An interview with Paul Mockapetris, the creator of the DNS | Hacker News Reader

An interview with Paul Mockapetris, the creator of the DNS

welcometothejungle.com

53 pointsBerislavLopac28 comments

> "I designed it this way for autocomplete. My vision at the time was that people would want to do autocomplete or they might want to just type part of the domain name and have it completed in a search list of the local environment."

> "Imagine if we were to type “com.” and then wait for autocomplete. Out of 160 million choices, there would be a pretty long pull-down menu."

What an amazing and unexpected reason, but I love it.

I thought the same myself although I am a bit suspicious he made up this reason in hindsight. Whatever the truth is, the result is better than Berners-Lee's idea, I think.

What's presented here by the interviewer is not actually what M. Berners-Lee's idea was. Here's what M. Berners-Lee actually said:

* http://impactlab.net/2006/03/25/interview-with-tim-berners-l...

This is the point where old hands mention JANET. (-:

* https://news.ycombinator.com/item?id=24005111

Imagine writing code so useful and flexible it lasts for decades, being used every single day by billions. DNS might not be perfect but it's one of those simple and elegant systems that keeps on trucking because of its simplicity.

It's simple and comparatively easy to make reliable, but a factor in its continued use is that's so prevalent in hard-to-change places: the web, libraries, old OSs, switches, other battle-hardened systems, etc.

It's the largest distributed database ever. It's not simple or easy, but it works very well and has for decades.

No doubt it is well written, simple code, but that's not even the main reason it's so widespread.

The point is that the moment it was written is even more important than how well it was written.

Though I suppose that if it had been really bad code it would have been replaced long ago.

Is it the same code or the same protocol?

I'm probably just reacting to the unfamiliar here but does anyone feel the alternative example they give would have it's own drawbacks?

> domain/host/path

> com/welcometothejungle/en/collections/behindthecode

Forgetting about the host/domain order I feel a different separator is actually a benefit in terms of readability and being able to distinguish between host and folders is more useful than this would suggest. If my URL is

edu/utexas/mccombs/blogs/mba-insider/covid-19-updates/

And I don't get a response am I trying to ping the equivalent of utexas.edu or mccombs.utexas.edu or blogs.mccombs.utexas.edu?

“But suppose that DNSSEC does give you security—I’m not sure whether all of my DNS to Google or Cloudflare DNS servers [which perform DNSSEC by default] is what I really want if I’m interested in preserving my privacy.“

-Paul Mockapetris

Which is where DNS-over-TLS (DoT) comes in. It provides privacy.

Feels like that quote is muddling two different problems in the security of DNS. DoT and DoH provide session privacy by hiding the queries from unwanted sniffing. DNSSEC provides authenticated records back to the origin. They have separate use cases.

And neither hide your DNS query from the DNS server itself. If half the world are using Cloudflare DNS via DoT, then Cloudflare could log those DNS queries and IPs. The logged data could be sold or given to law enforcement, governments, advertisers, etc. all from one or two large, convenient DoT providers. That is his point.

QNAME Minimisation hides your queries from more people who didn't need to know them. Historically most resolvers just always ask their entire question of everyone they speak to.

"Hi, I need to reach Suzy the Whore in Big Street, Glasgow?" Local travel agent: "Glasgow is in Scotland, far side of the world, so you need a plane, go to the airport and ask for Scotland" "Hi, I need to reach Suzy the Whore in Big Street, Glasgow?" Airport information desk: "Glasgow is the other side of the country, you need a train, go the train station and ask for Glasgow" "Hi, I need to reach Suzy the Whore in Big Street, Glasgow?" Glasgow station information: "Big Street is about half an hour's walk across the city. Go catch a number 16 bus and get off at Big Street" "Hi, I need to reach Suzy the Whore in Big Street, Glasgow?" Local resident: "Suzy's two doors down, top floor"

This is clearly a bad idea, we didn't need to tell anybody that we were looking for Suzy until we reached Big Street, or that we were headed for Big Street until we reached Glasgow. Is it possible Heathrow Airport has a tunnel to Suzy's house skipping the train to Glasgow that we'd only find by asking them? Not really, no, so we needn't give away what we want so easily.

Also, the very big providers like Cloudflare are cheerfully signing agreements not to log all this data for outfits like Mozilla (and Google) if you insist on trusting them rather than having resolution take place locally.

Do you trust these agreements with cloudflare and google? That is a lot of trust in a few providers ... seems more like centralization rather than decentralization and perhaps move away from privacy

From whom?

From anyone other than who you are connecting to.

Not per se.

Only over the wire. Google and Cloudflare (or whatever DoT server you are using) still see and log your DNS queries (if they want). That is his point.

Nothing in DoT tries to make you use some centralized resolver. That’s more DoH’s style.

For clarity and credit, Jon Postel is the other "creator of DNS" alongside Mockapetris. Sad Postel passed away so soon given all that he did for internetworking.

I wish he'd talked more about scaling. To me the real miracle of DNS is the way it's scaled from its original design to handle, what, a million times as much data and traffic as anyone would have reasonably assumed when it was deployed? More? I don't even know how to estimate it. The core idea of a hierarchy of caches has proven remarkably effective.

There are very few Internet protocols this old and widely used that haven't seen significant changes in design or at least implementation. BGP is the other one but it's not clear that it's a success story. NTP, sorta, but its current deployment is very different from the original design.

A hierarchy of caches is not the core idea. This is a common misunderstanding, but it is not how the DNS works.

There is a hierarchy of content, content DNS servers serving up their portions of the overall DNS database with delegations pointing to subdomain content DNS servers, and resolving proxy DNS servers stitching all of this content together (combining a bunch of partial answers from different content DNS server into an overall full answer) as they perform query resolution. Content DNS servers don't even have caches, as they serve up content directly from some kind of back-end database source.

That is the core idea; distribution of content around the world's content DNS servers, rather than having a giant replicated /etc/hosts or HOSTS.TXT file. Indeed, the headlined interview begins with this very point.

And yes, there has been at least one significant change in implementation. It was about a quarter of a century ago, when people began to realize that not having the same single DNS server perform multiple rôles was a good idea, and indeed best practice, and the whole RD/AA thing turned into mostly a hangover from old poorer practices.

So if you were about to retort that some content DNS servers (e.g. ISC's BIND, Microsoft DNS server) also doubled up as caching proxy DNS servers and did have caches, you should notice that even the "Cricket" Book has been recommending proper separation of rôles for many years now. This was a major change, reflected in the designs of newer DNS softwares than ISC's BIND, such as Bernstein djbdns, MaraDNS, PowerDNS, and nsd, which do not mix the rôles in a single program. And it's page 321 et seq. in the 2001 edition of the book.

* http://jdebp.uk./FGA/dns-server-roles.html

There are about 60 or 70 different uses that people have come up with.

That many? I'm aware of a few 'alternative uses' for DNS but wasn't aware that there were so many. Anyone here know of some?

Let's start with:

* name-to-address, times 2 because IPv4 and IPv6 are separated ("Many people think that the sole objective of the DNS was to go from names to addresses, but …")

* address-to-name, again times 2

* name-to-SMTP-Relay-server(s)

* name-to-content-DNS-server(s)

* name-and-service-and-transport-to-address (http://jdebp.uk./FGA/dns-srv-record-use-by-clients.html)

* name-to-SPF-information

* name-to-DMARC-information

* name-to-verification-token for Google/Bing webmaster tools et al.

* address-to-SMTP-Relay-client-allow/deny (http://jdebp.uk./Softwares/djbwares/guide/commands/rbldns.xm...)

* DNS-client's-address (e.g. o-o.myaddr.l.google.com.)

* address-to-opaque-name-to-same-address (http://jdebp.uk./Softwares/djbwares/guide/commands/walldns.x...)

Then we get into the more obscure uses such as AFS cell lookup, DHCP IDs, various kinds of keys including SSH public key fingerprints and OpenPGP keys, MAC address lookup, and "responsible person" mailbox names.

Be amused by https://news.ycombinator.com/item?id=24681726 .

I agree with your list, but maybe he meant more high-level use cases. For example, "DNS-as-load-balancer". I've seen people mess with DNS entries to produce the behaviour they want, versus doing it the "right way". Sometimes it was done because of ignorance of the "right way", other times it is because the responsible party does not want to deal with the change management processes of the "right way".

Thanks, yes that is what I meant but to clarify. When the figure of 60-70 uses for DNS was mentioned, thoughts of data exfiltration over DNS and DDoS amplification attacks were two things that sort of sprang to mind as alternate uses of it.

So I was wondering what other less Nefarious purposes DNS has been (ab)used to do?

Reply on news.ycombinator.com