[gtld-tech] Delegated nameservers RFC compliance

[Mark Andrews]

In message <0EDF3BC2-6E1E-4A2B-B264-3972B5E994B2 at icann.org>, Francisco Arias writes:
> Hi Mark,
>
> Are you suggesting there is an issue with TLD servers or second-level
> names, or both?

There are issues with both though the TLD servers have show a massive
improvement [1] and the GTLD subset are supposed to be RFC compliant
with DNSSEC, EDNS(0) and STD 13 as per their contracts.  The root
servers also need to meet the same level of compliance.

[2] shows that most of the TLD and root servers are basically
compliant.  The tests used are described in [3].

The second level names are a entirely different matter with only
~60% [1] of servers actually passing just the EDNS(0) subset of the
tests above.

Everytime new features (EDNS, DNSSEC, DNS COOKIES, AD=1 in queries)
have been deployed in the DNS resolver vendors have had to work
around non compliant servers where possible or just live with the
fact that you can't do reliable signaling because the broken servers
were not removed from the ecosystem in a timely enough manner (AD
is echoed back by too many servers despite this being explicting
prohibited by STD13).  This could have been avoided if nameservers
were actually checked for protocol compliance and operators with
non-compliant servers informed that their servers are broken.

Some of this will improve as operators use F1 [4] load balancers
and Checkpoint Firewalls upgrade (Unknown EDNS version and Unknown
EDNS Flags will no longer cause the DNS message to be dropped based
on correspondence with a Checkpoint developer.)  This won't cover
all cases of packets being dropped.  Nor will it address the servers
returning inappropriate responses.

To be able to use the extensions mechanisms specified in EDNS(0)
the deployed server need to be well behaved when they see a message
using a extensions mechanisms.  This is very much not the case
today.

Mark

[1] https://ednscomp.isc.org/compliance/summary.html
[2] https://ednscomp.isc.org/compliance/tld-fullreport.txt
[3] https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-03.
[4] https://support.f5.com/kb/en-us/solutions/public/16000/200/sol16240.html

Mark

> Regards,
>
> --
> Francisco
> On 7/18/16, 2:07 PM, "gtld-tech-bounces at icann.org on behalf of Mark
> Andrews" <gtld-tech-bounces at icann.org on behalf of marka at isc.org> wrote:
>
>
>     As part of preparations for shipping nameservers that support DNS
>     COOKIES (RFC 7873) I have been measuring EDNS Compliance in a number
>     data sets the results of which are available at
> https://ednscomp.isc.org
>     along with a online tester.  We wanted how much will break when we
>     ship BIND 9.11.0 which has DNS COOKIES on by default.
>
>     We found there were zones that could no longer resolve if validation
>     was enabled. Named falls back to plain DNS on certain detected
>     errors as there isn't time to probe exact failure causes by trial
>     and error.  Even if trial and error worked for DNS COOKIEs the
>     problem will get worse as more EDNS features get used.
>
>     We found zones that were taking multiple seconds to resolve.  We
>     were back to the sort of resolution times we saw when EDNS was first
>     introduced for some zones.
>
>     We saw increased queries being needed to be made as servers didn't
>     correctly ignore unknown EDNS options.
>
>     All these errors are easily determinable by running a handful of
>     queries against each server.
>
>     RFC 1034 and RFC 1035 were written assuming that servers delegated
>     to would be RFC compliant.  Currently GTLD servers are checked and
>     there is no reason that servers delegated to by the GTLD servers
>     can't also be checked and the operators asked to fix the faults
>     detected.  This can be done at both the RFC 1034 and RFC 1035 level
>     and at the EDNS level.  It is not a actionable condition if all the
>     EDNS tests fail in a way that indicated the EDNS is not supported.
>
>     I would suggest that {E}DNS compliance checking be done within a
>     week of a new server being registered and delegated to and 1/2
>     yearly thereafter.  If a server fails a test that the operator /
>     registrant be informed and the server be retested in a month.  I
>     would also suggest that compliance testing results and test date
>     should be record in whois or similar so there is no need to retest
>     too frequently.
>
>     Mark
>     --
>     Mark Andrews, ISC
>     1 Seymour St., Dundas Valley, NSW 2117, Australia
>     PHONE:	+61 2 9871 4742		         INTERNET: marka at isc.org
>
>

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