[gtld-tech] Delegated nameservers RFC compliance

Thu Sep 1 00:54:47 UTC 2016

Mark, colleagues,

A quick update regarding the state of the nameservers in the gTLD space, I
have been monitoring the nameservers of the gTLDs, and across time between
99.9% and 100% nameservers do not present any of the EDNS issues described
in https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-04.
Registries have solved the issues reported by ICANN in a timely manner.

Finally, a handful of name servers are copying the Z flag bit from the query
header (see 8.1.3.3 of draft-ietf-dnsop-no-response-issue-04) and this is
related to a bug that has now been fixed now in Knot (see.
https://gitlab.labs.nic.cz/labs/knot/issues/476).  We expect that in the
near future the MBZ issue should be solved in the gTLD space as Registries
roll out the new version.

Regards,
Gustavo

On 7/26/16, 15:59, "Gustavo Lozano" <gustavo.lozano at icann.org> wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160901/10dec280/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: default.xml
Type: application/xml
Size: 3222 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160901/10dec280/default-0001.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4701 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160901/10dec280/smime-0001.p7s>