In message <[email protected]>, 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
