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

31–40 of 52 posts

Re: Web Developer's Guide to DNS

#31

Post by aspencer8111 »

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

Re: Web Developer's Guide to DNS

#32

Post by hnuser123456 »

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

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.

Re: Web Developer's Guide to DNS

#33

Post by kgoutham93 »

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…

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.

Re: Web Developer's Guide to DNS

#35

Post by bluejekyll »

spc476 wrote: post #29
bluejekyll wrote: post #12

Earlier quoted context omitted.

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

I chose to write my own: 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.

Re: Web Developer's Guide to DNS

#36

Post by EpicEng »

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

Is the GP wrong? Of not then I don't see why you're bothered.

Re: Web Developer's Guide to DNS

#37

Post by yomly »

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

I don't see any tone in this reply which makes any personal attacks or even any major value judgements on the article itself such as "this is crap not even worth reading" as such I, the reader of both, am informed of an alternative explanation.

The author is then also invited to revise their article if they agree with the feedback.

Perhaps the grandparent could have thanked the author or opened with some positive feedback first, but given the grandparent took the effort to write detailed answers in a noncondescending tone, I see it as a quality informational post. I hope others do too.

Re: Web Developer's Guide to DNS

#38

Post by aasasd »

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?

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.

Re: Web Developer's Guide to DNS

#39

Post by inopinatus »

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…

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.

Re: Web Developer's Guide to DNS

#40

Post by js2 »

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.

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.

Post reply on HN