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

[Kai Krakow]

Am Mon, 10 Apr 2017 12:46:02 +0200
schrieb Lennart Poettering <lennart at poettering.net>:

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

As I pointed out it wouldn't have a big effect anyways, so probably
you're perfectly right.

Is there a way to know the delays used, i.e. if it 1000 or 100ms?


-- 
Regards,
Kai

Replies to list-only preferred.