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

[Marcel Holtmann]

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.

Regards

Marcel