[dns-operations] Stop marking TLD's NS server as EDNS-incapable
shane at time-travellers.org
Mon Mar 6 09:55:11 UTC 2017
At 2017-03-06 08:46:02 +0100
"Ralf Weber" <dns at fl1ger.de> wrote:
> 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
> DNS records. Resolvers following
> 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
> > 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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the dns-operations