Live data from Hacker News

DNS Explained – How Domain Names Get Resolved

bhusalmanish.com.np

41–50 of 54 posts

Re: DNS Explained – How Domain Names Get Resolved

#41
post #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…

You'd still need to memorize the IP address without DNS, otherwise how would you know to which server to connect?

The fact that a server can serve multiple vhosts and do TLS cert selection via SNI is not related to the lookup of what server to connect to.

Re: DNS Explained – How Domain Names Get Resolved

#42
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…

> It's the people who think they are clever and try to make things better by making them worse.

you mean DNSSEC, right? RIGHT?

Re: DNS Explained – How Domain Names Get Resolved

#43
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…

> It's the people who think they are clever and try to make things better by making them worse. you mean DNSSEC, right? RIGHT?

I didn't actually. :). I meant people who change their DNS server or client (usually server) to do "clever" or "more efficient" things.

DNSSEC at least has its own RFC and uses the TXT record, which was added to DNS specifically for this kind of use case.

Re: DNS Explained – How Domain Names Get Resolved

#45
post #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

https://www.dnsperf.com/#!dns-resolvers

https://github.com/cleanbrowsing/dnsperftest

Re: DNS Explained – How Domain Names Get Resolved

#46
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…

> It's the people who think they are clever and try to make things better by making them worse. you mean DNSSEC, right? RIGHT?

How should we make DNS secure, and why aren't you tptacek?

Re: DNS Explained – How Domain Names Get Resolved

#47
post #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…

You'd still need to memorize the IP address without DNS, otherwise how would you know to which server to connect? The fact that a server can serve multiple vhosts and do TLS cert selection via SNI is not related to the lookup of what server to connect to.

You'd still need to send a Host header for the website you want and you can't do that in the address bar.

Re: DNS Explained – How Domain Names Get Resolved

#48

> 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

To avoid centralisation, I suggest running your own resolver. 1.1.1.1 censors a lot of places.

Re: DNS Explained – How Domain Names Get Resolved

#49
post #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…

You'd still need to memorize the IP address without DNS, otherwise how would you know to which server to connect? The fact that a server can serve multiple vhosts and do TLS cert selection via SNI is not related to the lookup of what server to connect to.

Just connect to cloudflare /s

Re: DNS Explained – How Domain Names Get Resolved

#50
It might be worth mentioning the concept of "stub resolver" and clarifying a bit that a nameserver is a resolver. That might be being pedantic, but thought it might be worth clarifying that the difference conceptually may just be what the particular dns server answering the query is authoritative for, if anything.

One other thing that might be worth a mention is the concept of the OS' resolver and "suffix search order", with an example of connecting (https, ping, ssh, whatever protocol) to a host using just the hostname, and the aforementioned mechanism that (probably) allows this to connect to the FQDN you want. (Also, now that I type that, do you mention "FQDN" at all? If not, maybe should.)

On that note one final thought that occurs to me is the error/confound that may occur if a hostname is entered and is not resolved, but does resolve with one of the domain suffixes attached on a retry (particularly can be confusing with a typo coupled with a wildcard A record in a domain, for example.) I recognize that the lines that look like DNS records are not explicitly stated to be in a format for any particular dns server software, and even if they were, they're snippets without larger context so we don't know what the $ORIGIN for the zone might be, an adjacent concept you might want to explore, even if just for your own edification is that of the effect of a terminating "." at the end of a hostname, either at resolution or configuration time.

Just offering feedback that might help you add to the article.

Post reply on HN