NXDomain remapping, DNSSEC, Layer 9, and you.

Mark Andrews marka at isc.org
Tue May 29 02:47:10 UTC 2012


In message <CAAAwwbWRGcGcxhJ7G4XcFTr=6Q--EOWkBgnOqHWBA1o0BB+zhg at mail.gmail.com>
, Jimmy Hess writes:
> 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
> 
> Yeah.............
> 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".

Well I'm trying to get this fixed at the protocol level for other
reasons as explained in
http://www.ietf.org/mail-archive/web/dnsext/current/msg12495.html

draft-ietf-dnsext-dnssec-bis-updates-18.txt is still in IETF last
call and if you think always setting CD=1 when forwarding is bad for
whatever reason I could do with some support.
 
> 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.
> [snip]
> 
> 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"
> and
> 
> (3) The validation path is intact for _dumb_ non-validating stubs too.
> 
> --
> -JH
-- 
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 mailing list