[gtld-tech] Delegated nameservers RFC compliance
Gustavo Lozano
gustavo.lozano at icann.org
Tue Jul 26 22:59:40 UTC 2016
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>
More information about the gtld-tech
mailing list