[systemd-devel] Will *.network replace resolv.conf? What about "Options single-request"?

[Lennart Poettering]

On Fri, 15.05.15 22:51, Mantas Mikulėnas (grawity at gmail.com) wrote:

> On Fri, May 15, 2015 at 10:40 PM, Tom Gundersen <teg at jklm.no> wrote:
> 
> > On Mon, May 4, 2015 at 2:57 PM, Christian Brunotte <cb at lathspell.de>
> > wrote:
> > > systemd.network(5) with Options like "DNS=" and "Domains=" looks like
> > > /etc/resolv.conf will soon be superfluous.
> >
> > In many setups, yes, but we will not aim at bug-for-bug compatibility
> > or anything like that. We are open to adding features that make sense
> > though.
> >
> > > If that's the plan, I wonder what happens to "options single-request"
> > > which I had to use on all IPv6 enabled devices. Is "ResolveOptions" just
> > > missing in Systemd or considered so "special" that will stay in libc's
> > > resolv.conf?
> > >
> > > (quoting from the man page: "By default, glibc performs IPv4 and IPv6
> > > lookups in parallel since version 2.9. Some appliance DNS servers cannot
> > > handle queries properly and make the requests time out.")
> >
> > Hm, this really does not sound like something that should be
> > configurable. Are you really seeing these bugs in the wild? And if so,
> > how do other OSs deal with this? I mean, having to add quirks to every
> > client does not sound very viable... Surely DNS is something that
> > should 'just work'. I feel like I'm missing some part of the picture
> > here.
> >
> 
> Yeah, it *is* something that should 'just work', but then there are both
> corporate firewalls and embedded devices (i.e. home gateways) which choke
> on EDNS, crash upon seeing DNSSEC, truncate all packets to 512 bytes
> (manufactured in 2015!), and even outright lie – by making up their own
> (incorrect) responses instead of forwarding the query. (If it's not
> encrypted, some proxy somewhere will screw it up...)
> 
> So, sometimes it "works" in the sense of "Windows doesn't trigger the bugs".

Well, but in all these cases, we should try to actively learn, and try
a few things before we give up, but certainly not give up completely
and let the user configure things.

For example, if a server doesn't resond to EDNS or DNSSEC or truncates
packets, then we should detect that automatically, fall back and
remember this during runtime.

One of the benefits that we have with resolved is that we are
system-wide and stateful, hence can remember these things relatively
easily, where classic nss-dns can't...

Lennart

-- 
Lennart Poettering, Red Hat