[dns-operations] resolvers considered harmful

[Paul Hoffman]

Speaking as someone who supports all end systems to be their own validating recursive resolver.

On Oct 23, 2014, at 6:10 AM, Paul Wouters <paul at nohats.ca> wrote:

> "simply" on their own moves the entire query load of all endpoints
> (billions) onto the authoritative nameservers only. Do you really
> propose a billion clients should perform lookups against my 3 poor
> nameservers for nohats.ca.?

Yes. How poor are your nameservers? What percentage of CPU and network are your current replies taking up?

> Have you talked to operators world wide on what the query load on their
> caching resolvers is?

Yes, and the answer is usually "we won't tell you for competition reasons".

On Oct 23, 2014, at 6:29 AM, Jelte Jansen <jelte.jansen at sidn.nl> wrote:

> Like others, I think it can use much more information on scalability
> issues for auths; One 'type' it haven't seen discussed it the root
> servers. Perhaps it won't be noticed in all the garbage they get right
> now, but perhaps the garbage they get will increase by a lot.

The root server operators consistently say "don't worry about sending us more valid queries".

> On increasing TTL: Most implementations don't keep state between
> restarts, so even if a TTL of a week was practical from the operator's
> view, any device that is restarted often (like, say, my desktop
> computer) loses all of its cache. So while increasing the TTL may reduce
> the number of queries, it's not completely clear how much from static
> trace data.

Correct. Having said that, having popular implementations of recursive resolvers start keeping state across reboot (every minute or so writing as much of their cache to hard disk as they can) would help.

> I do not think putting multiple questions in one request isn't reliably
> possible without heavy protocol changes; sure the protocol doesn't
> forbid adding more records to the question section, but it doesn't
> really have any way to answer them either; mostly because there is only
> one rcode field. So I don't think that option is as easy as the paper
> makes it out to be.


Fully agree. This would be a huge protocol transition, and probably not even worth considering.

--Paul Hoffman