In message <54fdb221.8020...@nlnetlabs.nl>, Willem Toorop writes: > I'd like to maintain the term exactly as specified in RFC4033 > (understanding DNSSEC but not validating), because it comes in use when > talking about validating stubs. > > Some network operators don't know or care about DNSSEC and do not equip > their network's resolver with a trust anchor. Such a resolver is > obviously not validating, but if it is a modern resolver it is very > likely to be security-aware. > > An application using a validating stub can leverage such a resolver to > get DNSSEC answers from the cache which it can then validate itself. > For example to get an authenticated TLSA and bootstrap an encrypted channel.
Which works most of the time as there are very few attacks and the resolvers do a pretty good job of dealing with the broken authoritative servers and poorly configured firewalls that block legitimate replies. If you want reliable DNSSEC then these resolvers also need to validate. > I have presented measurements on the amount of security-aware resolvers > in RIPE ATLAS in the context of this use case at ICANN50: > > https://london50.icann.org/en/schedule/wed-dnssec/presentation-dnssec-validat > ion-deployment-25jun14-en.pdf > > Though in the research we called those DNSSEC-aware instead of > security-aware. > > -- Willem > > Op 08-03-15 om 23:31 schreef Ralf Weber: > > Moin! > > > > On Sun, Mar 08, 2015 at 12:21:49PM -0700, Paul Hoffman wrote: > >> Greetings again. Paul Wouters noticed an inconsistency in the terminology > >> draft, and upon investigation, I believe it is a problem (hopefully > >> fixable) with the definitions in RFC 4033. RFC 4033 and 4035 use the term > >> "validating resolver" in a few places. However, RFC 4033 never defines > >> that. RFC 4033 *does* define "security-aware resolver": > >> > >> Security-Aware Resolver: An entity acting in the role of a resolver > >> (defined in section 2.4 of [RFC1034]) that understands the DNS > >> security extensions defined in this document set. In particular, > >> a security-aware resolver is an entity that sends DNS queries, > >> receives DNS responses, supports the EDNS0 ([RFC2671]) message > >> size extension and the DO bit ([RFC3225]), and is capable of using > >> the RR types and message header bits defined in this document set > >> to provide DNSSEC services. > >> > >> My personal interpretation is that "validating resolver" is a synonym for > >> "security-aware resolver". Do others agree? If not, how would you > >> differentiate them? > > I was told that the difference is that a security aware resolver does > > not validate, but instead relies on the "Validating Stub Resolver" to > > protect the user. So it would handle all the DNSSEC processing to the > > authoritative and would store the records with signatures in the cache, > > but it wouldn't check if they are valid. > > > > The people who told me that interpreation of the RFC never did deploy DNSSE > C > > and thankfully most of the people who did and deployed DNSSEC used > > validating and security aware resolvers. I don't think it makes sense to > > deploy a caching resolver without validation. So would be ok if we define > > it as you suggest. > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
