Can you please explain why you do not acknowledge reports of your nameservers being broken. Can you please explain why you are are blocking EDNS 1 queries over IPv4 when your servers are clearly capable of handling them over IPv6? Can you please explain why your servers mishandle EDNS flags? What part of the following is unclear. You *send* replies. The flag bits should be empty in the replies even if they are set in the request. You obviously are not ignore them as you echo them back (IPv6) or drop the query (IPv4). This will make the flag bits less useful when they are finally defined as no one will be able to depend on the bits not being echoed. We already have a flag bit where we can't depend on its return state (AD) because too many server just echo it. We do not need this to happen to any other bits. Z Set to zero by senders and ignored by receivers, unless modified in a subsequent specification. Mark Checking: 'utahtrust.gov' as at 2016-10-09T22:37:30Z utahtrust.gov @216.69.185.50 (pdns01.domaincontrol.com.): edns=ok edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=timeout docookie=ok edns@512tcp=ok optlist=nsid,subnet utahtrust.gov @2607:f208:207::32 (pdns01.domaincontrol.com.): edns=ok edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=mbz docookie=ok edns@512tcp=ok optlist=nsid,subnet utahtrust.gov @208.109.255.50 (pdns02.domaincontrol.com.): edns=ok edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=timeout docookie=ok edns@512tcp=ok optlist=nsid,subnet utahtrust.gov @2607:f208:303::32 (pdns02.domaincontrol.com.): edns=ok edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=mbz docookie=ok edns@512tcp=ok optlist=nsid,subnet The Following Tests Failed Warning: test failures may indicate that some DNS clients cannot resolve the zone or will get a unintended answer or resolution will be slower than necessary. Warning: failure to address issues identified here may make future DNS extensions that you want to use ineffective. In particular echoing back unknown EDNS options and unknown EDNS flags will break future signaling between DNS client and DNS server. We already have examples of this were you cannot depend on the AD flag bit meaning anything in replies because too many DNS servers just echo it back. Similarly the EDNS Client Subnet (ECS) option cannot just be sent to everyone in part because of servers just echoing it back. EDNS - Unknown Version Handling (edns1) dig +nocookie +norec +noad +edns=1 +noednsneg soa zone @server expect: BADVERS expect: OPT record with version set to 0 expect: not to see SOA See RFC6891, 6.1.3. OPT Record TTL Field Use EDNS - Unknown Version with Unknown Option Handling (edns1opt) dig +nocookie +norec +noad +edns=1 +noednsneg +ednsopt=100 soa zone @server expect: BADVERS expect: OPT record with version set to 0 expect: not to see SOA expect: that the option will not be present in response See RFC6891 EDNS - Unknown Flag Handling (ednsflags) dig +nocookie +norec +noad +ednsflags=0x80 soa zone @server expect: SOA expect: NOERROR expect: OPT record with version set to 0 expect: Z bits to be clear in response See RFC6891, 6.1.4 Flags Codes ok - test passed. nsid - NSID supported [RFC5001]. subnet - EDNS Client Subnet supported [RFC7871]. mbz - EDNS flags echoed back. timeout - lookup timed out. To retrieve this report in the future: https://ednscomp.isc.org/ednscomp/79f338bd47 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org