[dns-operations] Stop marking TLD's NS server as EDNS-incapable

[Shane Kerr]

Ralf,

At 2017-03-06 08:46:02 +0100
"Ralf Weber" <dns at fl1ger.de> wrote:

> Moin!
> 
> On 6 Mar 2017, at 3:40, Davey Song wrote:
> > I concluded it here that the EDNS fallback is proposed for good. But 
> > it may
> > introduce false positives due to temporary network failure or 
> > malicious
> > manipulations. Once the name server of certain TLD like .com and .net 
> > are
> > marked EDNS-incapable , it will become a disaster for validating 
> > resolvers.  
> That highly depends on the resolver implementation, however IMHO in your
> example it is shown that DNSSEC works as intended and detects spoofing 
> of
> DNS records. Resolvers following
> 	https://tools.ietf.org/html/draft-fujiwara-dnsop-resolver-update-00
> or
> 	https://tools.ietf.org/html/rfc7816
> might produce quite different results, though they also will detect the
> DNS spoofing if they validate.

Unfortunately if an attacker can send spoofed packets and trigger the
EDNS downgrade, that will effectively prevent a resolver from using the
authority servers for some time. That seems like a cheap (for the
attacker) and difficult to diagnose (for the defender) DoS to me.

I don't see any real way to prevent this problem other than channel
authentication though. Moving to TCP instead of disabling EDNS might be
a reasonable workaround with current technology though.

Ironically if the Great Firewall was smarter and only modified queries
going to Facebook's actual name servers then there would be no
problems. I suspect that the Chinese government is quite happy for
these operational problems with DNSSEC to encourage operators to
disable it.

> > One intuitive idea is to stop mark TLD’s NS server as 
> > EDNS-incapable, given
> > the fact that 7040 of 7060 (99.72%) of name servers support EDNS. Or 
> > we can
> > turn off the fallback function when it comes to DS record (the query 
> > back to
> > their parents).  
> So you are pushing the issue one level down. What when we see similar 
> behaviour
> in three label TLDs at the second label (co.uk)? Do you also want to 
> mark them
> special? This is just the wrong approach, as we should not make protocol
> variations depending on where we are at the DNS tree.

I tend to agree. Any special-casing will cause problems later.

Cheers,

--
Shane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20170306/d42e8c10/attachment.sig>