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

21–30 of 52 posts

Re: Web Developer's Guide to DNS

#21

Post by _bfhp »

teddyh wrote: post #19
_bfhp wrote: post #15

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

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…

Thanks to you and bluejekyll! I am understanding it a bit better with the breakdown

Re: Web Developer's Guide to DNS

#22

Post by pm90 »

teddyh wrote: post #19
_bfhp wrote: post #15

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

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…

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> DiG 9.10.6 > cloudflare.com
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER
Why does cloudflare.com resolve to a different IP address than www.cloudflare.com?

Re: Web Developer's Guide to DNS

#23

Post by jjoonathan »

jrockway wrote: post #20
jjoonathan wrote: post #9

A special shout out to Lennart Poettering for recently breaking dig +trace! https://github.com/systemd/systemd/issues/5897

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

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.

Re: Web Developer's Guide to DNS

#24

Post by teddyh »

pm90 wrote: post #22
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…

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 > DiG 9.10.6 > cloudflare.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER Why does cloudflare.com resolve to a different IP address than www.cloudflare.com?

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

Probably because the IP addresses on cloudflare.com leads to a simpler web server which seems to only reply with redirects to www.cloudflare.com, and might not have any actual web pages.

Re: Web Developer's Guide to DNS

#25

Post by js2 »

jjoonathan wrote: post #23
jrockway wrote: post #20

Earlier quoted context omitted.

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

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.

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.

Re: Web Developer's Guide to DNS

#26

Post by inopinatus »

js2 wrote: post #25
jjoonathan wrote: post #23

Earlier quoted context omitted.

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.

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.

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.

Re: Web Developer's Guide to DNS

#27

Post by bluejekyll »

pm90 wrote: post #22
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…

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 > DiG 9.10.6 > cloudflare.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER Why does cloudflare.com resolve to a different IP address than www.cloudflare.com?

Based on the outage people noticed the other day with www.cloudflare.com, we actually know that www is delegated to other nameservers.

Notice that there is an SOA and NS records for www.cloudflare.com if you dig for them.

Given this, they can't just CNAME from one zone to the other (if they want to include additionals from the subzone). So my guess is that the resolution of cloudflare.com is relying on rules setup for an HTTP 301, as opposed to the relying on DNS aliasing.

Re: Web Developer's Guide to DNS

#28

Post by magila »

inopinatus wrote: post #26
js2 wrote: post #25

Earlier quoted context omitted.

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.

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.

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.

Re: Web Developer's Guide to DNS

#29

Post by spc476 »

bluejekyll wrote: post #12
vbezhenar wrote: post #6

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.

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

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

Re: Web Developer's Guide to DNS

#30

Post by moocowtruck »

magila wrote: post #28
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.

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…

yep this is the only way we're going to be able to drag linux into future, where maybe one day it actually will be year of the linux desktop
Post reply on HN