[gtld-tech] Delegated nameservers RFC compliance
Gustavo Lozano
gustavo.lozano at icann.org
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>
More information about the gtld-tech
mailing list