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