Re: [dane] An AD bit discussion

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Viktor Dukhovni writ
es:
> On Thu, Feb 27, 2014 at 09:50:59AM +1100, Mark Andrews wrote:
> 
> > > 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,...);
> 
> Thanks for the proof of concept!  From an application developer
> perspective, I'd like to suggest that this is not terribly practical
> as an application interface.  The decision is made in the wrong place
> if this is application code, rather than stub resolver internal code.

It wasn't to say that it was practical or best practice. Extending options
to set AD would be useful but there is no reason to wait for that to
happen.

> For example, Postfix uses res_search for everything, including TLSA
> lookups, but being single-threaded, it can safely make temporary
> changes in _res.options before each lookup (the original value is
> restored when the lookup completes).

Or one could use res_nsearch/res_nquery and have it work in a threaded
envionment.  Personally I would be using res_{n}query in a MTA to avoid
any possibility of searching.

> #define USER_FLAGS (RES_DEBUG | RES_DNSRCH | RES_DEFNAMES | RES_USE_DNSSEC)
> #define XTRA_FLAGS (RES_USE_EDNS0)
> #define SAVE_FLAGS (USER_FLAGS | XTRA_FLAGS)
> 	saved_options = (_res.options & SAVE_FLAGS);
>         _res.options &= ~saved_options;
>         _res.options |= flags;
>         len = res_search(name, C_IN, type, reply->buf, reply->buf_len);
>         _res.options &= ~flags;
>         _res.options |= saved_options;

> Here "flags" is always a subset of "saved_options" that is set for
> the current query, the remainder (including RES_DEFNAMES and
> RES_DNSRCH) are cleared, unless explicitly requested in "flags".
>
> This is about the lowest level of the libresolv API that Postfix
> will use.  Also control over whether the right bit to send is "AD=1"
> in the header or "DO=1" in the OPT pseudo-header really belongs
> in stub resolver configuration, not in Postfix.

res_search and res_query are on the same level.

         len = res_search(name, C_IN, type, reply->buf, reply->buf_len);
         len = res_query(name, C_IN, type, reply->buf, reply->buf_len);
 
Additionally res_search should only proceed to the next name on
NXDOMAIN.  Currently it is type sensitive which is a hold over from
the when always appended the first search element regardless of the
number of labels in it and handling wildcard MX records.  If you had
a MX record like

	*.element.in.search.list MX 0 some.server

you didn't want to stop a search for A records for foo.example.net.

> What would make more sense, is the ability to request pre-validated
> responses (AD without RRSIG if possible), and have the stub-resolver,
> based on /etc/resolv.conf settings, figure out the best way to
> satisfy the request.
> 
> A new RES_IGNORE_RRSIG or similar option could be used in combination
> with RES_USE_DNSSEC signal that an application wants "AD" in
> responses, but is not interested in RRSIGs (though might still
> get them).  The library would send whichever of "AD=1" or "DO=1"
> is specified in resolv.conf as being supported by the designated
> nameservers.
> 
> -- 
> 	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]