NXDomain remapping, DNSSEC, Layer 9, and you.

Jimmy Hess mysidia at gmail.com
Tue May 29 02:20:04 UTC 2012

On 5/28/12, Mark Andrews <marka at isc.org> wrote:
> Until stub resolvers set DO=1 pretty much ubiquitously this won't
> be a problem for ISP's that want to do nxdomain redirection.  There

Right now current _server_  implementations don't even have it right,
for properly implementing DNSSEC validation down to that level, let
alone the stubs below the server.

Many SME LANs utilize Windows-based endpoints, and commonly have
Windows-based DNS servers on the LAN, used by endpoints, where the
Windows DNS servers are set to forward queries to ISP recursive
servers.   Current  Windows' DNS server in 2008 "supports" DNSSEC.
 When Windows DNS server is configured to forward DNS queries to a
list of reasonable  recursive DNS servers,  the server sets  CD (Check
disabled) bit set, and the DO bit set  for all queries it sends;
there is no option to "support dnssec queries from smart stubs but
don't send queries from dumb stubs with CD".

Also, there are by default no trust anchors, and _Every_ response is
treated as valid.  (In other words, CD bit and DO bits are set in
forwarded queries, but no validation occurs).
It's kind of like having a SSL implementation that treats ALL SSL
certificates as valid, until and unless you take manual steps to
configure a CA list.

If you don't like this default and want to configure Windows DNS with
the root trust anchor....  Sorry, Algorithm #5 RSA/SHA-1 is the only
supported key type, and the current root signing key is not of a
compatible format.

Your "smart" stub can send a query to this broken DNSSEC
implementation with the DO bit set, for sure.

> still plenty of crappy DNS proxies in CPE routers to be replaced
> before you can just set DO=1 as a default without worrying about
> breaking DNS lookups.  Even setting EDNS as a default is a issue.

I'm all for smart stubs   as long as  (1) They can get the data to them
(2) They can get the proper logging/reporting to them,  E.g.   No
"silent" upstream validate/discard;      No  upstream  silent "ignore
the stub's requested CD bit and validate/discard anyways"

(3) The validation path is intact for _dumb_ non-validating stubs too.


More information about the NANOG mailing list