pay.gov and IPv6

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
make

* 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org