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

[Mantas Mikulėnas]

On Fri, May 15, 2015 at 11:28 PM, Marcel Holtmann <marcel at holtmann.org>
wrote:

> Hi Lennart,
>
> >>> 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.
>
> so EDNS0 over UDP is something you really should to give up on. In ConnMan
> we tried hard to make that work and in the end gave up. Funny thing is that
> home routers in Germany were the most broken ones when it comes to EDNS0
> support. The solution is to just jump to DNS over TCP right away and not
> try to handle larger packets with EDNS0 over UDP.
>
> What this means is if a remote server or home network gateways truncates
> DNS packets, then switch over to establish a TCP connection for DNS and
> start using that one. Meaning in case the result is too large to fit in
> over UDP, make the same request over TCP and deliver that result to the
> clients. At that point, you can also keep using the TCP connection. I think
> in ConnMan we used some sort of idle timeout to terminate the TCP
> connections and fallback to UDP until the next truncated packet required us
> to re-establish the TCP connection.
>
> And I think that glibc does something similar. If it receives a truncated
> packet, it tries to get the full packet over TCP and only if the DNS server
> does not support TCP, it delivers the truncated data.
>

Hmm, what happens when the server supports neither? (Retry with 8.8.8.8 or
another fallback?)

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