Live data from Hacker News

DNS Explained – How Domain Names Get Resolved

bhusalmanish.com.np

31–40 of 54 posts

Re: DNS Explained – How Domain Names Get Resolved

#31
post #20

The biggest issue with DNS is not the protocol, or even the reference implementation. It's the people who think they are clever and try to make things better by making them worse. The most egregious of course is ISPs rewriting TTLs (or resolvers that just ignore them). But there are other implementation issues too, like caching things that shouldn't be or doing it wrong. I've seen resolvers that cache a CNAME and the…

ISP DNS servers really ought to be banned, they are always so bad. I've seen traffic days later on a record with 1 hour TTL. In general I see like 50% traffic move after the initial 1-2x TTL interval, another 40-45% over next several hours up to one day, and then the last 5-1% can take forever. For round-robin, I've actually had it work reasonably well for API usage. Of course it's not ideal, but when I wanted to rol…

When I moved reddit from one datacenter to another, about 70% of the traffic shifted within the TTL. Another 20% moved within a week. Took till the end of a month after the change to get to about 98%

But after two months, about 1% was still going to the old server (I had set it up as a proxy for the cutover). Most of that traffic looked like crawlers that were written in things like Python or Ruby and had probably hard coded the IP or done something where it just didn't know what a TTL was.

So at that point I just shut down the old server.

You're probably right about API clients using better resolvers though. I was talking about consumer facing things where a lot of people would be on ISP DNS.

Re: DNS Explained – How Domain Names Get Resolved

#32
> Without DNS, you'd need to memorize IP addresses for every website.

This used to be true until virtual hosting came along, allowing for several domains to point to the same IP address, but only for non-HTTPS traffic. Then a bit later we got SNI (Server Name Indication) that did the same thing for HTTPS.

I remember having web servers with 10-12 public IP adresses when I started working. The number of IPv4 addresses needed has been greatly reduced since.

Re: DNS Explained – How Domain Names Get Resolved

#33

Only oddity was the reference to the "router cache". I agree if your browser tried to lookup example.com the local cache would be used, but then it would be the system's configured DNS server - and that would most likely be an ISP, rather than your local router. (Assuming a typical home connection, your router is _probably_ not a DNS server with local cache, it probably is a DHCP server which will hand out the upstre…

I would argue the contrary - most home routers are running a DNS server of some kind. They forward to upstream, but will resolve local names like your printer and whatnot. dnsmasq is the defacto tool on these embedded devices for dhcp+dns. probably a billion deployments. it's up there with sqlite for most used tech.

IIRC a resolver is what people would think of as a DNS server only it's not an authority for any domains. Like you said, they're used to get load off of authoritative servers and are very common. I think dnsmasq is mentioned explicitly in the O'Reilly locust book but it's been a while.

Re: DNS Explained – How Domain Names Get Resolved

#34
post #16

This is not a bad overview of DNS from a theoretical perspective. It’s also pretty well written and has good examples and figures. What I think is missing is a bit more of the “in practice” side. If the author was surprised about TTL values, I doubt they have much experience with some of the other pitfalls, so I’m not surprised (not a knock on the author). But there is a reason why the phrase “It’s always DNS” exists…

> it could be helpful to mention that ISP DNS resolvers (or any caching resolver in the path) could decide to ignore the TTL

not exactly the same but it reminds me of MTU. You can set it to whatever you want but it only takes one router that you don't control in the path to undo what you're trying to accomplish.

Re: DNS Explained – How Domain Names Get Resolved

#36
post #10

> DNS broke my site for three hours. But now I actually understand it I have been broken for three decades and I still don't understand DNS. It is a simple protocol but people use it in complicated manners.

Simple? Oh no. Simple it is not.

It's the most baroque protocol that is still somehow surviving from the initial Internet. There are so many weird limitations, like not being able to use CNAME for apex zones. Or the entire DNSSEC fiasco.

Re: DNS Explained – How Domain Names Get Resolved

#37
post #14

I have to admit - I still grind my teeth every time I see "dns propagation" used without a direct follow-up that it's a myth, you're looking at cascading cache expiry. Propagation might be a useful way to visualise it, but doesn't match reality unless every cache is a warm cache.

I grind my teeth every time I hear "I need an urgent DNS change" :/

Re: DNS Explained – How Domain Names Get Resolved

#39
> You can change which resolver you use in your network settings. I switched to 1.1.1.1 on my machines - it's noticeably faster than my ISP's default resolver.

Noticeably faster as in just loading a website? Or in some script where small differences add up? I thought typical DNS lookup was sub 100ms, but I've never tried switching my resolver so I'm curious

Re: DNS Explained – How Domain Names Get Resolved

#40

> You can change which resolver you use in your network settings. I switched to 1.1.1.1 on my machines - it's noticeably faster than my ISP's default resolver. Noticeably faster as in just loading a website? Or in some script where small differences add up? I thought typical DNS lookup was sub 100ms, but I've never tried switching my resolver so I'm curious

Curious how you’d measure this
Post reply on HN