Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Developer's Guide to DNS

rjzaworski.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Web Developer's Guide to DNS

#41

Post by inopinatus »

js2 wrote: post #40
inopinatus wrote: post #26

Earlier quoted context omitted.

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.

That’s beside my point. Dig isn’t a tool for diagnosing resolv.conf. It’s a tool for querying and diagnosing name server responses. I have no opinion on systemd nor its maintainer. Meta: this entire thread is even relevant to the story. Some folks just wanted to complain about systemd. It doesn’t make for interesting reading and lowers the discussion quality here.

Fortunately for the rest of us, no-one actually gets to own a thread and gatekeeper the discussion.

Re: Web Developer's Guide to DNS

#42

Post by 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

Re: Web Developer's Guide to DNS

#43

Post by teddyh »

kgoutham93 wrote: post #33
teddyh wrote: post #19

Earlier quoted context omitted.

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…

Assume that example.com and foo.example.com have different zone files which in-turn have different ns entries day ns1 and ns2. So if I query for the A record of foo.example.com will it be answered by ns2? If so can I assume that the .com tld server has entries for both example.com and foo.example.com? So, what are the practical application of zones? I can think of load balancing DNS queries as one.

> So if I query for the A record of foo.example.com will it be answered by ns2?

Yes, if I understand your example correctly.

> If so can I assume that the .com tld server has entries for both example.com and foo.example.com?

No. The .com zone only contains NS records for example.com. The NS records for foo.example.com exist in the example.com zone (and, for consistency, in the foo.example.com zone), but not in the parent .com zone, which knows nothing about any sub-zones.

Re: Web Developer's Guide to DNS

#44

Post by teddyh »

js2 wrote: post #42

> 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 base…

> [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.

Re: Web Developer's Guide to DNS

#45

Post by magila »

inopinatus wrote: post #39
magila wrote: post #28

Earlier quoted context omitted.

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 thing…

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.

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.

Re: Web Developer's Guide to DNS

#46

Post by kgoutham93 »

teddyh wrote: post #43
kgoutham93 wrote: post #33

Earlier quoted context omitted.

Assume that example.com and foo.example.com have different zone files which in-turn have different ns entries day ns1 and ns2. So if I query for the A record of foo.example.com will it be answered by ns2? If so can I assume that the .com tld server has entries for both example.com and foo.example.com? So, what are the practical application of zones? I can think of load balancing DNS queries as one.

> So if I query for the A record of foo.example.com will it be answered by ns2? Yes, if I understand your example correctly. > If so can I assume that the .com tld server has entries for both example.com and foo.example.com? No. The .com zone only contains NS records for example.com. The NS records for foo.example.com exist in the example.com zone (and, for consistency, in the foo.example.com zone), but not in the pa…

Thanks, but where are zones used in practice?

Re: Web Developer's Guide to DNS

#47

Post by js2 »

teddyh wrote: post #44
js2 wrote: post #42

> 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 base…

> [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 m…

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?

Re: Web Developer's Guide to DNS

#48

Post by teddyh »

kgoutham93 wrote: post #46
teddyh wrote: post #43

Earlier quoted context omitted.

> So if I query for the A record of foo.example.com will it be answered by ns2? Yes, if I understand your example correctly. > If so can I assume that the .com tld server has entries for both example.com and foo.example.com? No. The .com zone only contains NS records for example.com. The NS records for foo.example.com exist in the example.com zone (and, for consistency, in the foo.example.com zone), but not in the pa…

Thanks, but where are zones used in practice?

Zones are used to split DNS data into zones of responsibility. I.e. when you want different administrative entities to have control over different sets of names, you put the names in different zones, served by different name servers controlled by those different administrative entities. If a company would split, say, the HQ and research department into separate subdomains "hq.example.com" and "research.example.com", and if they made those two subdomains into separate zones, each department could have their own name servers and each department’s name server administration team could add and delete server host names in their own zone all day long without risking breaking anything for the other department, and without even involving anyone else.

More practically, the "com" and "net" zones are managed by a different company than, say, the zone for "ibm.com", therefore they are in different zones. Also, the root zone (".") and all the country-specific zones like "se" or "de" are certainly managed by different entities (governments), therefore the root zone is separate from those individual country-specific zones.

Re: Web Developer's Guide to DNS

#49

Post by teddyh »

js2 wrote: post #47
teddyh wrote: post #44

Earlier quoted context omitted.

> [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 m…

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?

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...

Re: Web Developer's Guide to DNS

#50

Post by Terretta »

aspencer8111 wrote: post #31
teddyh wrote: post #3

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 th…

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

A confused explanation gets halfway round the world before a valid explanation gets its pants on.
Post reply on HN