[dns-operations] DNS at FOSDEM 2016

[Petr Spacek]

On 3.2.2016 13:40, Marek Vavruša wrote:
> 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 and anyone else, would you be willing to work with us on improving error
reporting in DNS answers (not only SERVFAIL, think also about REFUSED etc.)?

There were some previous attempts but for lack of time we did not move much:
http://www.ietf.org/mail-archive/web/dnsop/current/msg13299.html

Would you be willing to help with a draft? (And of course implement it into
Knot :-)

-- 
Petr Spacek  @  Red Hat