This is the talk page for discussing improvements to the Domain Name System article. This is not a forum for general discussion of the article's subject.
This article is within the scope of WikiProject Systems, which collaborates on articles related to systems and systems science.SystemsWikipedia:WikiProject SystemsTemplate:WikiProject SystemsSystems
This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet
This article is within the scope of WikiProject Citizendium Porting, a project which is currently considered to be inactive.Citizendium PortingWikipedia:WikiProject Citizendium PortingTemplate:WikiProject Citizendium PortingCitizendium Porting
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Pictures?
Diagrams would be helpful.
agreed, done - I've added two, but there are more to make...LionKimbro
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)[reply]
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)[reply]
What is a zone?
Define "zone", please. Mr. Jones 16:46, 14 Dec 2004 (UTC)
done - please let me know if the explanation is clearLionKimbro
How DNS works
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)[reply]
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)[reply]
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)[reply]
is a valid URL and has nothing to do with DNS.
Matteo 08:21, 2004 Dec 7 (UTC)
hosts file
I think what's referred to as "the HOSTS.TXT file" should be changed to "the hosts file", considering it's most often /etc/hosts on unix-like OSes, and [last time I checked] doesn't even have the .txt extension on Win32. --Midg3t 00:33, 12 Mar 2005 (UTC)
It was called "HOSTS.TXT" in the pre-DNS days 25 years ago. Samboy 22:12, 18 Mar 2005 (UTC)
And that bit is specific: the file that was retrieved was named HOSTS.TXT. Of course, after it was retrieved, it was renamed to whatever the local operating system required. — mendel☎ 00:56, Jun 16, 2005 (UTC)
Removal is appropriate, IMO -- Wikipedia is not a repository of links. If there's useful information at those sites that is relevant to the article but is not already mentioned, it should be included in the article — mendel☎ 00:55, Jun 16, 2005 (UTC)
Common Nameserver IP Addresses?
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)[reply]
Additions - Anycast mirrors and DNS RBL's?
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)[reply]
Types of DNS records - wikilinks
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)[reply]
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)[reply]
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)[reply]
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
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)).[reply]
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)[reply]
Don't Merge
Domain Name System is a long article which should discuss technical aspects of the system of domain names.
Domain Name should discuss only the names themselves, including the domain name market, daytrading domain names, domain name auctions, registrars snapping up expired domains, domain name tasting, domain name drops, and other aspects of this industry.
Setting domain names up
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)[reply]
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)[reply]
Contradicts "Canonical Name" on internationalization. Secondary and slave.
http://en.wikipedia.org/wiki/Canonical_name states that:
The maximum permitted length of an FQDN is 255 bytes, with an additional restriction to 63 bytes for each label within the domain name. The syntax of domain names is discussed in various RFCs — RFC 1035, RFC 1123 and RFC 2181. Any binary string can be used as the label of any resource record; a common misconception is that names are limited to a subset of ASCII characters.
But "DNS" article states that domain names are limited to a subset of ASCII.
One more issue is that "secondary or slave name servers" expression is used. BIND manual states that "The other authoritative servers, the slave servers (also known as secondary servers)", which looks like secondary is a mere alias for slave. If I'm assuming wrongly, a clarification on the difference in the article would be helpful.
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
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)[reply]
Recursive flag
It's probably a good idea to mention the "Recursion Desired" flag somewhere in the article. This is basically the flag that separates client-server DNS requests from server-server DNS requests. See also http://www.simpledns.com/help/index.html?df_recursion.htm
Registry-Registrar Model?
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)[reply]
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
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)[reply]
SPF records
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Aren't the IPs really binary?
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)[reply]
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)[reply]
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Let's add a simple, introductory example?
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 > en.wikipedia.org 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)[reply]
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://en.wikipedia.org. 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 en.wikipedia.org.
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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
Is there some reason why this is not mentioned in this article? Are there certain types of records that are not included in this article for a specific reason?
Thanks in advance for any input.
External links modified
Hello fellow Wikipedians,
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.
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)[reply]
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)[reply]
I was tempted to simply follow the suggestion and replace decentralized with distributed. But the followup sentence already describes the directory service as distributed. It appears that both are correct characterizations, taking the meaning of decentralized in its dictionary sense. As such it is probably a lot more meaningful to a general audience than distributed, which is a highly technical term. I think, I prefer to keep it as written, with the exception of adding a comma or and after hierarchical to separate the association of those characterizations. Kbrose (talk) 16:05, 4 February 2019 (UTC)[reply]
If the convention is to assume users will look this up in a dictionary then that is fine. In the literature (and standards?) there often is a difference [1]131.174.85.103 (talk) 16:46, 4 February 2019 (UTC) R.[reply]
This reference makes the case stronger for also retaining the decentralized description as this meshes with how the DNS hierarchy works. ~Kvng (talk) 15:00, 12 February 2019 (UTC)[reply]
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)[reply]
Semi-protected edit request on 27 December 2019
This edit request has been answered. Set the |answered= or |ans= 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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".
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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:[2] 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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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 Domain Name System (DNS) is a hierarchical and decentralized naming system for computers, services, or other resources connected to the Internet or a private network.
Would you please give me an example or two of what a "service" would be in this context? Or, perhaps, is there an existing Wikipedia article about services connected to the internet? Butwhatdoiknow (talk) 16:47, 26 October 2021 (UTC)[reply]
I think what that language is referring to is how some companies install different Internet services on separate physical servers and assign each server its own unique DNS name. "Service" in this context refers to the server side of any application that runs over the Internet. For each kind of client, there has to be a corresponding server that listens for requests from clients. So there would be one server called "www" listening for inbound World Wide Web requests, one server called "mail" listening for inbound email requests, and so on. --Coolcaesar (talk) 19:41, 26 October 2021 (UTC)[reply]
Butwhatdoiknow, you link the word "services" to the article Server-side as though the two were equivalent, but this is another example of exactly the problem with your other suggested edit. This form of misleading over-specificity is similar to a fallacy of composition, in that you're incorrectly assuming that a part is equivalent to or representative of the whole. Services provided "server side" are a portion of the services that are addressed by the DNS, but equally, "client side" and "peer to peer" services utilize the DNS. RLMcGinley (talk) 19:18, 27 October 2021 (UTC)[reply]
How to dumb down the lede
The problem, as I see it, is jargon. "Services" (and, while we're at it, "resources") may make sense to someone who can casually say "and of course, IP addresses of both IPv4 and IPv6 varieties." But what about the non-expert reader? Certainly we can (and do) get into the details in the article, and even in the lede. However, I suggest, the first sentence or two should be very basic. Here are two examples of what I have in mind from elsewhere on the web:
Please review the Wikipedia Manual of Style and WP:NOT. On Wikipedia, we do not oversimplify concepts for consumption by ten-year-old children in the childish manner that you are suggesting. Wikipedia is not a manual, guidebook, or textbook. We have Wikibooks and the Simple English Wikipedia for such situations. The current lead paragraphs are an accurate and lucid explanation of the DNS. --Coolcaesar (talk) 16:44, 27 October 2021 (UTC)[reply]
Butwhatdoiknow, I'll be a little less blunt, but I agree with Coolcaesar: the purpose of Wikipedia is not to assume that readers are "dumb," as you put it, but to assume that they are intellectually curious. We use plain language, and we document the truth. In your attempt to "dumb down" the information, you have stripped the vast majority of the truth from the sentence, leaving only a bare thread of content remaining, not nearly sufficient to summarize the article. You summarize only a tiny portion of the article, whereas the existing text summarizes a more substantial portion of the article and does not pretend to a false completeness or specificity, which your proposed wording does. By analogy, you've replaced a sentence which says that "postal services deliver mail and packages, and in some countries perform banking services," with "postal services deliver letters in white envelopes to people named John." While you may regard it as more accurate, it is actually misleadingly over-specific. RLMcGinley (talk) 18:57, 27 October 2021 (UTC)[reply]
![{\displaystyle ]]}](https://wikimedia.org/enwiki/api/rest_v1/media/math/render/svg/09196d1f1ab31143bf7d6f1de80a80303db7dd01)
Moved from WP:RFPP
Done, thank you very much! 
~ ToBeFree (talk) 20:03, 18 July 2021 (UTC)