On Fri, May 15, 2015 at 11:28 PM, Marcel Holtmann <mar...@holtmann.org> wrote:
> Hi Lennart, > > >>> On Mon, May 4, 2015 at 2:57 PM, Christian Brunotte <c...@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 <graw...@gmail.com>
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
