[HN Gopher] The Top of the DNS Hierarchy
___________________________________________________________________
The Top of the DNS Hierarchy
Author : mrzool
Score : 118 points
Date : 2024-02-25 13:10 UTC (9 hours ago)
(HTM) web link (computer.rip)
(TXT) w3m dump (computer.rip)
| hardaker wrote:
| You may wish to additionally read the history of the Root Server
| System, which was written by the Root Server Operators and
| provides significant more context and facts about it's
| development:
|
| https://www.icann.org/en/system/files/files/rssac-023-04nov1...
|
| Another helpful document that explains why the diversity of Root
| Server Operator organizations is a good thing can be found in
| this document as well:
|
| https://www.icann.org/en/system/files/files/rssac-042-17may1...
| teddyh wrote:
| > _BIND used to stand for Berkeley Internet Name Domain_
|
| Surely "Berkeley Internet Name Daemon"?
| WarOnPrivacy wrote:
| I'm running into so many multipurpose acronyms lately I'm
| wondering if we shouldn't start nesting them or something.
|
| As an aside, why do you " and not " ? App thing?
| teddyh wrote:
| " is an ASCII abomination, and should only be used when
| absolutely necessary.
| silverquiet wrote:
| Do you mean acronym collisions? I think that might just be
| part of getting older; I started complaining about it around
| 30, but I am a bit of a complainer anyway.
| rascul wrote:
| > Surely "Berkeley Internet Name Daemon"?
|
| The Berkeley Internet Name Domain Server
|
| https://www2.eecs.berkeley.edu/Pubs/TechRpts/1984/5957.html
| teddyh wrote:
| I stand corrected.
| c22 wrote:
| _named_ is the BIND daemon.
| WarOnPrivacy wrote:
| > everything is a subdomain of something, even "rip" itself,
| which in a certain sense is a subdomain of the DNS root "."
|
| Now that he's explained it, I'm annoyed that we use . to
| represent the root zone and to delimit between zones. Pick a lane
| already.
| p4bl0 wrote:
| Why? We do the same thing with file path for example, with /
| being both the root and the separator. In both cases you can
| think of the character as the separator if you prefer it to
| have a single role, and then the root is just the empty string.
| c0pium wrote:
| Oh, or we could add drive specifiers (maybe letters for ease
| of typing?) and then a reserved character before the root
| path separator to signify the change in context.
|
| Something like c:/dir_name could really take off...
| packetlost wrote:
| I find this snarky comment hilarious while also being
| disgusted at the implication
| bombcar wrote:
| www.example.com.c:
| somat wrote:
| I laughed, but wanted to acknowledge that the single tree
| filesystem is a pretty great invention. I like how the plan
| 9 ethos is "if it's a tree, it goes in the filesystem
| somewhere" dns.. in the filesystem. html dom? looks like a
| tree to me, in it goes.
|
| And I think this is the fundamental problem with the
| windows registry. Because it sounds like a really great
| idea. "A dedicated database to store all configs in"
| However in reality it sort of sucks. I think this is
| because now you have a second strange tree that has
| different special access methods and usage.
| somat wrote:
| An interesting functional distinction between the unix
| filesystem hierarchy and the DNS hierarchy. is that in the
| unix filesystem directories are distinct named entities and
| in DNS there is no such concept(closest you get are glue
| records)
| kidmin wrote:
| Actually the root is a null (empty) label rather than "."; dots
| are delimiters of labels, there is an empty label after "." in
| FQDNs. See RFC 1034 Section 3.1.
| c0pium wrote:
| Having all addresses be rooted in an untypeable null isn't
| much better.
| jesprenj wrote:
| It is not null, it's an empty string.
| calvinmorrison wrote:
| One thing that surprises me is that there isn't more competition
| in this space. Alternate domain name systems by the Post
| COMINTERN bloc or something
| p4bl0 wrote:
| The OpenNIC project [1] maintains an alternative DNS root and
| supports a few alternative TLDs: .bbs, .chan, .cyb, .dyn,
| .geek, .gopher, .indy, .libre, .neo, .null, .o, .oss, .oz,
| .parody, and .pirate.
|
| My personal web page is available at
| http://pablo.rackham.pirate/ for users of this alternative root
| =). I don't have a TLS certificate for it thought, because it's
| not supported by Let's Encrypt (same problem with my .onion
| address, but it's less of a problem because traffic is e2e
| encrypted anyway over Tor).
|
| Also, I don't know if there is any conflict with the new TLDs
| that were introduced by ICANN in 2015. I hope not :).
|
| [1] https://www.opennic.org/
| bombcar wrote:
| Weirdly enough apparently there are a few SSL cert issuers
| who will issue for .onion - maybe they would issue for
| OpenNIC.
| p4bl0 wrote:
| Oh I'm sure that if you're willing to pay for a certificate
| you can get one for pretty much anything you want. I was
| specifically talking about Let's Encrypt :).
| overstay8930 wrote:
| Why? Rerooting will just only cause problems to solve a
| solution that doesn't need to be solved.
|
| The only places that are offended by how America-centric DNS
| is, don't actually care since they're already blocking anything
| they don't like.
|
| It's hard to even have a DNS Root in Europe with how many
| European countries have normalized internet censorship. NetzDG
| would have caused an actual implosion of America if it ever
| existed here.
| hardaker wrote:
| You may wish to read [RFC2826] which the Internet Architecture
| Board of years past wrote on why a unified name space is
| important for the Internet.
|
| [RFC2826]: https://www.rfc-editor.org/rfc/rfc2826
| zrm wrote:
| That isn't necessarily incompatible with alternate domain
| name systems. If OpenNIC is registering names under .pirate
| and ICANN is aware of this then it can simply refrain from
| using .pirate as a TLD and you still have a unified
| namespace. It just happens by consensus rather than central
| authority.
|
| If they would get along a little better then you might even
| have the ICANN root servers direct queries for those TLDs to
| the OpenNIC servers. It's not obvious what benefit is
| achieved by not doing this.
| toast0 wrote:
| Alternate roots are basically unusable. Either your domain
| names are universally accessible, or someone needs to follow
| specific instructions to use them, in which case why use
| AlterNIC or OpenNIC, when you could just give instructions that
| were specific to your chosen domain name?
|
| Regardless of your grievences with ICANN, nearly universal
| consensus is almost certainly worth the price of using an ICANN
| delegated top level domain.
| zrm wrote:
| > Either your domain names are universally accessible, or
| someone needs to follow specific instructions to use them, in
| which case why use AlterNIC or OpenNIC, when you could just
| give instructions that were specific to your chosen domain
| name?
|
| In theory there is a network effect. If it got popular
| enough, there is a possibility that major operating systems
| or browsers or recursive nameservers might start supporting
| one of the alternatives, which is never going to happen with
| a bespoke individual domain name.
| zokier wrote:
| Afaik Russia has its own DNS roots under their "sovereign
| internet" program, see for example "3. The Implementation of a
| Russian National Domain Name System (DNS)" here:
| https://dgap.org/en/research/publications/deciphering-russia...
|
| I would assume that Chinese have similar capability, maybe some
| other countries too.
| jesprenj wrote:
| > Even if a root server were to experience a major failure due to
| some sort of administration problem, there are twelve more.
|
| This usually does not help in case of DNS. Let's say a resolver
| queries a root that does not reply. The resolver will time out
| after n seconds and then try another root server, but will not
| send any replies to the querying client. Therefore, the querying
| client has no way to know if it's the resolver that is broken or
| the upstream authoritative server and the querying client itself
| will timeout after m seconds and switch to another resolver,
| ignoring any possible later response from the first initialized
| query.
|
| If m is larger or equal to n, the problem is aparent -- client
| will never know if the root is broken or the resolver, usually
| treating the resolver as such.
| fanf2 wrote:
| Traditionally (in the Berkeley code) the timeouts in the stub
| resolver in libc are 3x longer than the timeouts in the
| iterative resolver in the recursive server. I don't think this
| is specified or that the RFCs even have much to say about
| timeout periods or retry counts.
| mike_d wrote:
| Maybe for a query or two, but the problem sorts itself out.
|
| Auth servers are very rarely running from a completely cold
| cache. Additionally most resolver software uses a system called
| scoreboarding where response times for each IP are recorded and
| it will prefer the fastest known nameserver for a query (some
| number of queries are still periodically sent to "slower" or
| unknown servers to gather metrics for them).
|
| Clients never treat a system resolver as "broken." Most
| operating systems will round-robin the list of available
| recursive servers when there is a timeout before returning
| failure to the software. In the case of web browsers and such,
| they'll retry with a resolver operated by the browser vendor
| before admitting defeat.
| spenczar5 wrote:
| This is a wonderful piece of writing. Clear, interesting asides,
| a complex subject covered in detail, internal sub-dramas with
| actual suspense. In the SEO and LLM text age, when so much
| writing is just a thinly disguised marketing attempt, this is so
| delightful. More like this, please!
| aftbit wrote:
| Read more of computer.rip. It's all in this style.
| pests wrote:
| Seconded. I've read through the entire archive. He gets on
| some very interesting tangents and I've learned a lot of
| weird things.
| zrm wrote:
| > I doubt they thought they'd take down the root servers, but it
| seems totally reasonable that they might have wondered if the
| root server operators would filter DDoS traffic based on the
| domain name appearing in the requests.
|
| Which wouldn't have worked even if it worked.
|
| When a recursive nameserver asks the root servers for the address
| of "916yy.com", the root servers are just going to direct it to
| the _.com_ servers. Which the recursive nameserver already knows
| when it has the address of the _.com_ servers cached, as would be
| the case >99% of the time, and would ask them directly instead
| of bothering the root servers to begin with.
|
| Even in the rare case when the recursive nameserver doesn't have
| the address of the _.com_ servers cached yet, that condition
| would last for approximately zero seconds before someone tries to
| resolve some other .com domain name and it gets cached, typically
| for at least a day.
___________________________________________________________________
(page generated 2024-02-25 23:01 UTC)