[dns-operations] DNS at FOSDEM 2016

[Marek Vavruša]

On 3 February 2016 at 11:33, Mukund Sivaraman <muks at isc.org> wrote:
> On Wed, Feb 03, 2016 at 11:48:34AM +0100, Shane Kerr wrote:
>> Stephane,
>>
>> At 2016-02-02 21:47:59 +0100
>> Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
>>
>> > On Tue, Feb 02, 2016 at 09:10:48PM +0100,
>> >  Shane Kerr <shane at time-travellers.org> wrote
>> >  a message of 17 lines which said:
>> >
>> > > I was at FOSDEM 2016 last weekend, and wrote up a few of my
>> > > observations around DNS there:
>> > >
>> > > http://dnsv6lab.net/2016/02/03/DNS-at-FOSDEM/
>> >
>> > What, still no LDAP client, RDAP client and EPP client in systemd?
>>
>> He talked about how systemd has its own DHCP client now, because DHCP
>> is easy, just ask what is available, then confirm it.
>>
>> I was thinking "wow, DNS is even easier as a protocol then! ask for a
>> name, get an IP address!"
>>
>> As always, the devil is in the details.
>>
>> Or, perhaps "DHCP/DNS: minutes to learn, a lifetime to master"?
>
> Cannot master in lifetime. Except, if you're Mark Andrews.
>
> 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.

I feel the same way. Having open/semi-open resolvers introduces a lot of
problems and complexity into the protocol (client subnet, last-mile privacy,
reflection mitigation, consented filtering) which could be simply avoided
by using a resolver that is closer to the endpoint. I (usually) run a personal
resolver for dogfooding reasons and after a while, I can't discern any
noticeable
difference (apart from bugs that I've caused) between using a public resolver
and mine. Probably 80% of my traffic is predictable and prefetching kicks in,
for the rest it's sometimes faster to use a public resolver, and sometimes not.

> However, hearing of systemd trying to implement it is a case of
> reinventing the wheel. They should use an existing resolver
> implementation.
>
>                 Mukund

I think there is another very compelling reason to implement resolver on
the endpoint and that is error reporting from the resolver. DNS error responses
from the resolvers are a joke: spoofed DNSSEC answer - client gets SERVFAIL,
upstream is too slow - client gets SERVFAIL, too long CNAME chain - SERVFAIL,
... what the user gets from the browser is a blank page with a generic
excuse and that's
about that. Compare to HTTP error codes and error pages, certificate
failures etc.
If the browser had a better way to ask the local resolver and get a
detailed error report,
that would be awesome.

Marek


> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs