Thank you Mark,

In the past we worked with a few gTLD backends to solve these issues. I

think that the massive improvement that you mentioned is related to this

effort. I will review your latest report and work with the affected gTLD

backends to solve any new issue.

Regards,

Gustavo Lozano

ICANN

On 7/25/16, 21:01, "gtld-tech-bounces@icann.org on behalf of Mark Andrews"

<gtld-tech-bounces@icann.org on behalf of marka@isc.org> wrote:

In message <0EDF3BC2-6E1E-4A2B-B264-3972B5E994B2@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@icann.org on behalf of Mark

Andrews" <gtld-tech-bounces@icann.org on behalf of marka@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@isc.org

--

Mark Andrews, ISC

1 Seymour St., Dundas Valley, NSW 2117, Australia

PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org