Re: [Add] Mozilla's DoH resolver policy

[Ted Hardie <[e-mail]>]

Howdy,

On Fri, Apr 12, 2019 at 10:14 AM Peter Saint-Andre <[e-mail]>
wrote:

>
> > Have you considered randomly rotating all queries
> > through every item in the list,
>
> We've considered random rotation but "there are problems with this".
>
>
So, I assume Wes didn't mean sending all queries to all entities on the
list, because that would be wasteful of bandwidth and very leaky of
information.  I think he meant "random rotation", which is the question you
answered.

But the reality is that folks have been dealing with the DNS round-robin
problem a long time and the change in transport protocols doesn't change
the parameters of the problem that much.  Generally speaking, you are
optimizing for reduced latency.  I think it was Duane Wessels who
introduced the "ladder race" method, which works pretty well over time;
there are also lots of variations of it.

Ladder race works by starting from a list, either with a known default or
no default.  You pick two for the first query and race them.  The winner
becomes the default and is raced against a random member of the list for
the next query or after a period of time--in this case, I'd suggest basing
that time period on the HTTPS set up time (e.g. 5x the set-up time).  Once
you have raced the entire list, you have a resolver choice that has the
lowest latency for that particular client.  You then re-race after a longer
elapsed period of time; if you get the same choice, you lengthen the time
between races.  Every time the race returns the same choice, the signal
that this is a stable choice increases and the time lengthens.  If there is
a change, you drop back to a shorter race time.

What this should do is associate the clients with the lowest latency
resolver.  If a resolver gets busy, its latency will increase and it will
go down in the races and shed clients, so this is a blended signal of
network distance and resolver load.  It will vary over time, but there are
lots of clients for whom that variation won't result in a change in
assigned server.

In this case, you also don't need all the servers to speak the same
protocol; you could blend DoT and DoH servers into the same list.  That
might actually reward the use of DoT where it is not blocked, because the
response time for a cache fill is likely to be a bit better (as there is
less overhead without the mime-type processing in DoH).

Mechanisms like ladder race and its variations basically provide you some
way gathering data to make the choice in a way that optimize what you want;
the key is doing it in a way that is friendly enough to the resolvers and
the network. But I don't think this is a new problem, even if this code is
new to Firefox.

regards,

Ted