In message <CAAAwwbWRGcGcxhJ7G4XcFTr=6q--eowkbgnoqhwba1o0bb+...@mail.gmail.com> , Jimmy Hess writes: > On 5/28/12, Mark Andrews <ma...@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: ma...@isc.org
