[systemd-devel] high latency on systemd-resolved repsonses of LLMNR names

[Lennart Poettering]

On Mon, 10.04.17 12:41, Kai Krakow (hurikhan77 at gmail.com) wrote:

> > Queries and responses in LLMNR are supposed to be delayed by a random
> > time up to 100ms according to the RFC. See:
> > 
> > https://tools.ietf.org/html/rfc4795 section 2.7, and section 7.
> > 
> > If you add up the delay for the query and the response you'll get a
> > delay up to 200ms for a full transaction.
> 
> Well it seems a bit more complicated:
> 
> The random delays are a combined value of jitter and timeout. And it
> depends on whether you're currently the sender or responder: Responders
> have shorter timeouts (only jitter), according to section 2.7.
> 
> It also says SHOULD wait (so it is a good idea), and it says the jitter
> MAY be ignored if the responder knows the name is unique. Only the
> sender MUST wait for timeout+jitter.
> 
> This is where the 200ms come from, but it may even be 1000+100ms if
> you are connected to none-IEEE 802.* media, e.g. VPN or PPP interfaces
> and LLMNR is configured to listen on these, as far as I understand
> section 7.
> 
> According to RFC2119, the terminology SHOULD suggests that systemd could
> maybe make this configurable? Maybe taking the proper warnings for this
> configuration into account for administrators... Still you would see
> delays of at least 100ms then because the sender MUST wait.

I am not a fan of configuration options in zeroconfey technology like
this one I must say. I mean "zeroconf" is about "zero configuration",
hence making it configurable creates kind of a tautology...

Lennart

-- 
Lennart Poettering, Red Hat