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

[Lennart Poettering]

On Fri, 15.05.15 23:01, Christian Brunotte (cb at lathspell.de) wrote:

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

Well, this is not possible with DNS (see other mail). But maybe this
really is about doing multiple parallel DNS queries from the same source IP +
port. 

Right now all queries resolved does originate from the same IP
port. It has been requested to change this and use a new port number
for every single request, so that the 16 bit of the port can add to
the entropy when attackers want to guess DNS transaction credentials.

I wonder if we implement that if this might as side-effect also make
us more compatible with such firewalls, since unlike glibc we'd then
also have the A and AAAA requests come from a different IP/port pair...

Lennart

-- 
Lennart Poettering, Red Hat