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

11–20 of 52 posts

Re: Web Developer's Guide to DNS

#11

Post by tyingq »

teddyh wrote: post #10
tyingq wrote: post #8

Earlier quoted context omitted.

The Linux box could have a caching forwarder, as could the router. There are many routers with a local cache that put their own IP in the DCHP nameserver spot. And 8.8.8.8 may not know the answer, and may have to query for it, that's a very common "stack". A non recursive client letting a recursive server do the trawling is probably the most common home use case. You could put a recursive resolver on your Linux deskt…

Everything is possible in theory, of course, but all of these theoretical possibilities are relatively uncommon, and, more importantly, made to not look like the aforementioned chain-of-resolvers. The normal DNS procedure is client→resolver→authoritative_server, and any deviation from this is deliberately hidden by the components which alter it.

They aren't uncommon though. The most typical home setup has a non recursive client ask their ISP to resolve a name. The ISP, if it hasn't cached the answer prior, queries someone else on the client's behalf.

Separately, Windows, Linux (most popular distros), and MacOS all have a caching/forwarding local resolver.

Re: Web Developer's Guide to DNS

#12

Post by bluejekyll »

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.

Re: Web Developer's Guide to DNS

#13

Post by tyingq »

jjoonathan wrote: post #9

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

"poettering commented...This is really by design."

Oy. It worked before. I get his notion of not wanting to make it a full dns resolver, but breaking something that worked seems clear enough.

Re: Web Developer's Guide to DNS

#14

Post by xfitm3 »

teddyh wrote: post #10
tyingq wrote: post #8

Earlier quoted context omitted.

The Linux box could have a caching forwarder, as could the router. There are many routers with a local cache that put their own IP in the DCHP nameserver spot. And 8.8.8.8 may not know the answer, and may have to query for it, that's a very common "stack". A non recursive client letting a recursive server do the trawling is probably the most common home use case. You could put a recursive resolver on your Linux deskt…

Everything is possible in theory, of course, but all of these theoretical possibilities are relatively uncommon, and, more importantly, made to not look like the aforementioned chain-of-resolvers. The normal DNS procedure is client→resolver→authoritative_server, and any deviation from this is deliberately hidden by the components which alter it.

Gross over simplification. You can have multiple authoritative resolvers, such as in the case of stub delegation.

Re: Web Developer's Guide to DNS

#15

Post by _bfhp »

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

Re: Web Developer's Guide to DNS

#16

Post by teddyh »

tyingq wrote: post #11
teddyh wrote: post #10

Earlier quoted context omitted.

Everything is possible in theory, of course, but all of these theoretical possibilities are relatively uncommon, and, more importantly, made to not look like the aforementioned chain-of-resolvers. The normal DNS procedure is client→resolver→authoritative_server, and any deviation from this is deliberately hidden by the components which alter it.

They aren't uncommon though. The most typical home setup has a non recursive client ask their ISP to resolve a name. The ISP, if it hasn't cached the answer prior, queries someone else on the client's behalf. Separately, Windows, Linux (most popular distros), and MacOS all have a caching/forwarding local resolver.

You’re still not describing a stack; you are describing the normal three-step client→resolver→auth_server procedure. Your “non recursive client” is the client, the ISP has the resolver, and that resolver performs many queries to many authoritative servers, which is the final step. There is still only one resolver, not a stack of them.

A common variation, which might have been what you meant to describe, is that a home router is announcing itself as a resolver to the local network, but is, in reality, merely acting as a proxy to the actual resolver, either at the ISP or some other resolver provider. But a DNS proxy is not a resolver, and might not even have a cache. A DNS proxy is made to be transparent, i.e. invisible to both sides; the local network sees the proxy as the resolver, and the real resolver sees the proxy as the client. There are even more complex setups possible on the authoritative server side, but none of these proxy possibilities alter the fundamental DNS model of client→resolver→auth_servers.

The possibility of transparent proxies in any client-server protocol should not alter the description of that protocol from “client-server” to “client-proxy-proxy-proxy-…-server”, especially not when the protocol does not itself account for proxies. The DNS protocol has, inherently, one component between client and server: the resolver. There is no chain-of-resolvers model in the DNS protocol. The possibility of any number of transparent proxies at any point in the chain should not alter the description or explanation of any protocol.

Re: Web Developer's Guide to DNS

#18

Post by bluejekyll »

_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

I commend the author for attempting to make this subject more approachable to people less familiar with networking, but it’s always tough to present this and understand how much you need to explain.

- zone: you can think of as an SOA, start of authority, for a set of records. For example: there is an SOA record for example.com. In addition there are NS records that express what nameservers are responsible for being the authority, trusted server, of the zone. Often zones are expressed in a single file, and loaded into the authoritative server, and it contains all the additional records for the zone, like A address records.

- public: in this context probably is referring to the fact that it’s exposed and reachable from the greater internet. Often people create internal private zones that only work inside a particular network.

- hop: a network hop is a router on the network, and internet. Each represents a hop, this is important for things like the TTL on a UDP packet (distinct from the TTL on a DNS record), each hop decrements the packets TTL by 1. This is really important for multicast packets.

- block of IPs: generally refers to the CIDR block, which designated a routable network. 10/8 means all addresses that match 10.x.x.x, where as 10.10.1/24 is the 10.10.1.x network.

Re: Web Developer's Guide to DNS

#19

Post by teddyh »

_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 address into a name, which you can then look up and get a DNS record containing a name.

For example:

foo.example.com. A 192.0.2.3

is a name with an attached DNS record containing an IP address. To do a reverse lookup, we transform the address into the name “3.2.0.192.in-addr.arpa”, and look up not the A record (containing an address) for that name, but the PTR record, containing a name:

3.2.0.192.in-addr.arpa. PTR foo.example.com.

You can think of DNS record types (A/PTR/MX/etc.) as types or classes in a programming language. What data a DNS record can contain, and what that data should mean, is controlled by the record type.

This is the essence of it. There are always various minutiae one could get into, like the fact that IPv6 has a separate procedure to transform addresses into names, and, just as a name can have more than one address, the lookup of one address can result in more than one name.

To directly answer your questions:

• “Timely inversion” is not used as a technical term, it’s just a cute way of referencing the transformation procedure for an IP address into a name able to being looked up in the DNS.

• A “zone” is technically a collection of DNS records, restricted to a particular domain or subdomain. For example, the zone for “example.com” would normally contain all DNS records for not only “example.com”, but also the records for the names “www.example.com” and “foo.example.com”. The purpose of zones is that a zone is the mechanism by which the responsibility to respond to queries about DNS data is delegated to DNS servers. If you want questions about some names to be answered by some special DNS servers, you have to put those names in a separate zone. This is unusual but not unheard of – the other day¹ Cloudflare had problems related to the fact that they have actually delegated “www.cloudflare.com” to separate name servers from the name servers which are authoritative for the “cloudflare.com” zone. I.e. “www.cloudflare.com” is its own zone. Note however that this is unusual. You can tell if something is its own zone by the presence of an SOA record (and NS records) on the name; www.example.com does not have an SOA record, but www.cloudflare.com does.

• “Public” in this context simply means “for use by the public” or “publicly accessible”. And it’s strictly speaking a DNS resolver, not an authoritative DNS server for any specific zone or zones.

• The use of the word “hop” is, I believe, a further indication of the belief by the author in the stack-of-resolvers model, but this is a false belief. What actually happens is that a resolver asks one authoritative server (starting with the root servers), receives as a reply a list of better servers to ask, and the resolver asks those authoritative servers in turn. This is the actual “hop” referred to in reality.

• A “block” of IP addresses is a contiguous span of IP addresses. IP addresses are not allocated to organizations or ISPs around the world randomly or individually, but are instead delegated into as large and as contiguous spans as is possible. This is because the routing tables in routers are composed of lists of spans of IP addresses, and it is vital to minimize these lists, because if the core routers run out of memory, no more addresses can be routed.

1. https://news.ycombinator.com/item?id=19641155

Re: Web Developer's Guide to DNS

#20

Post by jrockway »

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) good luck if you aren't using glibc (go implements its own DNS stack, for example)

This would be a Linux rant, but OS X is also crazy and I imagine all other OSes are too.

The underlying issue is that "name resolution" and "DNS" are not exactly the same thing. There are all sorts of other things people expect to be able to use for name resolution, like mDNS. (I recall using LDAP and yp at some points in the past.) Thus, expecting a DNS trace to work for all "name resolution" is folly.

If you want to dig +trace to work, just point it at a DNS server with the @ argument. dig is a DNS client, not a name resolution client.

Post reply on HN