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