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.
how about something about the anycast mirroring of the f.root and other root servers in multiple locations by ISC
the use of dns in RBL's and the like could be covered plus perhaps some stuff on enum Htaccess10:34, 8 August 2005 (UTC)
You say "I don't know the address of www.wikipedia.org, but I do know that the DNS server at 207.142.131.234 has information on the wikipedia.org domain."
But then you say "how does the DNS server 204.74.112.1 know what IP address to give out for the wikipedia.org domain?"
It DOESN'T. Straighten out the numbers.
Also "204.74.112.1 receives a request, the DNS server scans its list of domains, locates wikipedia.org, and returns the name servers associated with that domain."
I added "for the authorative DNS server" in the sentence "how does the DNS server 204.74.112.1 know what IP address to give out for the authorative DNS server for the wikipedia.org domain?". That seems to make most sense in reference to the next paragraph and glue records. Joonas Govenius13:55, 17 March 2006 (UTC)
Comment by 204.15.22.88
Re: Internationalized domain name: (shouldn't this be a bit more precise? is the first character required to be alfa? even though upper or lower case is allowed, is DNS case sensitive?). (original comment by 204.15.22.88, moved here by N0YKG14:01, 7 April 2006 (UTC)).
Arguably the TLD (top level domain, rightmost label) is still required to be ALPHA only. In practice no other official TLD exists. For the complete FQDN (fully qualified domain name) only digits (and dots) would be a bad idea, it could be confused with IPv4 addresses causing load for the root servers (answering queries about TLDs). Technically you can reduce this rule to "not only digits" for the TLD (allowing .1-2 with embedded hyphens), but that's not yet codified in an Internet standard, RFC 3696 is only informational. For other labels (not the TLD) there are two rules, host names (for e-mail, Web, etc.) must be LDH (letter, digit, hyphen), hyphen only embedded (not leading or trailing). Other domain labels (no hosts) can use any octet (byte), even dots, control char.s, spaces, and special char.s. That would break software designed to work with FQDNs, but there are official purposes for e.g. a leading underscore in labels. If you'd copy that info to the article I'd guarantee that it's correct... :-) -- Omniplex02:26, 8 April 2006 (UTC)
Here, just look at RFC1034. (That's the authoritative document.) Do a search for "authorit" -- repeatedly. LionKimbro
Merging "Domain Name System" with ALL Articles covering the Subject e.g. "Domain", "Domain Name", and corresponding redirects
It is a hassle to have so many Articles on the Main Subject the "Domain Name System".
I suggest merging them all.
"Domain Name System" Merging with ( some of the following Articles may no exist ):
Domain, Subdomain, Domain Name, root-level domain, top-level domain, second-level domain, sub-level domain, List of Internet top-level domains, BIND, Domain Name Server, EDU, ... .
I know that this results in a monstrous page but that can be prevented by using more than one page and getting rid of unsummarized and or otherwise bad content.
Example that helps to understand what I have in mind:
The first page of the article has a redirect to the following and a list of all pages that make up the article. Every Heading gets a Jump Point( like TARGET in HTML ) and if You search for Domain you get redirected to page x and point y of the article "Domain Name System".
Organisation:
The text will be stored as it is today but a new mark will be neccesary to accomplish the idea
( page x/page x x number of the page ). That mark will be managed by the server.
It´s possible to even further the idea with marks for every section heading in an article to lower the trafic outgoing from the server ( SectionHeading z/SectionHeading zsection z/section z ).
23:23, 17 February 2006 (UTC) Jan Girke jangirke@gmx.net
I'm not sure I understand your suggestion, and to the extent that I have at least a vague idea of what you want, I can't understand why you want it. I think the separation of pages should stay as it now is. Domain names are a complex subject which has many related topics which deserve their own pages. *Dan T.*00:22, 18 February 2006 (UTC)
My two cents; I'd like to see content go out of the DNS page. For instance, the section "Understanding the parts of a domain name" I would rather see go into domain name. (I'm the diagrammer guy, and I want to make some diagrams about domain names, themselves.) LionKimbro
I've just added an external reference to an example article which describes the issue of domain name theft. I couldn't find any other Wikipedia page that deals with the subject. It would make sense to add a section in the main article about such problems. As I don't feel sufficiently competent to write this myself, I am just adding this to the talk page as a suggestion for someone else to tackle. DFH15:17, 17 July 2006 (UTC)
I think that there should be two separate articles, and that Domain Name should be a stub that says something like "A human-readable name for a computer that can be resolved to the computer's IP address using the Domain Name System". --Guest, 23 December 2005
The DNS is a distributed database, and is very distinct from issues regarding the actual domain names. These should stay separate topics -- the DNS topic should focus on the system, while the domain names article should deal with how the names are used, disputes, relationships to trademark legislation, and so on.--Ott210:39, 10 January 2006 (UTC)
I agree with Ott2 they should be seperate but should have some indication that they are connected. Although, most people are most likely going to be IT students or It pros looking at this, it would be helpful for them to be seperate.
--Guest, 06 Feb 2006
I think that the information should be separate, but must present links between both sections.
Both r good - Domain Name only elaborates or say provides the base for reading Domain Name System article. So each has a seperate identity. Let them be as they are. Hartej 20:07, 24 April 2006 (IST)
Right: two articles are right. --gionnico 13:42, 29 April 2006 (UTC)
Keep separate - they are two different (though related) topics. DNS is the technical mechanism by which domain names are resolved, while domain names have many uses and conflicts unrelated to these technical aspects. *Dan T.*16:18, 14 June 2006 (UTC)
Keep both and what's more I'm going to remove the Merge? tag. - there is a clear concensus here to keep both and this discussion is so old. Next thing you know it'll be years since the tag was added and it'll still be there if no-one is brave enough to delete it. - Drstuey12:50, 4 August 2006 (UTC)
Fix disambig tag
Please replace the tag at the top of the page with the correct one. DNS does not link to this page; it goes to the disambiguation page. Cbdorsett08:52, 25 January 2007 (UTC)
In the end the change required to support IPv6 is so minor that it seems adequately covered in the Types of DNS Records section. Also the IPv6 article covers the issue well from the perspective of IPv6 pcrtalk04:31, 26 February 2007 (UTC)
I agree with that. Additionally, the categories are inconsistent. Most stuff is in Domain Name System, while this article and some others are in category Domain name system. See Category:Application_layer_protocols -- dbu, 29 November 2006
The Registrant section under Legal Users of Domains has a paragraph that begins, "However, some domain registries, such as VeriSign, use a registry-registrar model." This was not clear to me and I still do not understand the point being made. Perhaps an example would help? Silpertan02:39, 2 November 2006 (UTC)
"A domain name registry is the operator for a particular Top-Level Domain (TLD). For example, VeriSign is the registry operator of '.com' and '.net' domains, PIR is the registry operator of '.org', and NeuStar is the registry operator of '.us' and '.biz'.
"A domain name registrar is a go-between for the registries and the end-user. Much like a retailer sells goods from a wholesaler, a registrar sells domain registrations directly to the registrants, maintains information for the registrations such as nameserver delegation and WHOIS information (see below), makes changes to the registry on behalf of the registrants, and provides customer service and support. While a registry is usually governed by a single entity, many registrars exist to sell registrations to customers on their behalf, creating a competitive market."
-69.87.204.216 (talk) 21:43, 17 January 2008 (UTC)
Glue records - NS records have names
I've removed "typically" from the listing of DNS records for nameservers. An NS record contains a name, not an IP address, so it's impossible to list NS records by address - they have to be listed by name. --Alvestrand (talk) 20:40, 18 January 2008 (UTC)
The article name is screwed up
It should be Domain Name System, not Domain name system. All the important DNS Internet RFCs always spell it in all caps. I dunno who moved it to "Domain name system" but it really needs to go back to Domain Name System. --Coolcaesar (talk) 09:36, 26 February 2008 (UTC)
While I agree that "female cannot understand DNS" is an unnecessary remark, I'm not convinced that the changes made are not appropriate. 'he' is gender indefinite, and the use of phrases such as "he or she" is both cumbersome and absurd. I suggest that the change be re-instated with a better change log message.
i question the inclusion. yes, there's a new DNS type in place for it - but it's experimental, and i'm not sure if experimental records should be conferred formal status in the article. at best, it should be noted that they are experimental. yes? Anastrophe (talk) 19:22, 23 February 2008 (UTC)
I was just looking at the idea of moving SPF and NAPTR records to the list of DNS record types article. I notice that the list-of article is out of date and is missing quite a few of the minor record types. In my opinion, the status that the IETF puts on the DNS record shouldn't make much difference for wikipedia, we need to decide which ones are notable and as mentioned in this article "important". There are lots of (IMHO) unimportant DNS records that are on standard-track RFCs.
However, I think I should bow out of any changes here. I have strong conflicts of interest (e.g. WP:COI) as I'm both the co-author of SPF's RFC 4408 and a strong opponent of the idea that the new type 99 SPF records would ever be useful. (This is an issue that has divided the SPF community.) I've tried to be very impartial with my editing of that particular part of this article, I neither added it, have changed it much. I reverted your deletion only because I thought you didn't realize that there were two different record types for SPF. Wrs1864 (talk) 19:57, 23 February 2008 (UTC)
you get a huge virtual pat on the back for acknowledging your own COI and voluntarily deferring. would that 99.999995785% of the other editors with COI would do the same (and only after being confronted on it). many thanks. and yes, you were correct - i wasn't aware that there was the new record type. Anastrophe (talk) 20:12, 23 February 2008 (UTC)
I guess I didn't mention that it is quite possible that there are now more type99 SPF records in the DNS than there are WKS records. Both of these are probably outnumbered by other DNS records, such as used by IPSec, DNSSEC, HIP, etc. DKIM will soon have an new DNS record, and I suspect more are coming. I guess what I'm saying is again is that I think the list in the this article should be cut back, while the list of DNS record types should be pretty expansive. I could see moving CNAME and PTR out of this article too. Wrs1864 (talk) 22:28, 2 March 2008 (UTC)
In this edit, someone made the claim that the type 99 SPF record "will be the preferred record type". This, to me is in clear violation of WP:NOT#CRYSTALBALL as nothing in the SPF spec says that type 99 records are preferred. Also, the discussion about when SPF is during the e-mail transaction really doesn't belong here, it is discussed in the SPF article already. Basically, I done not think any of the edit is appropriate for this article. I would revert it, but as I mentioned above, I have a WP:COI problem here. Speaking of which, if Alex2006 is Alex van den Bogaerdt, he also has a very similar conflict of interest problem.
agreed. purely on WP:CRYSTAL grounds it's not appropriate, and considering the slothlike path RFC's can sometimes take, it's silly to suggest what will result (particularly considering the fine points of "MUST", "SHALL", "MAY" that RFC's get into, and which won't be finalized until the rfc is finalized). i'm going to revert. Anastrophe (talk) 06:23, 3 April 2008 (UTC)
I made that change yesterday because someone objected in my talk page that SPF does not actually operate on the Return-Path. I don't think one needs a crystal ball to understand why a record named SPF has been introduced; however, I agree that preferred is not the exact word and would change it to specific. I'm sorry I hadn't read this talk page before... I'm not Alex van den Bogaerdt and I'm just a user of the SPF system, web site, and mailing lists, thus I don't think I have any conflict of interests. In addition, I think only spammers have real conflicts of interest on these subjects, so please don't hesitate to change/revert/amend my edit as you feel appropriate in the interest of clarity. Rationales for the change I (re)do are:
SPF is an example of an experimental DNS record, an occasion to explain such thing,
a crispy explanation of how the record is used is appropriate to understand the implications, and
this edit was also reverted, on the basis that this article is about DNS, not email. interested readers may go to the linked SPF article. That's probably correct, even if the use of DNS is very entangled with mail practices. It is difficult to explain the SPF record without making reference to the email system, though.
The record description as it stands is wrong, because it asserts that SPF does something with the Return-Path, which is wrong. I introduced that error myself in this edit. Thus, I feel obliged to fix it.ale (talk) 14:54, 5 April 2008 (UTC)
that's fine, my main objection was that it went into too much detail about SPF, which the wikilink to the SPF article is specifically there to assist those interested. Anastrophe (talk) 18:57, 5 April 2008 (UTC)
Merger proposal: "List of DNS record types" into this article!
The article "List of DNS record types" is completely identical to "Types of DNS records" section of this article. I propose a merger. Fleet Command (talk) 08:11, 28 March 2008 (UTC)
See the discussion above about the new SPF type 99 record type. My opinion has not changed from my comments posted there, I think we should do the opposite of what you are suggestion and split out all but the most important DNS records out of the DNS article and fill out the "list of" article. Oh, and the lists are not completely identical. Wrs1864 (talk) 10:00, 28 March 2008 (UTC)
I split it off the DNS article because I realized that:
The article in the DNS artcile is woefully incomplete
Making it complete would make it much too long to fit into the DNS article.
Support There's too many record types to fit in the main article. It's probably enough to mention the most common records (e.g. A, MX) and then have the list article contain an exhaustive list of DNS records. Andareed (talk) 19:06, 5 April 2008 (UTC)
agreed as well. the list should simply be in the 'types of dns records' article, and we link to it here. eventually, it would be "neat" if each record type got its own more informative paragraph in that article. Anastrophe (talk) 19:12, 5 April 2008 (UTC)
The article starts off "The Domain Name System (DNS) associates various sorts of information with so-called domain names; ". What are "so called" about domain names? Lyle (talk) 15:36, 11 April 2008 (UTC)
Re: "translating human-readable computer hostnames, e.g. www.example.com, into IP addresses, e.g. 208.77.188.166, which networking equipment needs to deliver information" (from this version): Isn't the real IP address 11010000010011011011110010100110 (if my math is right), and the 208.77.188.166 is only a somewhat more human-readable form of that (especially for the astigmatic)? I seem to remember a few years back that you could paste 11001000000000001001100000000010 into a browser and be taken to Wikipedia. Doesn't seem to work any more, even with the "search" and "add prefix/suffix" disabled. Did something change in the past few years? Unimaginative Username (talk) 09:32, 12 July 2008 (UTC)
Binary is used at a very, very low level, and I don't think it was ever exposed directly to the user. —CobraA123:17, 2 August 2008 (UTC)
Actually the domain name system isn't ever exposed to the user. In the context of the domain name system, IP addresses are stored in binary.
I don't think you ever could get to Wikipedia with 11010000010011011011110010100110, but you might get there with 3494755494.... however, doing that gets a "bad request" from SOME apache server on my browser.... --Alvestrand (talk) 21:59, 3 August 2008 (UTC)
"In the context of the domain name system, IP addresses are stored in binary.". That's what I thought. I realize that they were not deliberately exposed to the user that way, nor was the entire DNS system. It was partly an academic question, and partly because I seem to remember, waay back when, (Win 98/ME days), you could do the tricks I described, just for fun. I also vaguely remember that that's how some kids would get around parental filters (to adult sites). They'd ping the URL, find out the octet address 12.345.6.789, translate that into the 32-bit equivalent, and load it in the browser. Not that I'm condoning the practice, of course, but just wondering if my memory is faulty. Unimaginative Username (talk) 06:28, 4 August 2008 (UTC)
helpful for what? DNS servers are not noteworthy just because they exist and Wikipedia is not a place to collect links that will be difficult to keep current. We don't have pages that just list website urls either. That was a practice of early web directories in the early nineties. While it can be useful to query a distant name server at times for testing, most people have no need for that and should use their upstream name servers. Kbrose (talk) 18:21, 11 August 2008 (UTC)
OSI layer: why L7?
What makes the DNS protocol an application layer protocol? It isn't an “end in itself”, but serves for the purpose of initiating sessions. Unlike network layer IP protocol, it isn't used for addressing hosts on a network, but merely to resolve their IP addresses and other properties such as MX, etc. So, DNS lies between L3/L4 and L6/L7 — right on the L5, the session layer: each time a session is open or re-open, the DNS helps to find out the nessesary L3 and even L4 information. No one needs domain names per se, and it's not the application's task (according to OSI principles) to deal with domain addresses — the application simply passes user-supplied address to an opensocket() function, be it a domain name, an IP-address or other locally defined target host's alias. 213.234.235.82 (talk) 11:31, 29 August 2008 (UTC)
The right way to do that sort of analysis of a protocol, though, is to ask what the protocol itself makes use of. For DNS, it makes use of UDP below it so it definitely has to be higher than UDP, for example. It may be a supporting protocol to other ones, but that's not what classifies it. It's classified by how far up the information itself flows up and down the OSI stack. (since http can do a redirect to another http page, does that make http sit at multiple points since it's also a helping protocol to itself?) Hardaker (talk) 14:26, 29 August 2008 (UTC)
You're illustrating clearly why the IP protocol stack doesn't attempt to make any layer distinctions above layer 4. Every time anyone attempts to legislate layers up there, things get messy. --Alvestrand (talk) 14:44, 29 August 2008 (UTC)
Yes, of course, DNS uses UDP as a transport. This does not contradict with DNS residing on layer 5 while UDP is on 4, does it? Even more, DNS itself does not create any “session” (L5), nor it uses an encoding, compression, encryption (L6), nor it delivers end-user documents (L7).
And speaking of HTTP redirects, any redirect can be considered a document — not the needed document itself, but a pointer to it. The fact that browsers automatically follow redirects instead of displaying an empty window with redirecting link for user to press it, does not change the nature of HTTP protocol. Since redirects have the form of URLs (not IP addresses or other type of pointers), they belong to the same layer as user-supplied URLs do — the application layer. 213.234.235.82 (talk) 15:36, 29 August 2008 (UTC)
Frankly, this discussion of OSI layers is rather irrelevant, since DNS is clearly not an OSI protocol, but an Internet protocol. In the Internet Protocol Suite it's clearly an Application Layer protocol since its use is only in applications or software processes for the purpose of resolving domain names (= user labels) to the addresses used by the Transport Layer and below. As to the reason why the Internet Protocol Suite doesn't distinguish more layers above the transport, it's because it simply doesn't matter to the operation of the Internet, the same reason why it doesn't recognize a hardware layer at the bottom. Kbrose (talk) 04:14, 5 September 2008 (UTC)
From the start, the acronym BIND stood for Berkeley Internet Name Domain, the server being the "Berkeley Internet Name Domain (BIND) Server". It was never, as some have believed, Berkeley Internet Name Daemon. The original acronym is clear from the title of and usage in the original BIND paper, The Berkeley Internet Name Domain Server.
This is a good catch, anonymous (or mayby Fabiano). I will update the article appropriately (with facts from the BIND article) —fudoreaper (talk) 08:04, 5 September 2008 (UTC)
Remove IPstack box from DNS page
I suggest that the IPstack box ("The five layer TCP/IP model") at the top of this DNS page be removed. It is not relevant to the subject. Though DNS is an application that uses TCP/IP, this does not justify confusing readers with the complexity of the TCP/IP model. DNS is complex enough; the layers of the TCP/IP stack are not useful in understanding DNS. IP addresses are an important concept here, but they are much simpler than what is shown in this box.
Davipo09:19, 10 April 2007 (UTC)
Disagree. Why does that infobox include DNS, then? Just because it is hard for the user to understand the DNS in context with related technology (which is true of any highly-technical subject) is not reason to remove reference to closely related technology, i don't think. Further, I disagree that the layers of TCP/IP are not helpful in understanding DNS. I would say that if you have no understanding of IP, then you will never understand DNS. I would go along with moving the box to a see also section, though. —fudoreaper (talk) 07:40, 5 September 2008 (UTC)
I always had mixed feelings of its presence here, but over time neither opponents or proponents seem to form a majority, so I put it back in (as someone would do it again anyways) but with a much needed reference to the DNS protocol itself in the lede section. This should provide enough context as justification. Kbrose (talk) 18:44, 7 September 2008 (UTC)
I really think it belongs on the page. DNS is itself even listed in the box. DNS is a fundamental underpinning of how much of the internet works from a user's perspective and it is important that people understand how DNS is critically involved with the other protocols. I think it's important to be on the page not only for purposes of educating people where DNS sits, but also as a likely jump-box for people to other protocols. (It's early morning and I'm not being very articulate). Hardaker (talk) 13:10, 8 September 2008 (UTC)
My two cents: a very strong keep. I can't think of a more relevant protocol for the ipstack to template to have and for the ipstatck template to have on its main article. DNS and TCP/IP evolved around each-other and it is hard to understand one without the other. I am honestly confused about why anyone would think otherwise, despite pondering this subject of a while. Wrs1864 (talk) 20:05, 12 September 2008 (UTC)
McCain redirect
I am just raising awareness of the fact that there might be a need to protect this page in the near future. Earlier on 29 September 2008, there was a digg article about the URL voteforthemilf.com being owned by the McCain campaign. Sometime in the evening, the redirection now lands on the domain name registration section of the website. I, like many other digg users, can provide original research verifying it, however I am aware that is not the standard for wikipedia. I don't believe it warrants a mention on this page, I just want to alert people who track this sort of thing and know the appropriate course of action.O76923 (talk) 00:31, 30 September 2008 (UTC)
The types of records wikilinks which link to the record name article and then redirect back to the DNS page are fairly confusing. This breaks an important Web rule - never link to the current page. - Shadowhillway23:52, 7 November 2005 (UTC)
Would it be useful adding a section showing in general how long it takes to 'resolve' a domain name from one server IP to another? —Preceding unsigned comment added by 121.91.223.6 (talk) 02:26, 17 February 2010 (UTC)
Yes i think this is a good idea. Reverse DNS is nearly the same as forward DNS (actually just different type of lookup) but i think it merits discussion. Perhaps i can add something right now under 'operation'. —fudoreaper (talk) 22:05, 17 September 2009 (UTC)
Who will normally provide the reverse-DNS service for a given IP? The ISP? I guess this have to work somewhat different than a normal DNS query where you can simply ask the top level which refers to the DNS-server holding the requested zone/domain... —Preceding unsigned comment added by 158.112.86.66 (talk) 10:31, 27 May 2010 (UTC)
Technical question on Section move
According to this DIFF the editor left the comment "(move section to domain name)" but there is a problem.
I do not question the section move -- I think that is fine -- but I am going to show where something went wrong and ask for my own education as well as others' how this could have / should have been done better...
What, if anything, could have been done to prevent this broken wikilink? I do not believe that editors should be required to know what links are inbound to a page, but surely some mechanism must exist to identify broken wikilinks or to prevent breaking them?
Also, why does an "ArticleName#SectionName" type wikilink NOT show as a redlink when the named section is no longer present in that article?
There isn't any automatic mechanism to prevent breaking of such links (there should be, but the software isn't that clever). People who create such links are encouraged to leave a comment in the wikitext at the top of the section they link to, or perhaps insert an anchor. Such a broken link won't show as a redlink because it's not completely broken - the link will still work, but will take you to the top of the target page rather than the specific section. HTH,--Kotniski (talk) 10:37, 25 November 2010 (UTC)
Length - 253 or 255?
I've added some more text to the discussion of domain name length.
This is a somewhat complex question, as evidenced by Peter Koch's reply to Stuart Chesire's posting (Chesire's posting is quoted in the article; Chesire is Apple's leading DNS expert, while Peter Koch is currently one of the chars of the IETF's DNSOP WG). It's made more complex by the fact that the domain name system isn't at all limited to ASCII - technically, you can put any octet in a domain name, including control characters, high-octet characters and so on; you can even put dots inside a label, which is conventionally represented by a backslash in front of the dot, meaning that you have 2 characters in the ASCII representation for one octet of binary format.
The standard attitude for people who get into trouble by using these facilities is "you asked for it - your problem" - but people have been known to insert stuff into a zone file that would make things go bang if people blindly use DNS names in certain insecure way.
The introduction of IDN makes matters even more complex - the result of the ASCII-encoding of the Unicode form of a label means that you have more ASCII characters (and therefore octets) than you have characters, which means that the total length possible to represent in the 255-octet protocol format is very dependent on the exact characters used in the labels, and even rough guidelines are hard to come by. So careful terminology is important. --Alvestrand (talk) 18:24, 8 June 2008 (UTC)
I was just pondering if I should start a discussion here about the length. I confess I looked into it because I was worried that I messed up when editing RFC 4408. Someone told me to change the maximum length from 255 to 253, gave a vague explanation and I trusted him to be right. Then, when this article was changed to 253, I couldn't figure out why it was 253 and not 254 (I forgot that the first label has a length count, but not a dot).
Anyway, the reason why I thought 253 would be the better "maximum length" for this article is because this is supposed to be a general encyclopedia article, not a technical book on the subject. You are right that the definition of what can be in a "domain name" is *very* different than what many people expect. The original intent of the (now obsolete) MB record was to have the entire e-mail address put into the domain name, and the local-part can have periods, spaces and other special characters. Maybe we should have a section on "gory details", like how Joe\ A\.\ Blow.example.com is a valid domain name with a period and spaces inside a label, and how \[xd074/14].ip6.int is putting binary crud into a label. Until we start delving that deep into the bowels of the DNS, I think telling people that 253 is the maximum in the format they think DNS follows is the best.
Oh, and the footnote is technically still wrong. I wrote "on the wire", but as that thread points out, it really isn't "on the wire" that makes a difference, especially since label compression can shorten stuff up "on the wire". It is really about the sizes of internal buffers/database that a DNS server has to deal with, but that "database" isn't the same as the zone file. If you can think of a better way of phrasing it, please fix the footnote. Wrs1864 (talk) 19:24, 8 June 2008 (UTC)
Since I'm currently editing IDN specification documents, I'm painfully aware of just how many misleading things one can say by using the term "character" - that was actually my biggest concern. If you have a name in well-scattered Chinese characters (so that the Punycode compression doesn't help you much), I believe it's possible to get a maximum length in characters of somewhere around 64 characters. So when talking about characters, we have to say that it's ASCII characters too. (I guess 4408 will at some point have to address IDNs...)
"On the wire" is almost as painful as "character"; an SMTP or HTTP transaction is "on the wire" too, but carries the names in ASCII format. In this article, I think we should make sure we talk about the DNS format when we say "on the wire". The format is NULL-terminated, so the only real limit there is the comment about 255 octets - 1035 section 2.3.4 sounds a bit more authoritative about it.
About compression - I don't think you can manage to use compression on the name of a question. 1035 section 4.1.4 describes compression as pointing to whole labels that occur earlier in the same packet - this means that the question name, being first, cannot be compressed. So it's technically possible to return an answer that contains a name that expands to more than 255 octets, but you can't ask more questions about it....
(Yes, it seems that a section on "DNS arcanae", aka "facts you really wish you didn't need to know" would be fun to write.... but somewhat unencyclopedic....) --Alvestrand (talk) 20:37, 8 June 2008 (UTC)
This is quickly getting into RFC-lawyering, which I find interesting, but it probably isn't appropriate here. I am really not set on either the "253" number, nor the use of "characters", what I really wanted to do is show that link to the mailing list thread where the whole can of worms was opened for people to ponder. I also didn't want to imply any false precision, so I used the looser term "character" and said "typically about 253". I can certainly understand how "character' can be ambiguous, especially in the IDN area.
I think one of the causes of the misunderstanding about what can be in labels stems from the fact that almost all RFCs that specify the use of domain names, restrict them to either the letter-digit-hyphen hostname type restrictions, or small supersets such as including the underscore for SRV records. E-mail addresses, URLs, configuration files, etc. don't let you use backslashes to put a dot into a label, or create bit labels, or anything. So, saying that a domain name can be 255 octets, but only in situations that almost no one can directly use is, I think, a little misleading.
As far as label compression goes, I think you really are supposed to restrict things so that domain names can't be more than 255 octets internally, not just on the wire. I was thinking of things like NS records and glue A records, along with DNSSEC canonical forms being problem cases where you might be able to get longer domain names in the cache. And, if you *can* get them in the cache, well then, gee, you aren't really restricted to 255 octets, but you now have a whole new can of worms.
As far as 4408 goes, I was one of the first to jump on the IDN problems, but Meng patiently pointed out that there really aren't any (or at least not major ones), SMTP is painfully tied to ASCII and punycode domains can be put into SPF records. see SPF I18N FAQ and Frank's I-D. I think my repressed memories are coming back. >.< Wrs1864 (talk) 22:25, 8 June 2008 (UTC)
RE: Cache pollution attack in July 2008
An encyclopedia is not a news reporting bulletin board. There is nothing even in the CERT release that has bears any new knowledge of DNS, other than reiterating already known security flaws of DNS implementations. The paragraph on Security here is bad enough, but it does already mention cache pollution problems. Kbrose (talk) 12:20, 9 July 2008 (UTC)
I just looked at http://tools.ietf.org/html/rfc1123 and it states on page 12: "Host software MUST handle host names of up to 63 characters and SHOULD handle host names of up to 255 characters.". So the length limitation of each name not longer than 63/253 looks wrong to me (section "Domain name syntax", 3rd bullet) as the RFC specifies the length for the names as they are in fully qualified notation, not on a "per dot separated part" basis. Currently the text says "may contain up to 63 characters. The full domain name may not exceed a total length of 253 characters". --Ray —Preceding unsigned comment added by 153.96.14.101 (talk) 12:50, 5 April 2011 (UTC)
I have an idea about a feature that would change how the internet worked.
I propose that DNS have resource record types such as:
porthttp,porthttps,portsmtp,portsmtps,portimap,portimaps,portpop3,portpop3s,portftp,portftps,etc...
I appears to me that such a move would change the way the world relies on IP addresses, since we appear to be running out. If you think how many servers there are in the world that have static IP addresses that only host one web page or even one service.
It seems like it would be fairly easy to implement a record type lookup to determine what port a website is using. The same thing could be accomplished for looking up what port a mail server is using. Yes the web browsers of the world could be adapted to do a ip and port lookup.
SSL Certificates could be adapted to include both the domain name and port.
DNS record types could be created and used to register what port a webpage is on.
For example:
My webpage would have two DNS records.
Record Type "A" host record, www.example.com = 127.0.0.1
Record Type "porthttp" port record, www.example.com = 80
This type of resource lookup would allow the internet to host a website or service on which ever port they wanted and would prevent the world from relying on common ports as the answer of where am I going to put my service.
Think about this. Currently one static IP address can only host one website service on a single static IP address. Routing and NAT take care of this. The only problem is there is no DNS record to lookup a port for the expected service. If a single IP address can have 65535 ports then a single IP NAT address could host 65535 websites on 65535 different ports. All is need is the ability to find the port that the http service is located on. — Preceding unsigned comment added by 68.106.179.249 (talk) 10:58, 28 July 2011 (UTC)
I also see this as a chance to solve the world's problem with ISP's blocking commonly used ports.
I don't have the programming skills to do the work, but if the idea was communicated to the world, the right people could make it happen.
Nice thinking, but multiple logical web servers can already be hosted behind the same IP address, on the same server machine. For example, foo.example.com and bar.example.com might well direct to the same IP address. It's then up to the server software to recognize which service the user is actually requesting, based on the (sub)domain defined in the HTTP request. This is already widely in use. —ZeroOne (talk / @) 08:18, 20 September 2011 (UTC)
Yes now think about the following. Sub Domain defined HTTP requests works when a single server hosts multiple websites. People all over the world are hogging an entire IP or even a block of IPs because they want to host their webservers on port 80. I am saying by implementing port lookups you can have 65535 servers behind a single IP on any port available or assigned. Those servers with assigned ports can then host multiple sub domain websites through HTTP request matching. This is already currently available, except for one important feature that most web browsers are missing (port lookup). Most browsers assume that the website is on port 80, because somebody in the world decided that that was where websites would be located. I am saying this is restrictive and seems like the thinking of yesterday and should be recognized that today browsers could be updated quickly to support such functionality. The funny thing is that there is already a static file (services) on every computer in the world that provides port numbers for well-known services defined by IANA. Maybe RFC 2782 was supposed to take care of this and nobody has thought that web browsers could use this. — Preceding unsigned comment added by 68.107.144.160 (talk • contribs)
Maybe you didn't read RFC 2782 or maybe I didn't understand it correctly. I extracted below parts for you. The Port Record already exists. The problem is that no one is using it because no one explains DNS beyond a basic DNS lookup. My guess is that most modern browsers don't lookup port numbers by SRV RR type 33. I think this should be listed as part of this article. As it gives the ability for services to be access on non standard ports. Example would be running your services on non standard ports and use the standard ports as backups. There are lots of benefits.
The format of the SRV RR
Here is the format of the SRV RR, whose DNS type code is 33
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
(There is an example near the end of this document.)
Service
The symbolic name of the desired service, as defined in Assigned
Numbers [STD 2] or locally. An underscore (_) is prepended to
the service identifier to avoid collisions with DNS labels that
occur in nature.
Some widely used services, notably POP, don't have a single
universal name. If Assigned Numbers names the service
indicated, that name is the only name which is legal for SRV
lookups. The Service is case insensitive.
Proto
The symbolic name of the desired protocol, with an underscore
(_) prepended to prevent collisions with DNS labels that occur
in nature. _TCP and _UDP are at present the most useful values
for this field, though any name defined by Assigned Numbers or
locally may be used (as for Service). The Proto is case
insensitive.
Port
The port on this target host of this service. The range is 0-
65535. This is a 16 bit unsigned integer in network byte order.
This is often as specified in Assigned Numbers but need not be.
Here is a real example of why DNS needs to be explained correctly. This is a bug listing for an application that does not have the ability to use SVR RR Type 33.
I now know that I am not alone. https://bugzilla.mozilla.org/show_bug.cgi?id=14328
Service List Explained
http://www.zytrax.com/books/dns/ch8/srv.html
srvce Defines the symbolic service name (see IANA port-numbers) prepended with a '_' (underscore). Case insensitive. Common values are ...
_http - web service
_ftp - file transfer service
_ldap - LDAP service
_imap - IMAP mail service
_PKIXREP - PKIX Repository (X.509 certificates)
Examples
srvce.prot.name ttl class rr pri weight port target
_http._tcp.example.com. IN SRV 0 5 80 example.com.
_http._tcp.example.com. IN SRV 0 6 8080 example.com.
_http._tcp.example.com. IN SRV 0 7 8181 example.com.
_http._tcp.example.com. IN SRV 0 8 88 example.com.
_https._tcp.example.com. IN SRV 0 5 443 example.com.
_https._tcp.example.com. IN SRV 0 6 449 example.com.
Now you can put your servers on any port!
Now do you understand why it is so important to make sure people understand this?
"authoritative name servers that are installed in ... the parent zone"
Quote: "Every DNS zone must be assigned a set of authoritative name servers that are installed in NS records in the parent zone".
That's not complete is it? The zone is authorative for itself, so the NS records need to be installed in the zone to be authorative? — Preceding unsigned comment added by 203.206.162.148 (talk • contribs)
The copies must be installed in the parent zone so that people looking at the parent zone can find the NS records for the domain. These records are not authoritative - they need to be the same as those in the zone itself. (Having them not match is a common configuration error). --Alvestrand (talk) 14:19, 9 May 2012 (UTC)
Other uses: software updates
This makes absolutely no sense! A virus scanner gets updated hourly or sometimes many times an hour, while institutional DNS servers cache records for 24 or 48 hours. Why would any company use the DNS system to distribute quickly changing information, which only takes a few bytes?
Software Updates: Many anti-virus- and commercial software now uses the DNS system to store version numbers of the latest software updates, so client computers do not need to connect to the update servers every time. For these types of applications, the cache time of the DNS records are usually shorter. — Preceding unsigned comment added by Zsero1 (talk • contribs) 05:47, 9 May 2012 (UTC)
I think there is a good chance this is incorrect information, and it certainly isn't what DNS was designed to do, nor is it covered by an RFC, best I could find. If someone comes up with a reliable source, great, otherwise it needs to stay gone. — UncleBubba( T@C )06:37, 9 May 2012 (UTC)
clam AV (www.clamav.net) uses a TXT record for current.cvd.clamav.ne. At the time of writing, the value is "0.97.4:54:14945:1337668141:0:63:38837:182" and the TTL is 900 (15 minutes). As the leading sentence in the article states: "for computers, services, or any resource connected to the Internet"
The article also seems to be missing anything about SRV records, as in RFC 3263 "Locating SIP Servers"
this edit doesn't appear to be backed by the references given. The references are pretty bad, though—it's not really appropriate to refer to a primary source to justify the statements in this paragraph, and indeed all the primary source confirms is that Mockapetris is the author of RFC1034. If the author of this knows that the change is true, it would be great if he or she could provide some source material to support it. If the author reverts my revert, I will leave it alone, since I don't have any reason to believe either version over the other. Abhayakara (talk) 18:23, 29 July 2012 (UTC)
Would anyone be opposed to me adding a simple example of a common DNS query somewhere near the top of the article? The example would be something like:
browser > ISP's DNS server > root nameserver > .org nameserver > Wikipedia DNS server > wiki.riteme.site IP address
As it is, the article is unwieldy and not useful for someone wanting the basics of how DNS queries work. This would give someone a quick overview, after which they could dive into the loads of technical details the article provides.
--Qwerty0 (talk) 20:47, 26 September 2011 (UTC)
Yeah, something like that, but a bit simpler. A diagram would be good but I'm mainly talking about a simple written example where I explain how a lookup might proceed, mentioning caching and the recursive steps.
For example, your browser wants to get to http://wiki.riteme.site. So it looks in your computer's cache, then asks the ISP's server if it has it in its cache, then asks a root nameserver for the .org's nameserver IP address, then asks the .org nameserver for wikipedia.org's nameserver IP address, then asks wikipedia.org's nameserver for the actual IP address of the webserver at wiki.riteme.site.
And please correct me if anything about that is very incorrect. But remember I'm not going for extreme precision; I'm trying to keep it as simple and straightforward as possible.
Although simple can be good; too simple can be bad. If anything is going to be added that describes the typical process as an example, it should be first: accurate, second: clear, and third (last): simple. For simple descriptions we have simple:Wikipedia. We shouldn't patronise our readers. I myself have learned a great deal from WP's articles and am truly grateful they were not simple. fredgandt20:09, 22 December 2011 (UTC)
I don't think simple == incorrect. I think it can be both clear and accurate. Sorry, but I've stopped going to Wikipedia to learn things I don't already know about. That's because there are too many articles like this that you can't come to and learn what the thing is. It's very useful if you already know the concept but just forgot a few details. But it's not useful if you are trying to learn the concept. I would like to change that.
So: How about a simple, small section like I described? I'll post the draft here so you can peer-review it. Also: I found the kind of diagram I'm imagining. You can see a good example in this video.
In that case, simple == incorrect, the ISP's DNS server never asks for org, or wikipedia.org, it always asks for fr.wikipedia.org and either gets NS records telling it to go look somewhere else, the answer of what it asked, or an error.
should we list some common ones, like the root nameservers, or some well-known DNS servers?
Root servers? Probably not practical compared to searching elsewhere on the web. "Well-known"? Doubtful, or at least not without permission of their owners. Besides, if a user can reach Wikipedia, presumably they know the address of at least one nameserver already. — mendel☎ 07:12, August 21, 2005 (UTC)
Mendel, whats your beef? As a random user I can assure you it would improve the article 50% to provide practical information to the user. what is your goal? Trolling? Mrdthree (talk) 07:10, 28 April 2013 (UTC)
What on earth is a Human Organisation, and what has it got to do with DNS?
The beginning of the article contains the following line: ""Preeminently, DNS makes it possible to assign Internet destinations to the human organization or concern they represent, independently of the physical routing hierarchy represented by the numerical IP address."" So what exactly is the "human organisation". Should it be "human, organisation...." (comma inserted). Maybe this is better as a wording: " DNS makes it possible to assign the numerical Internet destinations to website names" —Preceding unsigned comment added by Although (talk • contribs) 07:39, 29 September 2007 (UTC)
Yes, they are a reality. It's all covered in another article, which this section referenced. To make it clearer, I add a Error: no page names specified (help). link to that article. Also, I updated this article's summary of the subject. Joeldbenson (talk) 21:53, 28 April 2013 (UTC)
Shouldn't this article include non-hierarchical and hypothetical DNS system types? Like P2P DNS for instance? — Preceding unsigned comment added by 64.6.141.115 (talk) 18:26, 5 July 2011 (UTC)
Why two "References" sections??
Am I the only one who noticed that a ==References== section was included at the top of the ===Nameservers=== section, in addition to the one at the end of the article, and that the references were divided among the two?
There are a number of organizations that provide public nameservers that are enhanced in various ways, like blocking malicious sites. Some of them are even the subjects of their own Wikipedia articles (e.g., OpenDNS and Google Public DNS). Apparently there was once a separate article listing such services, and a link to it here, but they were removed (see #Addition to See Also above). I'm thinking some mention of the subject would be appropriate in this article, and am considering boldly doing so. Joeldbenson (talk) 22:49, 28 April 2013 (UTC)
ARGH. "the" DNS.
As a unix sysadmin for the last thirteen years, having built and run nameservers for as long, I have to say I find it very grating to read repeatedly in the article such phrases as "History of the DNS". In reality, I know precious few people who *use* DNS who ever refer to "the" DNS. It is referred to simply as DNS. The 'the' is implicit when using the abbreviation. The article unfortunately vacillates between these two forms, exacerbating the jarring nature, at least to my ear. Oh, I'm sure someone will come along and point out that they've always said 'the DNS'. oh well. I'm contemplating conforming the entire article to drop the 'the' where appropriate. I'm open to discussion (obviously, else I'd have simply gone ahead and done it!). Anastrophe04:10, 9 July 2007 (UTC)
i've made the changes, in most cases simplifying "the DNS" to just "DNS", while in some places it was more appropriate to replace with "the Domain Name System" for clarity. also made minor changes to the description of the roots, and use of udp. Anastrophe05:53, 10 July 2007 (UTC)
And yet, in researching possible changes to this and other articles, I repeatedly see "the DNS" in the system's defining RFCs. Wikipedia articles are supposed to be formal. I don't believe in getting carried away with that, but we probably should be WRITING "the DNS". What sysadmins SAY when informally talking to each other is not really the appropriate criterion. That said, I at least will try to avoid it through careful structuring of my sentences (i.e., "DNS History" instead of "History of the DNS"). Joeldbenson (talk) 13:37, 30 April 2013 (UTC)
More info on how the DNS protocol works
I've been researching how the DNS protocol actually works (Header, Question, Answer, Authority, Additional), and it was hard to find sites with good information on this, does anyone else think the page would benefit from a more in depth explanation of the protocol? 88.108.251.218 (talk) 22:19, 11 November 2013 (UTC)
Seems like a bad rename (to "Services") to me; agree we should move it back. I have asked the person who did the rename to "Services" (Lysdexia) to please explain their rationale for their rename. Noel 18:27, 24 Oct 2004 (UTC)
Should be Domain Name System indeed -- Jacco Tunnissen, Dnssec.net
Hi, the article is mostly about the carrying out of the domain name resolution, and services has always been used for that effect. The system is the drawing out of how a service works. So the new revision describing the service as a system is wrong. lysdexia 17:09, 26 Oct 2004 (UTC)
If I understand you correctly, you seem to be saying (1) that the article is mostly about domain name resolution; and (2) domain name resolution is better known as "domain name services". Is that right? Point (1) is fair but the article does touch on the overall system and you must remember that this is Wikipedia and no article is finished. I think your point (2) is wrong, this is surely best known as "domain name resolution". My main concern is that "Domain Name System" is the most common name for the system, and what would Wikipedia have under that title if not a description of the system and the services it offers? Gdr 19:37, 2004 Oct 26 (UTC)
The system as a whole (architecture, protocols, servers, etc) is definitely known as the Domain Name System - see all the RFC's, etc. If some end-user computer has a subsystem which users/applications talk to is appropriately called the "Domain Name Services", and it deserves a page, fine. However, the Domain Name System (architecture, etc) richly deserves (nay, requires) a page - a page which would include, IMO, a description of how a name is resolved in it. Is there some content on the current page that you think would be inappropriate for an article named "Domain Name System"? What page would it properly belong on? Noel 04:58, 27 Oct 2004 (UTC)
DNS should be Domain Name System, it covers a wide variety of aspects of which a DNS service or server is only a part, albeit an important one. The RFCs should be considered the primary source in the definition here. --BenM 07:46, 28 Oct 2004 (UTC)
From RFC 1034 -- "This RFC is an introduction to the Domain Name System (DNS)..." 'nuf said! --calkid 16:34, 28 Oct 2004 (UTC)
Unless you somehow believe you know better than the likes of Jon Postel and Paul Mockapetris. --BenM 17:10, 28 Oct 2004 (UTC)
Huh? I think he was agreeing with you. Or are you implicitly responding to those who want to expand DNS to "Service"? Noel 21:29, 28 Oct 2004 (UTC)
The latter. That was a generic "you," not a specific "you." There was another part of that comment which I later removed which made it more clear, but may have been interpreted poorly regarding the person who prefers Services over System. --BenM 06:58, 29 Oct 2004 (UTC)
Domain Name System is not equivalent to Domain Name Service - Domain Name Service is the service that a DNS name server provides and Domain Name System is a system that contains many name servers ( machines programs ), the DNS protocol, etc D001ng (talk) 18:36, 21 June 2011 (UTC)
![{\displaystyle ]]}](https://wikimedia.riteme.site/api/rest_v1/media/math/render/svg/09196d1f1ab31143bf7d6f1de80a80303db7dd01)
