Anyone from GoDaddy here?

Sun Oct 9 22:53:20 UTC 2016

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 at 512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=timeout docookie=ok edns at 512tcp=ok optlist=nsid,subnet
utahtrust.gov @2607:f208:207::32 (pdns01.domaincontrol.com.): edns=ok edns1=ok edns at 512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=mbz docookie=ok edns at 512tcp=ok optlist=nsid,subnet
utahtrust.gov @208.109.255.50 (pdns02.domaincontrol.com.): edns=ok edns1=timeout edns at 512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=timeout docookie=ok edns at 512tcp=ok optlist=nsid,subnet
utahtrust.gov @2607:f208:303::32 (pdns02.domaincontrol.com.): edns=ok edns1=ok edns at 512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=mbz docookie=ok edns at 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 at isc.org