This is an archive of past discussions about Domain Name System. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
In the section "How the DNS works" it asserts that the "browser starts out knowing only the IP address of a root server", which provides it with the proper subordinate server. Yet, in fact, a web browser uses whatever DNS server is specified for the client; this is usually the DNS server of their ISP, not the root server. AFAIK, the root servers are rarely directly queried by clients. I don't know the proper way to correct this. Centrx22:26, 17 May 2004 (UTC)
not only that but the browser just makes a system call to the operating system resolver library like gethostbyname() and gethostbyaddress(), this stub resolver then queries the dns, and the dns is not the only possible name resolution system, there is also /etc/hosts lmhosts winz and other micrsoft monstrosoties and nis, nis++ and other sun monstrosities.
I corrected this. It's actually the ISP's DNS server that has the list of root servers. I'm going to do further clarification when I have some more time. Technically it's not the "browser" that does the DNS querying at all, it's actually the TCP/IP stack in the computer. I also don't want the article to become overly technical so I'll have to figure out a way to get that in there without making the whole thing unnecessarily complex.
Gutzalpus 19:10, 19 Jul 2004 (UTC)
No, actually it's not the Internet Protocol stack which does the queries (think about the "layering violation" concept) but the resolver library, which is usually one of the system libraries and probably runs in the same addresses space of the browser. --Md 21:31, 23 Jul 2004 (UTC)
DNS name resolution
The process of resolving DNS names is much like finding a name in a telephone book. You dont just pick your phone book and start looking for the desired name on the first page and keep turning the pages until you find it. Like a telephone book, the DNS name structure is broken down into smaller categories that can be searched more easily and logically for a name/
|Martoh|
It would be worth describing how hosts normally get their DNS server's IP address(s) in the first place: As I understand it, it's typically from a DHCP server (at the same time it receives it's own IP address). In the case of that DHCP running on a home router, it may in turn have got it from the ISP's DHCP server - alternatively, if the ISP has assigned the line a fixed IP address and isn't providing DHCP (e.g., many cable-based suppliers), the home router must have it supplied during the router's initial set-up. Clearing this up would make it easier to understand how most load is kept from the root servers/diverted to the ISP's servers, how ISP's can return false or misleading results, etc. Having each host (PC, Printer, etc) manually configured with a DNS address would be very much the exception these days.Nimrod54 (talk) 02:53, 5 July 2014 (UTC)
By clicking the “Save Page” button, you are agreeing to the Terms of Use and the Privacy Policy, and you irrevocably agree to release your contribution under the CC-BY-SA 3.0 License and the GFDL. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Please give us a call at 704 for more information.
I believe that the table at paragraph "DNS message format" is a little bit misleading, because the sections containing RRs (Question, Answers RRs, Authority RRs, Additional RRs) are actually of variable length, but they're indicated as starting at a fixed octet offset. The fact that they're of variable length is cleary said in the paragraph "DNS resource records".
Moreover, in the paragraph "DNS resource records" I'd add the detail on how the NAME labels length is specified. Quoting RFC 1035: "Domain names in messages are expressed in terms of a sequence of labels. Each label is represented as a one octet length field followed by that number of octets. Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero".
Glavepp (talk) 09:56, 22 April 2015 (UTC)
External links modified
Hello fellow Wikipedians,
I have just added archive links to one external link on Domain Name System. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:
When you have finished reviewing my changes, please set the checked parameter below to true to let others know.
This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).
If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.
That reference once lead to this kind of thing, the bot instead chose the last available snapshot, which was a redirect eventually leading to this different kind of thing, which is overly long and doesn't substantiate the point --one registrar covers multiple TLDs. The adjoining reference is a dead link too. I'm going to remove both. ale (talk) 18:32, 18 December 2015 (UTC)
Section 0 is too long
Since we —IMHO correctly— decided to not merge various DNS pages, we should at least try and avoid repeating the same concepts in the same page.
Obviously it is not convenient to explain in an introductory, yet exhaustive style all of the content of DNS RFCs in a single page. An alternative is to just touch on concepts, one per subsection, using {{Main}} to direct to more detailed explanations. In particular:
The lede should be a few sentences in one or two paragraphs,
Section "History" seems to be too short, given that we don't have a "History of DNS" page,
Section "Function" could possibly be renamed "DNS vs phonebook",
Section "Structure" conveys the meaning of the hierarchy, so it is important to non-technical users,
From Section "Operation" onward, the content has to be more technically oriented. It may need some rearrangements in order to be more easily grasped. Some illustrations or tables might improve understanding as well; I'm aware Kbrose (talk·contribs) removed the message format table, but the remaining "bit-a-bit" description is not quite readable either... Perhaps we should have a real resource record page? Hm...
It scares me a bit that this article is quality B. I don't want to spoil it. Knowing someone takes a look at my changes would help, so please add your opinion below.
I have just modified one external link on Domain Name System. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).
If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.
I removed following paragraph as it conveys incorrect information. It reads as if the Sender Policy Framework and DomainKeys are now using they own DNS record type (instead of TXT). While a SPF record was introduced it was later discontinued in favor of using TXT record. This is documented in the List of DNS record types article.
I also did not find the paragraph particularly relevant.
The Sender Policy Framework and DomainKeys were designed to take advantage of another DNS record type, the TXT record, but have since been assigned specific record types. — Preceding unsigned comment added by Arekkusu.r (talk • contribs) 06:43, 9 February 2019 (UTC)
Semi-protected edit request on 27 December 2019
This edit request to Domain Name System has been answered. Set the |answered= parameter to no to reactivate your request.
The statement that IETF published RFCs 882 and **3 is incorrect: these two RFCs were published in November 1983, predating the first IETF meeting, which was held in 1986 (I was one of the 21 attendees). LixiaZ (talk) 04:40, 27 December 2019 (UTC)
I cannot see any publisher's information in the RFCs and IETF was formed in 1986. The current wording is:
Are there any opinions on wording for a possible change? Perhaps something like this:
The original specifications in RFC 882 and RFC 883 were published in November 1983.
A link to Paul Mockapetris is given in the preceding sentence. Perhaps the short paragraph above would be better if joined to the preceding paragraph. I temporarily disabled the edit request so a discussion about what to do can occur. At this time of year, we might need to wait a week or two for other views. Johnuniq (talk) 06:01, 27 December 2019 (UTC)
Either the above wording or a link to previous sentence as discussed would make sense. How about:
Mockapetris instead created the Domain Name System and the original specifications were published in RFC 882 and RFC 883 in November 1983
If you want to make either change or a similar one, I don't think it needs a full debate. The current wording is clearly not quite right, and if the new wording is not optimal, another editor can tweak it. Feel free to make a bold change. -- Sirfurboy (talk) 08:22, 27 December 2019 (UTC)
Does anyone know how I can set up my own domain name?
I mean, even the domain hosts have to get their one somewhere.
-DalekClock
Most people just use domain registrars. Domain hosts just have access to high level DNS servers, and the Internic ones (the major world ones), and they can sort it out with them. Reedy Boy13:02, 1 July 2006 (UTC)
I agree with this, and its notable that neither RFC 1034 nor 1035 use the term slave, and instead use master/secondary. RFC 8499 mentions previous use in rfc1996 which seems to be the outlier. I think that it is also reinforced by the fact that BIND and NSD documentations use both forms interchangeably, with secondary appearing to be used more. There will need to be some mention though of the alternate terminology as many configuration and zone files still reference it. Strangerpete (talk) 23:30, 20 June 2020 (UTC)
I forgot to add the quotes from RFC 8499 which is the Best Current Practice:
"Although early DNS RFCs such as [RFC1996] referred to this as a "slave", the current common usage has shifted to calling it a "secondary"
"Although early DNS RFCs such as [RFC1996] referred to this as a "master", the current common usage has shifted to "primary".
Currently, the types of DNS resolvers are described as non-recursive, recursive and iterative.
In my humble opinion, this distinction (without further explanation) is slightly confusing, as recursive and non-recursive should intuitively cover all the cases. In the RFC currently cited for this section[1], iterative is used as a different possibility altogether, and the section explaining the recursive and non-recursive mode somehow "forget" about the iterative mode, if I see this right? Any suggestions about how this could be clarified a little more? Any other opinions on whether it needs clarification at all?
Talitha 42 (talk) 17:58, 2 February 2018 (UTC)
IMO this section should be completely re-written. The word "iterative" doesn't occur at all in RFC 1035, and occurs only three times in RFC 1034, namely, on page 4. There it is clearly used as a synonym to "non-recursive". In the RFC, the terms "recursive" and "non-recursive" are only used to describe how DNS servers react to queries, not to describe how resolvers work.
As I understand it, resolvers always try to provide a definitive result, therefore providing "recursion" in a client application's point-of-view. They do this by iteratively querying other name servers, or by sending a recursive query to a DNS server that supports recursive queries (e.g. the DNS server provided by the ISP). — Preceding unsigned comment added by Mebuege (talk • contribs) 00:06, 25 August 2020 (UTC)
The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.
Comments@Randy Kryn: can you point me to a policy stating that that would be the best idea? If I am reading WP:CRITERIA, then DNS would be the best name, because due to it's significant higher use it has greater recognizability. Therefore it's also the most fitting name regarding naturalness, because it has been referred to as DNS. Because DNS is already redirecting to this article, the precision would be fine. Other articles about networking protocols also use the abbreviation, such as HTTPS and MQTT, so consistency is also fine. PhotographyEdits (talk) 18:59, 31 March 2021 (UTC)
WP:COMMON seems to cover it. This one is a good recognizable name, changed to just the initials it would probably lose a good amount of recognizability among a percentage of readers. For instance, for DNS my first guess would have been a moving company, second, one of those UPS competitors. Randy Kryn (talk) 19:32, 31 March 2021 (UTC)
Oppose I very rarely agree with using an abbreviation as an article title as opposed to the proper term. – DarkGlow • 19:00, 31 March 2021 (UTC)
@PhotographyEdits: Can you point me to a policy or guideline stating that removing the letter "E" from every Wikipedia article and then coming to your house and throwing your computer in a swimming pool would be a bad idea? Wait...what? Oh, that's right. It is the job of the person who proposes a change to give a reason for making the change. Never mind.(The swimming pool idea has a certain appeal, though...) --Guy Macon (talk) 19:36, 31 March 2021 (UTC)
WP:COMMON covers your proposal as well. To quote: "Similarly, just because something is not forbidden in a written document, or is even explicitly permitted, doesn't mean it's a good idea in the given situation." The computer in the pool proposal, in the vein of Phil Ochs' "Basket in the Pool", may be a bit extreme in this situation. So I'll Oppose that, and instead double-down on "They have a pool?" Randy Kryn (talk) 19:58, 31 March 2021 (UTC)
Yes, and you make a well-thought out good faith case in favor of the change. My point of view on it is that lots of us who aren't computer literate enough to recognize the initials alone (as Guy Macon demonstrates below) do know what 'Domain Name System' describes. Randy Kryn (talk) 20:17, 31 March 2021 (UTC)
Oppose for the obvious reasons. WP generally spells out proper names of protocols, and this is also the name of an entire naming architecture. Acronyms like HTTPS and MQTT are exceptions rather than a rule, and should be avoided as titles. kbrose (talk) 19:21, 31 March 2021 (UTC)
Oppose per MOS:ACROTITLE: "Many acronyms are used for several things; naming a page with the full name helps to avoid clashes."
DNS may also refer to:
Deviated nasal septum, a displaced part of the nose
3,5-Dinitrosalicylic acid, an aromatic compound
Dinalbuphine sebacate, an analgesic
Direct numerical simulation, a simulation method in computational fluid dynamics
@Guy Macon: DNS has other meanings, yes, but the WP:PRIMARYTOPIC is the Domain Name System, DNS redirects here. If I compare the pageviews from the articles on the DNS disambiguation page, then the Domain Name System has the most views, by a *wide* margin. see here. I would argue that "Acronyms should be used in a page name if the subject is known primarily by its abbreviation and that abbreviation is primarily associated with the subject" from MOS:ACROTITLE does apply in this case. PhotographyEdits (talk) 20:06, 31 March 2021 (UTC)
Right now you have five editors who oppose and zero editors who agree with you. It looks like you need a better argument if you want to convince anyone.
BTW, here is a better NGRAM:[1] Many people use, for example "DNS lookup" or "domain name lookup" but not "domain name service lookup". --Guy Macon (talk) 20:36, 31 March 2021 (UTC)
@Guy Macon: I'm not very convinced by the counterarguments though. It's up to the closing administrator to weigh all the arguments against each other. Regarding your Ngram link, Domain name is already a separate subject and otherwise it seems to confirm my point that DNS is a far more widely used than Domain Name System. PhotographyEdits (talk) 22:33, 31 March 2021 (UTC)
Oppose - I'm not sure what this request to move/rename is really solving. Yes, people know it as "DNS", but when they come to this page (by searching for "DNS"), it is clearly defined as "Domain Name System". In fact, I would argue that having it defined in the title actually helps people understand what "DNS" is because they immediately get it spelled out. I have read MOS:ACROTITLE and do understand the use cases for having pages titled as acronyms. I'm just not sure that applies here because, as noted above, there are other uses of "DNS" outside the Internet space.
A curiosity question about your use of Google Ngram Viewer for data, as I am not very familiar with it. If that is searching books for the usage of "Domain Name System" versus "DNS", isn't it logical that "DNS" would enormously outrank the full "Domain Name System"? The general principle in books is to define an acronym at its first occurrence, and then use the acronym thereafter. So many books will have something like "..in the Domain Name System (DNS) there are..." and then will use "DNS" for the rest of the book. In any given book there could be only one mention of the full name and tens or hundreds of mentions of "DNS". If this is the case, is the Ngram Viewer perhaps not the best source of data for this discussion? (Perhaps Google search trends or something might be better.)
@Dyork: "Yes, people know it as "DNS", but when they come to this page (by searching for "DNS")", well, then the title should be DNS. The title should represent the name that people are likely searching for per WP:CRITERIA on naturalness, and the first sentence of the article should give the full name. PhotographyEdits (talk) 11:25, 1 April 2021 (UTC)
Oppose on first WP:CRITERIA Recognizability: A non-expert familiar with the internet will certainly have heard of a Domain, but outside technical circles, I wouldn't expect anyone to recognize a protocol acronym.
Second on Consistency: The two pointed out as examples are literally the only ones in the protocol suite that are not full titled. And I'd argue that HTTPS isn't the same since the average reader will have typed https into their browser at least once in their life, and quite possibly why they searched here in the first place - this same reason applies to DNS: nobody 'types' dns, but they all talk about domains. Strangerpete (talk) 01:35, 1 April 2021 (UTC)
I disagree that anyone could have the slightest idea of intent, past the singular word 'domain', or the combo 'domain name'. And one easy way to help clarify that is to do as WP:COMMONNAME emphasizes, use natural language titles; it would be easier for a reader to decide if they want domain names or the system, simply by reading the title.
To point, your book stats example is using the full title; if you search DNS vs Domain name, there is a 0.0001% difference in popularity; since we have no idea which 'dns' or which 'domain name' is the interest, it all seems moot.
That said, I could assume most here replying are technically literate, and well familiar with dns if they are following the talk page; arguably this means we probably can't be the best judge of Recognizability, and is perhaps one source of pushback. If we want a balanced discussion I think it might be important to invite a less-technical audience to the party for their two-cents. Strangerpete (talk) 17:13, 1 April 2021 (UTC)
Comment: many engineering and scientific documents use "Domain Name System (DNS) exactly once in the first paragraph and then use "DNS" hundreds of times. Ngrams are a nice tool, but like all tools they have limitations. BTW, when I personally run across "DNS" the first thing I think of is "Do Not Stuff", but that's because I design electronics that are produced on pick-and-place machines. The context makes it easy to figure out what is meant. --Guy Macon (talk) 02:32, 1 April 2021 (UTC)
@Guy Macon: I think that's a good criticism on the Ngram tool, but I disagree. For example, this news article from ZDNet talks about DNS but never explains what the acronym means. So anyone unfamiliar with it would search for DNS. As I've earlier pointed out, by counting the Wikipedia page views it shows that this article is by a wide margin the most viewed of all articles that could have "DNS" as an abbreviation. PhotographyEdits (talk) 11:37, 1 April 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
New historical resource available (Nov 2020) about DNS and associated systems
The French and German version of this article have the upper image and other languages (e.g. Polish) have variations thereof. Whereas this article in English has the lower one.
Why do we not use the German one (or a variation thereof)? Is it incorrect or misleading? To me, being someone who is learning about what a DNS is, the upper one is much clearer. How about making a fusion of the English and German ones with useful names in the ″resource records with associated name″ instead of scribbles? 89.157.239.36 (talk) 06:51, 24 November 2012 (UTC)
The image File:DNS_in_the_real_world.svg depicts how DNS worked for most people fifteen years ago, but is really no longer accurate for most people, most of the time. Not that many ISPs operate their own recursive resolvers anymore, and not that many people use the ones they do operate. So labeling the recursive resolver as though it's somehow inherently operated by the ISP is definitely inaccurate. If there are any serious objections, I'll drop it, but I'll see if I can't whip up a more accurate diagram to replace this one. EVhotrodder (talk) 14:47, 30 August 2021 (UTC)
Moved from WP:RFPP
Done, thank you very much! 
~ ToBeFree (talk) 20:03, 18 July 2021 (UTC)
