Talk:Domain Name System/Archive 2

This edit request to Domain Name System has been answered. Set the |answered= parameter to no to reactivate your request.

The statement that IETF published RFCs 882 and **3 is incorrect: these two RFCs were published in November 1983, predating the first IETF meeting, which was held in 1986 (I was one of the 21 attendees). LixiaZ (talk) 04:40, 27 December 2019 (UTC)

I cannot see any publisher's information in the RFCs and IETF was formed in 1986. The current wording is:

The Internet Engineering Task Force published the original specifications in RFC 882 and RFC 883 in November 1983.^[1][2]

Are there any opinions on wording for a possible change? Perhaps something like this:

The original specifications in RFC 882 and RFC 883 were published in November 1983.

A link to Paul Mockapetris is given in the preceding sentence. Perhaps the short paragraph above would be better if joined to the preceding paragraph. I temporarily disabled the edit request so a discussion about what to do can occur. At this time of year, we might need to wait a week or two for other views. Johnuniq (talk) 06:01, 27 December 2019 (UTC)

Either the above wording or a link to previous sentence as discussed would make sense. How about:

Mockapetris instead created the Domain Name System and the original specifications were published in RFC 882 and RFC 883 in November 1983

If you want to make either change or a similar one, I don't think it needs a full debate. The current wording is clearly not quite right, and if the new wording is not optimal, another editor can tweak it. Feel free to make a bold change. -- Sirfurboy (talk) 08:22, 27 December 2019 (UTC)

Does anyone know how I can set up my own domain name?

I mean, even the domain hosts have to get their one somewhere. -DalekClock

Most people just use domain registrars. Domain hosts just have access to high level DNS servers, and the Internic ones (the major world ones), and they can sort it out with them. Reedy Boy 13:02, 1 July 2006 (UTC)

I agree, setting up a domain name -- domain registration -- is almost always through a domain name registrar into a domain name registry. There's a list of some notable registrars at the bottom of those Wikipedia articles. Is there some way to improve this "Domain Name System" article to make it more obvious? --DavidCary (talk) 00:05, 14 January 2020 (UTC)

Now that most of us (Yanks, at least) agree with the Black Lives Matter movement, replacing the term "master server" with "primary server" and the term "slave server" with "secondary server" is recommended. The section to which I refer is "Authoritative name server." -SteveT (talk) 22:22, 20 June 2020 (UTC)

I agree with this, and its notable that neither RFC 1034 nor 1035 use the term slave, and instead use master/secondary. RFC 8499 mentions previous use in rfc1996 which seems to be the outlier. I think that it is also reinforced by the fact that BIND and NSD documentations use both forms interchangeably, with secondary appearing to be used more. There will need to be some mention though of the alternate terminology as many configuration and zone files still reference it. Strangerpete (talk) 23:30, 20 June 2020 (UTC)

I forgot to add the quotes from RFC 8499 which is the Best Current Practice:

"Although early DNS RFCs such as [RFC1996] referred to this as a "slave", the current common usage has shifted to calling it a "secondary"

"Although early DNS RFCs such as [RFC1996] referred to this as a "master", the current common usage has shifted to "primary".

With that said, I'll just go ahead and make the change Strangerpete (talk) 13:44, 21 June 2020 (UTC)

Nice; thank you! I added a reference to Wikipedia page Master/slave_(technology). -SteveT (talk) 00:47, 22 June 2020 (UTC)

Currently, the types of DNS resolvers are described as non-recursive, recursive and iterative. In my humble opinion, this distinction (without further explanation) is slightly confusing, as recursive and non-recursive should intuitively cover all the cases. In the RFC currently cited for this section^[1], iterative is used as a different possibility altogether, and the section explaining the recursive and non-recursive mode somehow "forget" about the iterative mode, if I see this right? Any suggestions about how this could be clarified a little more? Any other opinions on whether it needs clarification at all? Talitha 42 (talk) 17:58, 2 February 2018 (UTC)

IMO this section should be completely re-written. The word "iterative" doesn't occur at all in RFC 1035, and occurs only three times in RFC 1034, namely, on page 4. There it is clearly used as a synonym to "non-recursive". In the RFC, the terms "recursive" and "non-recursive" are only used to describe how DNS servers react to queries, not to describe how resolvers work.

As I understand it, resolvers always try to provide a definitive result, therefore providing "recursion" in a client application's point-of-view. They do this by iteratively querying other name servers, or by sending a recursive query to a DNS server that supports recursive queries (e.g. the DNS server provided by the ISP). — Preceding unsigned comment added by Mebuege (talk • contribs) 00:06, 25 August 2020 (UTC)

To clarify, I'm talking about this section: Domain_Name_System#DNS_resolvers Also, this may be helpful when rewriting the section: https://tools.ietf.org/html/rfc8499#section-6 Mebuege (talk) 15:45, 26 August 2020 (UTC)

I have nominated the (redundant) categories Category:Domain name system and Category:Domain Name System for merging at the former. Domain Name System has redirected here since May 2006. --RobertG ♬ talk 09:26, 16 March 2007 (UTC)

To save future readers of the page the trouble of looking into this, it has been done! Joeldbenson (talk) 21:46, 28 April 2013 (UTC)

And it was renamed to the capitalised version in 2020. – Fayenatic London 09:24, 31 August 2020 (UTC)

Just noting that in November 2020, ICANN published a report titled "The Creation and Administration of Unique Identifiers, 1967-2017" that may be very useful as a reference source for some of the historical info in articles related to DNS and other topics. - Dyork (talk) 11:53, 14 May 2021 (UTC)

Moved from WP:RFPP

 – ~ ToBeFree (talk) 20:01, 18 July 2021 (UTC)

This edit request to Domain Name System has been answered. Set the |answered= parameter to no to reactivate your request.

In the article "Domain Name System" section "Structure", please replace

"Although no technical limitation exists to use any character in domain name labels which are representable by an octet,"

with

"Although no technical limitation exists to prevent domain name labels using any character which is representable by an octet,"

Thanks 14.201.0.207 (talk) 16:08, 18 July 2021 (UTC)

 Done, thank you very much! ~ ToBeFree (talk) 20:03, 18 July 2021 (UTC)

Diagrams would be helpful.

agreed, done - I've added two, but there are more to make... LionKimbro

Thanx 218.208.247.5 (talk) 18:27, 28 August 2008 (UTC)

Thanx 218.208.247.6 (talk) 18:30, 28 August 2008 (UTC)

The French and German version of this article have the upper image and other languages (e.g. Polish) have variations thereof. Whereas this article in English has the lower one.

Why do we not use the German one (or a variation thereof)? Is it incorrect or misleading? To me, being someone who is learning about what a DNS is, the upper one is much clearer. How about making a fusion of the English and German ones with useful names in the ″resource records with associated name″ instead of scribbles? 89.157.239.36 (talk) 06:51, 24 November 2012 (UTC)

The image File:DNS_in_the_real_world.svg depicts how DNS worked for most people fifteen years ago, but is really no longer accurate for most people, most of the time. Not that many ISPs operate their own recursive resolvers anymore, and not that many people use the ones they do operate. So labeling the recursive resolver as though it's somehow inherently operated by the ISP is definitely inaccurate. If there are any serious objections, I'll drop it, but I'll see if I can't whip up a more accurate diagram to replace this one. EVhotrodder (talk) 14:47, 30 August 2021 (UTC)

The first sentence of this article says:

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)

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)

So we could say "... computers, services on computers, or other resources ..."? Butwhatdoiknow (talk) 21:31, 26 October 2021 (UTC)

We could say that, but I think the language that's currently there isn't bad. The DNS can encode a lot of different kinds of information, including services, "resources," locations, cryptographic keys of many types, identities of all sorts, names, and of course, IP addresses of both IPv4 and IPv6 varieties. So I don't see a clear case for trying to be either more exhaustive, nor more concise, in the opening sentence. Bill Woodcock (talk) 09:18, 27 October 2021 (UTC)

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)

I believe that a domain may have more than one IP address associated with it, and geoDNS uses geographic location of the caller to provide the IP address of the nearest data centre. Many large organisations have many web servers at each data centre, and the web traffic is balanced my multiple load balancers. Does each of these load balancers have it's own public IP address?, ie does the DNS issue multiple IP addresses for a website even for a single data centre? There is no mention of this practical information in the article.FreeFlow99 (talk) 16:28, 20 November 2021 (UTC)

@FreeFlow99: You've asked a number of questions, each of which has its own (not always simple) answer. I'll take them one-by-one:

...a domain may have more than one IP address associated with it...

Yes, that's correct, and more specifically, a single fully-qualified domain name (FQDN) may have more than one IP address associated with it. That may occur because it has both A and AAAA records (an IPv4 and an IPv6 address), or it may have multiple A and/or AAAA records associated, in which case the client which receives the records might have a choice to make about where to deliver their next packet.

...geoDNS uses geographic location of the caller...

Well... "GeoDNS" is jargon for a whole field of techniques generally referred to as geolocation. It's not a specific technology. There are networks like Akamai, which attempt to use the ECS parameter of a query, or failing that, the origin IP address of the transit interface of the recursive resolver which serviced the query, as one component in their decision about what A and/or AAAA record(s) to hand back in response to a query. They may be looking at the originating Autonomous System, at their return paths, at someone's guess as to the geographic location of the IP address, or at round-trip response times for that address or others in its BGP-advertised subnet. Or other factors, those are just the first few that spring to mind.

...to provide the IP address of the nearest data centre...

Well, first of all, as you point out later, datacenters don't have IP addresses, individual services have IP addresses. So, if we amend that to:

...to provide an IP address of a service hosted in the nearest data centre...

...then the answer would be "Well, sometimes they try to; sometimes not." As I said, there are many different factors that weigh into a decision on where to try to influence client traffic to route to. Even if one had an unambiguous geolocation for a specific ECS-supplied IP address, that still doesn't tell you what their path to a datacenter (of known location) is, and the geographically nearest may not be the topologically nearest, which is what matters. Which is why sensible networks use anycast rather than trying to make geolocation not fall on its ass too badly, since anycast gets you directly to the topologically nearest instance, without all of this room for error.

Many large organisations have many web servers at each data centre...

Yes, true of small organizations as well. Beneficial redundancy is good.

...web traffic is balanced my multiple load balancers.

"Load balancers" were something hucksters sold to clueless enterprise network buyers back in the 1990s, they've never been a thing in serious networks. They can be replaced with a patch-cord without loss in functionality and with considerable gain in MTBF. So I'll amend your next question to "servers" so we can dive back in:

Does each server have it's own public IP address?

Typically no. Typically each server has its own private IP address (whether that's "private" in the RFC1918 sense, or "private" in the "not advertised to the public in the DNS" sense) so that it can be managed, its cache stuffed, etc. But on the public-facing side, each service has exactly one IPv4 and one IPv6 address. There's no reason to have more than one address per service, it just complicates things without adding any value. And there's no reason for the same service on different servers to have different addresses, that again just complicates things without adding value.

...does the DNS issue multiple IP addresses for a website...

Yes, often hundreds, perhaps thousands. Every tracking bug, advertisement, etc., is going to have its own IP address, since they're all going different places. But I don't think that's what you meant when you asked the question.

...even for a single data centre?

Well, many of those services may be physically hosted in many of the same datacenters, but each is independent of the others, so that's just a coincidence. If what you mean to ask is:

Do instances of a service hosted on different servers within the same datacenter have different IP addresses?

...then the answer is no, not in a competently-run network that's functioning properly.

There is no mention of this practical information in the article.

Correct, because none of it has to do with the domain name system, it has to do with IP address assignment. The DNS is just how those IP addresses are communicated to users. The Anycast article would be a good reference, if you feel like pursuing this further. I'd be happy to try to answer any further questions, though, here or there. Bill Woodcock (talk) 17:24, 20 November 2021 (UTC)

Thanks Bill! Thanks for taking the time to constructively reconstruct my questions and answer them; that's very helpful.

Most of that sounds great, but I'm still puzzled. I worked in a .com a few years ago and it was putting in a load balancer to distribute traffic to a pair of IBM Data Power web appliances (which then go to a server farm if they don't have the appropriate web page, so that a server can create the page). I think in the old setup they used one or more load balancers to distribute traffic to 80 web servers. I read an article today about an Application Gateway Load Balancing Proxy FireWall that also provides session management, authenticating, and rate limiting. In the absence of a load balancer(s), how would traffic be distributed to web appliances and servers; by using DNS servers to serve up public IP addresses for the servers/services in a randomly distributed fashion? Feel free to divide and conquer the above questions. FreeFlow99 (talk) 17:50, 20 November 2021 (UTC)

The normal way to do it is to use anycast to get your traffic to both your DNS and your content. All your DNS servers serve the same consistent A and AAAA answer for each service, and each instance of each service has one consistent IPv4 address and one consistent IPv6 address everywhere. If the services support redirection, like web servers, they can choose to redirect long-TCP-session users to a unique address, and if a server becomes overloaded, it sends a BGP withdrawal to its adjacent router, removing itself from the pool that accept new connections. Load balancing is a function best done on the servers themselves, not by an extraneous middlebox, which just creates an additional serial point of failure. Which is great for people selling additional points of failure, but not so great for people trying to keep services running. Any large network then has an overlay of proprietary fine-tuning knobs, and DDoS countermeasures, and "traffic engineering," but all that's useless if you don't build a strong foundation. Bill Woodcock (talk) 21:04, 20 November 2021 (UTC)

Someone want to take a crack at fixing the protocol infobox, so it can display more than just the first nine relevant RFCs? Bill Woodcock (talk) 21:41, 28 November 2021 (UTC)

We should define "relevant" first - of the lump of RFCs you added (and besides the duplicates, I do see your point) more than a few are obsolete, drafts, historic, or experimental in the 90s, and a couple not even related (1750, 2133.) We clearly cannot show them all, and besides being a wall of numbers it isn't helpful to anyone to understand the protocol. I'd argue anything that isn't a standard or proposed standard, probably doesn't belong in the infobox.

I think one step to make it more navigable could be to split certain classes of RFCs into separate fields, such as Best Common Practices, which could be more helpful to a reader. Or separating core specification from extensions and experiments. Strangerpete (talk) 01:55, 29 November 2021 (UTC)

I agree with all that. I hadn't yet made any attempt to differentiate them; it was as much to make a point as anything else. My opinion is that an infobox isn't appropriate here, in that as-is it's overly reductive, and if it were fixed to be more inclusive, it would be in danger of becoming a catalog of the rest of the article, duplicative of the table of contents or index of RFCs. So, I guess my point is that I think that we should either remove the infobox, or put a heck of a lot more thought into it than has happened thus far. Bill Woodcock (talk) 09:41, 29 November 2021 (UTC)

Gotcha. In those terms, I support removing the infobox until both issues are settled, if at all. Since you added it @EidenNor, any thoughts? Strangerpete (talk) 14:49, 29 November 2021 (UTC)

DNS have 50+ RFC that are relevant to the protocol.

I agree we can't add all RFC, some RFC are "proposed standard", or less and still implement as a standard.

I think the RFC links is good way to go looking for more information, if we have a limitation of 9, then we need to pick the top 9.

I think for DNS that we should have the following:

• When was it first mentioned
• When was it officially a "standard"
• Add encryption
• Add Ipv6

https://www.google.com/search?q=site%3Atools.ietf.org+dns EidenNor (talk) 15:51, 29 November 2021 (UTC)

This edit request to Domain Name System has been answered. Set the |answered= parameter to no to reactivate your request.

please change "proximal" to "nearest to" Phrilly (talk) 10:54, 3 May 2022 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{edit semi-protected}} template. That would alter the meaning. ScottishFinnishRadish (talk) 11:55, 3 May 2022 (UTC)

The article states "The key functionality of the DNS exploited here is that different users can simultaneously receive different translations for the same domain name, a key point of divergence from a traditional phone-book view of the DNS." I don't know if its just that everyone is too young to remember how phones books worked, but that's exactly how phone books worked. If you looked up John Smith in a New York phone book, it would tell you the name the John Smith that lives in that area. It would be a different phone number than the one given for John Smith in California. Businesses worked the same way. If you wanted to call up IBM, you were going to get the phone number for the nearest IBM office. Do people think that phone books contained literally every single phone number and that they were all identical?

216.151.4.222 (talk) 04:49, 24 May 2022 (UTC)

Geo-location discriminant recursive resolution for example (something that comes to my mind). If you're resolving big-corp-domain.com around DE or NL, you'll unlikely gonna get the same result around the US or CA and JP or CN. --WikiLinuz {talk} 🍁 09:39, 25 May 2022 (UTC)

Also, DNS is a complex mechanism. It could be deduced into a "phone book" in a straightforward reductionist approach, but much more things get involved in reality. --WikiLinuz {talk} 🍁 09:43, 25 May 2022 (UTC)

In the first sentence of the article:

"The Domain Name System (DNS) is a hierarchical decentralized naming system"

refers to DNS as decentralized. In the rest of the article, the word 'distributed' is used.

• Is there a source for the use of 'decentralized' here?
• Can the word 'decentralized' be omitted, or is it bound to hierarchical?
• Should it also be replaced with 'distributed' here?

131.174.85.84 (talk) 14:51, 4 February 2019 (UTC) R.

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)

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.

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)

I replaced decentralized with distributed before noticing this existing discussion. Decentralized seems obviously wrong for a hierarchy with a central root, but I'm open to the idea that my definition of decentralized is not the same as that of a general audience, and won't be bothered if there's consensus for a revert. DefaultFree (talk) 02:15, 27 October 2022 (UTC)

The section "How the DNS works in theory" uses the term URL to define domain names. URLs can contain domain names but are not the same thing.

mailto:name@somedomain

is a valid URL and has nothing to do with DNS. Matteo 08:21, 2004 Dec 7 (UTC) — Preceding unsigned comment added by Corti (talk • contribs) 08:21, 7 December 2004 (UTC)

Define "zone", please. Mr. Jones 16:46, 14 Dec 2004 (UTC) — Preceding unsigned comment added by MrJones (talk • contribs) 16:46, 14 December 2004 (UTC)

done - please let me know if the explanation is clear LionKimbro — Preceding undated comment added 06:15, 26 October 2005‎ (UTC)

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) — Preceding unsigned comment added by Tedp (talk • contribs) 00:33, 12 March 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)

On 26 Apr 2005, a lot of highly relevant external links about the DNS system were removed by 220.225.129.125, see http://en.wikipedia.org/w/index.php?title=Domain_Name_System&diff=12851911&oldid=12847683 I think they should be restored, and like to receive input about this from others. -- JT 04/30/2005 — Preceding unsigned comment added by 217.77.131.3 (talk) 04:08, 1 May 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)

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. — Preceding unsigned comment added by Sokool (talk • contribs) 15:58, 21 April 2006 (UTC)

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. — Preceding unsigned comment added by 60.234.133.143 (talk) 14:45, 21 July 2006 (UTC)

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 — Preceding unsigned comment added by 82.92.174.89 (talk) 08:21, 2 September 2006 (UTC)

The following links should be considered for removal:

• Zytrax.com, Open Source Guide - DNS for Rocket Scientists, an on-line technical. WP:NOTADVERTISING WP:CONFLICT WP:ELNO
• A listing of some DNS tools WP:NOTADVERTISING WP:CONFLICT WP:ELNO
• CircleID - Open news and opinion hub for all DNS related topics WP:NOTADVERTISING WP:CONFLICT WP:ELNO

— Preceding unsigned comment added by 60.234.246.33 (talk) 11:59, 13 April 2010 (UTC)

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. — Preceding unsigned comment added by Brian Gragg (talk • contribs) 20:53, 18 August 2017 (UTC)