
Web Developer's Guide to DNS - rjzaworski
https://rjzaworski.com/2019/04/the-web-developers-guide-to-dns
======
teddyh
A few issues:

• The description is a bit vague, but the article seems to describe a model of
a stack of resolvers, each resolver asking the next one in turn, the last
resolver getting an answer, and the answer being then passed down the chain
again. But this is _not_ how it works. For a normal DNS query, there is ever
only _one_ resolver involved. This one resolver is the single thing asking
many authoritative servers the same question, each time getting names of
servers who might know the answer, and ultimately getting an actual answer.
There is no stack of resolvers.

• The article completely conflates the process of a cached record expiring due
to TTL expiration, with the process of an updated zone with a new serial
number being transferred to slave servers. These two things have virtually
nothing in common.

I also found the illustrations too detailed (i.e. confusing for non-experts).
There are a lot of options to "dig" which could have been used to cut down on
the extraneous output when illustrating a particular point.

The zone file was especially confusing, in that none of it was explained, and
the nature of the DNS data model would have been much better illustrated with
an object diagram of some kind.

~~~
aspencer8111
Someone spends a shit ton of time explaining a new and complex concept.

Top comment is someone else ripping it apart. Yep. Welcome to Hacker News.

Can we please try to spend a week not using the following terms:

A few things, a few issues, actually..., I agree but, or anything else that
makes you feel superior by shitting on someone else

~~~
hnuser123456
No? If the article has issues, and you have domain-specific knowledge to
correct it, please share to the benefit of all of us. Just because there are a
few issues doesn't mean the whole thing was a waste, especially if it
motivated an expert to share.

------
pooya72
I've also found this guide to be really helpful:
[https://howdns.works/](https://howdns.works/)

------
detcader
What background does one need to understand the "4.4.8.8.in-addr.arpa"
paragraphs? I'm a career web developer who took a networking course many years
ago but "timely inversion," "DNS zone," what "public" means as an adjective
for a DNS server, "hop," and "block of IP addresses" are all presented like
I'm supposed to intimately know them already...maybe I'm just missing
something

~~~
teddyh
The article is not actually explaining it, merely obliquely hinting at it.

If you want to look up an IP address and get a server name (i.e. the reverse
of a normal DNS lookup where you look up a name and get a DNS record
containing an IP address), you do a “reverse” DNS lookup. Since the DNS
protocol does _not_ support this operation directly, this is enabled by a
somewhat ugly hack, namely the transformation of the IP address into a name,
which you can then look up and get a DNS record containing a name.

For example:

foo.example.com. A 192.0.2.3

is a name with an attached DNS record containing an IP address. To do a
reverse lookup, we transform the address into the name “3.2.0.192.in-
addr.arpa”, and look up not the A record (containing an address) for that
name, but the PTR record, containing a name:

3.2.0.192.in-addr.arpa. PTR foo.example.com.

You can think of DNS record types (A/PTR/MX/etc.) as types or classes in a
programming language. What data a DNS record can contain, and what that data
should mean, is controlled by the record type.

This is the essence of it. There are always various minutiae one could get
into, like the fact that IPv6 has a separate procedure to transform addresses
into names, and, just as a name can have more than one address, the lookup of
one address can result in more than one name.

To directly answer your questions:

• “Timely inversion” is not used as a technical term, it’s just a cute way of
referencing the transformation procedure for an IP address into a name able to
being looked up in the DNS.

• A “zone” is technically a collection of DNS records, restricted to a
particular domain or subdomain. For example, the zone for “example.com” would
normally contain all DNS records for not only “example.com”, but also the
records for the names “www.example.com” and “foo.example.com”. The purpose of
zones is that a zone is the mechanism by which the responsibility to respond
to queries about DNS data is delegated to DNS servers. If you want questions
about some names to be answered by some special DNS servers, you have to put
those names in a separate zone. This is unusual but not unheard of – the other
day¹ Cloudflare had problems related to the fact that they have actually
delegated “www.cloudflare.com” to separate name servers from the name servers
which are authoritative for the “cloudflare.com” zone. I.e.
“www.cloudflare.com” is its own zone. Note however that this is unusual. You
can tell if something is its own zone by the presence of an SOA record (and NS
records) on the name; www.example.com does _not_ have an SOA record, but
www.cloudflare.com _does_.

• “Public” in this context simply means “for use by the public” or “publicly
accessible”. And it’s strictly speaking a DNS _resolver_ , not an
authoritative DNS server for any specific zone or zones.

• The use of the word “hop” is, I believe, a further indication of the belief
by the author in the stack-of-resolvers model, but this is a false belief.
What actually happens is that a resolver asks one authoritative server
(starting with the root servers), receives as a reply a list of better servers
to ask, and the resolver asks those authoritative servers in turn. This is the
actual “hop” referred to in reality.

• A “block” of IP addresses is a contiguous span of IP addresses. IP addresses
are not allocated to organizations or ISPs around the world randomly or
individually, but are instead delegated into as large and as contiguous spans
as is possible. This is because the routing tables in routers are composed of
lists of spans of IP addresses, and it is _vital_ to minimize these lists,
because if the core routers run out of memory, no more addresses can be
routed.

1\.
[https://news.ycombinator.com/item?id=19641155](https://news.ycombinator.com/item?id=19641155)

~~~
pm90
For the cloudflare case, I found this interesting:

    
    
       dig www.cloudflare.com
    
      ; <<>> DiG 9.10.6 <<>> www.cloudflare.com
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38923
      ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    
      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 512
      ;; QUESTION SECTION:
      ;www.cloudflare.com.  IN A
    
      ;; ANSWER SECTION:
      www.cloudflare.com. 16 IN A 104.17.210.9
      www.cloudflare.com. 16 IN A 104.17.209.9
    
      ;; Query time: 14 msec
      ;; SERVER: 75.75.75.75#53(75.75.75.75)
      ;; WHEN: Sat Apr 13 14:46:25 PDT 2019
      ;; MSG SIZE  rcvd: 79
    
    
       dig cloudflare.com
    
      ; <<>> DiG 9.10.6 <<>> cloudflare.com
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16630
      ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    
      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 512
      ;; QUESTION SECTION:
      ;cloudflare.com.   IN A
    
      ;; ANSWER SECTION:
      cloudflare.com.  536 IN A 198.41.215.162
      cloudflare.com.  536 IN A 198.41.214.162
    
      ;; Query time: 73 msec
      ;; SERVER: 75.75.75.75#53(75.75.75.75)
      ;; WHEN: Sat Apr 13 14:46:47 PDT 2019
      ;; MSG SIZE  rcvd: 75
    
    

Why does cloudflare.com resolve to a different IP address than
www.cloudflare.com?

~~~
aasasd
In a sort-of-related curio, IBM still keeps around their bunch of
“www2.ibm.com” subdomains or something like that—likely because some links
around the web are pointing to them. Afaict these addresses were used as ‘poor
man's’ load balancing before multi-tier backends became the norm.

~~~
kalleboo
One amusing form of poor-man's load balancing was in the original Netscape 1,
which had hard-coded rules for certain netscape web servers where it would
automatically generate www1/www2/etc subdomains randomly

------
js2
> When you hit “save”, the serial number (se) incremented to reflect the
> change. As clients everywhere evicted their last-retrieved cached copy of
> the pets.com zone, your new change (with its new serial) bubbled out across
> the internet, and some indeterminate time later it finished going “live”.

This sorta implies the serial number has something to do with the caching
mechanism, but it doesn’t. Record caching is based on the record TTLs only
(which the author later mentions).

The serial number was originally used by the BIND master/slave replication
mechanism for zone files (so called “zone transfers”[0]), which occur out of
band of normal DNS lookups. Other name servers could use it for similar
purposes, since the serial number is required in the SOA record, but I don’t
know if an so. (In fact, the formatting shown for zone files is specific to
BIND. Other name server implementations have their own ways of storing the
zone records.)

This entire piece is written in a way that gives me a feeling that the author
doesn’t fully understand DNS.

That said, I do somewhat blame the original DNS RFCs. For a long time BIND was
the only name server implementation, and the RFCs themselves reflect this with
RFC 883 and its updates being as much about BIND itself as about DNS. The DNS
RFCs are kinda unusual in that way. It would be like there being an RFC for a
specific httpd implementation as part of the http RFCs.

[0] [https://cr.yp.to/djbdns/axfr-notes.html](https://cr.yp.to/djbdns/axfr-
notes.html)

~~~
teddyh
> [The article] _sorta implies the serial number has something to do with the
> caching mechanism, but it doesn’t._

I agree, as I said yesterday in my sibling comment.

> _In fact, the formatting shown for zone files is specific to BIND._

No, the format is a _standardized_ (defined by RFC 1035 section 5)
serialization format for zone data, called _Master File_ format. It is used as
an interchange format for zone file data.

It may (or may not) have originated with BIND, but that is beside the point.
It is not, and should not be seen as, being specific to Bind in any way. Is is
analogous to JSON for DNS data.

~~~
js2
As I wrote, RFC 883 and its updates (such as 1035) are an odd mix of DNS
specifications and BIND implementation details. Which servers besides BIND use
that master file format?

~~~
teddyh
Wikipedia says¹:

“[Master file format] _has been widely adopted by other DNS server software –
though some of them (e.g. NSD, PowerDNS) are using the zone files only as a
starting point_ […]”

1\.
[https://en.wikipedia.org/w/index.php?title=Zone_file&oldid=8...](https://en.wikipedia.org/w/index.php?title=Zone_file&oldid=863467828#File_format)

------
fillskills
In addition to the content, I really appreciated the site itself. Very simple,
easy to read and fast to load. Good work!

------
vbezhenar
I've recently found that DNS is surprisingly simple protocol, you can
implement simple query/response with very few lines of code. So if you want to
better understand it, you might want to code a simple client, may be even
recursive one.

~~~
bluejekyll
It seems simple on the surface, then you get into the various record types,
and edge cases to support.

~~~
spc476
You just need a decent library to parse DNS packets. [1] Yes, it's in C, but
it should be easy to interface to other languages given it only has two
functions.

[1] [https://github.com/spc476/SPCDNS](https://github.com/spc476/SPCDNS)

~~~
bluejekyll
I chose to write my own: [https://github.com/bluejekyll/trust-
dns](https://github.com/bluejekyll/trust-dns)

And, it in theory can be used in other languages via C FFI as well, since it’s
in Rust.

------
mobilemidget
suggestion, add section explain OS hosts file. When, why, how to use and how
bypasses dns lookup.

------
shaohua
nice!

------
jjoonathan
A special shout out to Lennart Poettering for recently breaking dig +trace!

[https://github.com/systemd/systemd/issues/5897](https://github.com/systemd/systemd/issues/5897)

~~~
jrockway
It sounds like the underlying issue is that people think DNS resolution linux
works like:

1) Read resolv.conf 2) Send DNS packets directly to one of the named servers.

But that is never how it worked. Linux has always had the wacky NSS plugins
that are involved, and the underlying model ends up being:

1) glibc or similar reads resolv.conf 2) glibc or similar does random stuff
depending on a variety of other files 3) good luck if you aren't using glibc
(go implements its own DNS stack, for example)

This would be a Linux rant, but OS X is also crazy and I imagine all other
OSes are too.

The underlying issue is that "name resolution" and "DNS" are not exactly the
same thing. There are all sorts of other things people expect to be able to
use for name resolution, like mDNS. (I recall using LDAP and yp at some points
in the past.) Thus, expecting a DNS trace to work for all "name resolution" is
folly.

If you want to dig +trace to work, just point it at a DNS server with the @
argument. dig is a DNS client, not a _name resolution_ client.

~~~
jjoonathan
The fact that linux (and OSX and Windows) support mechanisms of name
resolution other than resolv.conf has zero bearing on dig's previous utility
as a resolv.conf diagnostic tool, zero bearing on the fact that systemd
changed the behavior of a nonrecursive query for root zone NS records, and
zero bearing on the fact that Poettering insisted that this wasn't a problem
instead of fixing it.

~~~
js2
dig is not a resolv.conf diagnostic tool, it's a DNS lookup utility. I don't
think it even parses the full syntax of resolv.conf. Heck, it doesn't even
consider multiple nameserver statements.

~~~
inopinatus
It worked before, they broke it, and as usual the response is an egregious
"fuck you" and a queue of apologists castigating the aggrieved that they were
Doing It Wrong All Those Years And They Must In Future Conform To Only The
Approved Way.

This is why people loathe systemd.

~~~
magila
Something which is wrong but has mostly worked by accident is still wrong. A
tool which parses a config file it does not own and whose semantics do not
necessarily match what the tool expects is wrong. The blame for any breakage
which results is clearly on the tool in question.

Lennart has done more to improve Linux than all of his detractors on HN
combined in no small part because he is willing to break broken things and
force them to be fixed.

If the people whining about Lennart/systemd spent half as much time fixing
their shit as they did writing angry comments on the internet the Linux
ecosystem would be in much better shape.

~~~
inopinatus
It wasn’t broken, didn’t need fixing, and the config files existed before
systemd did, so claiming they “belong to a tool” really just exemplifies the
arrogance implicit in the whole project.

As for contributing, no, you don’t get to piss in the well and then demand
everyone drinks from it.

~~~
magila
I never claimed systemd owns resolv.conf so the fact that the latter predates
the former is irrelevant. resolv.conf is to be used to implement the resolver
API. Any tool which uses resolv.conf for any other purpose does so at its own
peril.

