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