Re: [dane] An AD bit discussion

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Viktor Dukhovni writ
es:
> On Thu, Feb 27, 2014 at 08:25:40AM +1100, Mark Andrews wrote:
> 
> > The history of the AD bit in responses and it meaning.
> > 
> > RFC 1035 -> AD=0
> > RFC 2535 -> AD=0/1 (records gone through validation) 
> > RCC 3225 (DO introduced)
> > RFC 3655 -> AD=0/1 (DO=1 required, answer and authority sections all secure
> )
> > RFC 3755 (type code roll)
> > RFC 4035 -> AD=0/1 (DO=1 required, answer and authority sections all secure
> )
> > RFC 6840 -> AD=0/1 (DO=1 or AD=1 required, answer and authority sections al
> l
> > 		    secure)
> 
> Thanks, this is very useful.  It remains only to determine whether
> for platforms on which the proposed designs are being contemplated,
> one can reasonably expect the target (reachable securely, typically
> local) resolvers to support AD=1 in the query.
> 
> This information seems to me to be more likely available to the
> administrator configuring *static* resolv.conf settings, than to
> an application author or user.
> 
> Therefore, my gut reaction is that applications that want the AD
> bit need to be able to ask for it, and the stub resolver library
> determines how to get the job done with help from resolv.conf.
> 
> The stub resolver library may be able to get away with sending AD=1
> instead of DO=1 and getting a more compact reply.  And may suppress
> RRSIG elements in the answer, authority and additional sections when
> the DO=1 was used because AD=1 was not known to be supported.
> 
> This still leaves us with the question of how libresolv clients
> should signal their interest in the AD bit?  At the very least the
> application needs to know that DNSSEC support is not simply
> unavailable.
> 
> With RES_USE_DNSSEC #defined, the application knows that the run-time
> promises to send DO=1.  There needs to be a similar option bit one
> can test for at compile-time, and use to signal that the stub-resolver
> library should return AD bits without RRSIGs (or with RRSIGs not
> specifically required if it is easier to pass them along if returned).

Setting AD isn't that hard.  For DANE you aren't going to want to use
res_search() to retrieve the TLSA record so this just unwraps res_query().

	res_mkquery(...,query,...);
	query[3] |= 0x08; // set ad in request
	res_send(query,...);
 
Mark

> -- 
> 	Viktor.
> 
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]