[dns-operations] Experiences with a post 2019 Flag Day Resolver

[Mark Andrews]

> On 17 Sep 2019, at 10:45 am, Shumon Huque <shuque at gmail.com> wrote:
> 
> On Mon, Sep 16, 2019 at 2:58 PM manu tman <chantr4 at gmail.com> wrote:
> On Mon, Sep 16, 2019 at 11:30 AM Shumon Huque <shuque at gmail.com> wrote:
> 
> Google Public DNS sends the EDNS Client Subnet option to authority servers that we run, and presumably to those broken servers too. We cannot observe the conversation between Google and the broken sites, but since they resolve, we assume that they might at least have a workaround to retry such sites without ECS (or maybe a dynamically maintained ECS blacklist is in use). Perhaps, a Google Public DNS operator can confirm or disconfirm this.
> 
> Obviously not for Google Public DNS, but last I remember, they would probe the name servers to see if they support ECS, if they do then they will start sending ECS. Therefore I would assume those misbehaving name sergers are failing the probe test and hence Google Public DNS will not send ECS to them.
> 
> Ah, thanks Manu.
> 
> I did vaguely recall reading about this, but when I attempted to find a reference earlier I failed. Now that I've typed the right set of search engine keywords, I found the following document which describes Google's ECS criteria:
> 
>     https://developers.google.com/speed/public-dns/docs/ecs
> 
> Mark Andrews writes:
> > ECS is also a white list option because of broken servers and the fact that
> > there are only relatively small numbers of servers that return ECS aware answers.
> 
> Yup, that makes sense. I was wondering whether the Flag Day workaround withdrawals had included ECS related changes. I guess, there is still enough brokenness around this feature that probing and whitelisting is still necessary. There is also the (partial) privacy benefit of selective ECS issuance in outbound queries.
> 
> Shumon.

With EDNS options there are 4 problems:

1) the EDNS option gets echoed back.  The big offender here was Microsoft but they fixed it in the March 2019.  This impacts on ECS as the client can’t tell the difference between a echoed option and working ECS.  For DNS COOKIE this doesn’t matter to named.  For NSID this is a non-issue.

2) servers that don’t respond.  There really aren’t a lot of these now.  The biggest offend here are servers behind old Juniper firewalls that block NSID option.  For the most part you don’t seen these unless you enable NSID requests.

3) servers don’t do DNS COOKIE correctly.  In my other email 2 of the servers failed to send the client cookie back when replying with a server cookie.

4) servers that send a different answer (e.g. NXDOMAIN instead of a address) to the non EDNS option query.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org