pay.gov and IPv6
marka at isc.org
Fri Nov 18 20:58:51 UTC 2016
In message <87twb4slol.fsf at mid.deneb.enyo.de>, Florian Weimer writes:
> * Mark Andrews:
> > The DNSSEC testing is also insufficient. 9-11commission.gov shows
> > green for example but if you use DNS COOKIES (which BIND 9.10.4 and
> > BIND 9.11.0 do) then servers barf and return BADVERS and validation
> > fails. QWEST you have been informed of this already.
> > Why the hell should validating resolver have to work around the
> > crap you guys are using?
> The protocol doesn't have proper version negotation, and again and
> again, implementers have tried to force backwards-incompatible
> implementations on the Internet at large.
The servers talk EDNS. They server signed zones which require EDNS
support. These are EDNS version 0 queries. BADVERS is the response
code for when you receive a EDNS version field higher than the one
you implement and it requires that you use EDNS to send the rcode.
The query has a EDNS version field of 0. The response has a EDNS
version field of 0. The response has a rcode of BADVERS.
Yes, the behaviour of how to handle unknown options was clarified
in RFC 6891. With RFC 2671 nameserver developer had a choice to
* BADVERS was never a sensible response however. BADVERS had explict
instructions for when it should be sent and they didn't include "if
there is a EDNS option you don't understand return BADVERS". If you
thought the version field was wrong then that made it a malformed
request which should elicit a FORMERR.
* FORMERR also wasn't a good idea. RFC 2671 didn't say that no
options could be added to a EDNS version 1 query but I can see if
you thought EDNS version 0 was not allowed to have EDNS options
that it could be seen as a malformed record. Unless you know the
format of the option you can't sensibly return FORMERR on it.
* NOTIMP would have made sense before RFC 6891 was published but we never
saw a implementation that did this.
* Echoing back the option made some sense, though sending a option that
you don't understand is risky.
* Ignoring the option also made sense. This is what RFC 6891 says
to do and matches the unknown EDNS flags behaviour.
* Ask the working group / IETF.
I wouldn't be complaining about it if they were only supporting
plain DNS. You can tell the difference between a server that
supports EDNS and one that doesn't. They behave differently.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the NANOG