[dns-operations] DNS at FOSDEM 2016

[Mukund Sivaraman]

Hi Ralf

On Wed, Feb 03, 2016 at 02:14:00PM +0100, Ralf Weber wrote:
> Moin!
> 
> On 3 Feb 2016, at 12:33, Mukund Sivaraman wrote:
> >I've always felt every machine should have its own DNS resolver (but for
> >some exceptions) - a local cache with insignificant access time. Most
> >people don't need an 8.8.8.8. An ISP providing a caching resolver is
> >similar to an ISP providing a HTTP proxy. Browsers implement caches and
> >that's usually sufficient. A shared cache helps no doubt, but it isn't
> >necessary in most cases. In the case of DNS, having the operating system
> >provide a default resolver is great.
> DNS requests and HTTP request are two totally different beasts wrt scaling,
> operation and cost.

I agree. HTTP (and resources served over HTTP) would put far more strain
on infrastructure than corresponding DNS traffic would.

> Also the current authoritative infrastructure we have today would not
> scale to resolvers on all clients.

Perhaps when it comes to "centralized" zones such as the root. But for a
regular authoritative server, it isn't clear how the situation is any
different from any other protocol. In comparison to HTTP processing and
resource utilization, DNS is a drop in the bucket.  From an average
domain owner's point of view, typical DNS authoritiative service
(including RR types other than A/AAAA) would be lighter compared to
service traffic (HTTP, SMTP, etc.) even when every resolver was a local
one. Authoritative side is easily distributable compared to other
protocols for those who expect high query rates (and likely have the
infrastructure to handle corresponding service traffic).

There are also CDNs which can offer local secondary name service similar
to the HTTP case.

It isn't right to compare apples and oranges, but how is authoritative
DNS a special protocol with regard to scalability when compared to
others, and why is it a client-side issue? From the client's viewpoint,
a cache is used to improve the client's time to access data, not to
assist the server side.

If a DNS domain host that serves on behalf of 3rd parties is worried
that doing this would increase their query traffic, they'd be correct,
but by all means let them handle the increased traffic because they are
the ones aggregating zones. It is not the DNS client-side's problem.

On the other hand, avoiding the use of external resolvers -- especially
external to one's immediate network -- has many advantages.

Incidentially, RFC 1034 says this:
>
> 5.3.1. Stub resolvers
>
> One option for implementing a resolver is to move the resolution
> function out of the local machine and into a name server which supports
> recursive queries.  This can provide an easy method of providing domain
> service in a PC which lacks the resources to perform the resolver
> function, or can centralize the cache for a whole local network or
> organization.

... which is about resource utilization on the DNS client side, rather
than on the authoritative side.


> The OS having an resolver is a great idea until it has a problem,
> which may be the reason that a lot of OS vendors so far haven't done
> it.


> I do hope that the systemd people offer an option not to use it.

Nod, it is unlikely that having the resolver locally will be suitable in
every case.

		Mukund
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160203/579b929e/attachment.sig>