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

[Mantas Mikulėnas]

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".

-- 
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150515/8582e02d/attachment-0001.html>