[gtld-tech] Delegated nameservers RFC compliance

[Gustavo Lozano]

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 --------------
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/20160726/2777050a/smime.p7s>