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

[Christian Brunotte]

> Lennart Poettering <lennart at poettering.net> hat am 15. Mai 2015 um 21:59
> geschrieben:
> 
> 
> On Mon, 04.05.15 14:57, Christian Brunotte (cb at lathspell.de) wrote:
> 
> > Hello
> > 
> > systemd.network(5) with Options like "DNS=" and "Domains=" looks like
> > /etc/resolv.conf will soon be superfluous.
> > 
> > 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?
> 
> What kind of bugs does this really solve?
> DNS servers that can only process one request per client at a time?

Firewalls notice outgoing UDP packets and allow response packets only within a
configured "UDP session timeout" time span. They need this timeout as UDP has
no opening and closing handshake like TCP. Some firewalls with "application
layer 
gateways" try to be especially clever and "understand" that a DNS request packet
only gets exactly one DNS response packet after which they can safely close this
port. In the case of a IPv4+IPv6 dual stack system that is no longer the case,
though.
The resolver can send one DNS request packet (IPv4 or IPv6 doesn't matter) that
contains 
queries for both the A and AAAA entries and the resolver may answer them in
separate packets.
Once the first one passes the firewall, the port is closed though. The requestor
now has to wait
some seconds in the hope that he gets the second packet - which never happens.
The GNU libc resolver knows about that problem and switches to single-request
automatically,
but that only happens for the current process which is why it's usually not
noticed. But if you
try to e.g. login via SSH, you encounter the problem every login as a new sshd
process is
spawned each time.

The above is from memory, so it might not be 100% accurate But I found other
links mentioning
the same problem and also with firewalls and IPv6:
* https://access.redhat.com/solutions/58625 (can't access myself but figured you
have an account :))
* http://udrepper.livejournal.com/20948.html
* https://bugzilla.redhat.com/show_bug.cgi?id=505105#c6 (mentioned Juniper
firwall)
* http://kb.juniper.net/InfoCenter/index?page=content&id=KB12312&actp=RSS (not
Linux specific)


> I mean, our intention is certainly to make things work by default,
> without any manual configuration, and this glibc option is something
> I'd really not like to replicate in resolved I must say.
> 
> but before we can see what we can do on this, I'd really need to
> understand what kind of broken DNS servers this is really supposed to
> fix?

It's hard to estimate how many people are still affected by this as surely all
firewall vendors
should have fixed this by now. 

But on the other hand, maybe it would'nt have any noticable speed drawback if
your resolved 
just defaults to sending one request packet for each query and configure libc6
to do so as well
(I admit I don't understand how systemd-resolved and libc6 NSS work together
exactly).

> Lennart
best regards,

-christian-