On 2021-11-21 22:21 +01, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote: > On Sun, Nov 21 2021, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote: >> On Sat, Nov 20 2021, Florian Obser <flor...@openbsd.org> wrote: > > [...] > >>>> Index: lib/libc/asr/res_mkquery.c >>>> =================================================================== >>>> RCS file: /home/cvs/src/lib/libc/asr/res_mkquery.c,v >>>> retrieving revision 1.13 >>>> diff -u -p -r1.13 res_mkquery.c >>>> --- lib/libc/asr/res_mkquery.c 14 Jan 2019 06:49:42 -0000 1.13 >>>> +++ lib/libc/asr/res_mkquery.c 20 Nov 2021 14:24:08 -0000 >>>> @@ -62,6 +62,9 @@ res_mkquery(int op, const char *dname, i >>>> h.flags |= RD_MASK; >>>> if (ac->ac_options & RES_USE_CD) >>>> h.flags |= CD_MASK; >>>> + if ((ac->ac_options & RES_TRUSTAD) && >>>> + !(ac->ac_options & RES_USE_DNSSEC)) >>>> + h.flags |= AD_MASK; >>> >>> do you remember why you check for !RES_USE_DNSSEC? >>> I'd like to leave it out. >> >> First, here's my understanding of RES_USE_DNSSEC: it's supposed to >> activate EDNS and set the DO bit. The server is then supposed to reply >> with AD set only if the data has been validated (with or without >> DNSSEC), and possibly append add DNSSEC data if available. >> >> Since I didn't know the semantics of both setting AD and DO in a query >> (I would expect such semantics to be sane) I wrote those more >> conservative checks instead. Does this make sense? If so, maybe >> a comment would help? >> >> /* Set the AD flag unless we already plan to set the DNSSEC DO bit. */ >> if ((ac->ac_options & RES_TRUSTAD) && >> !(ac->ac_options & RES_USE_DNSSEC)) >> >>> In fact I don't think RES_USE_DNSSEC is useful >>> at all. >>> If you want to set the DO flag and start DNSSEC from first principles >>> you are better of talking to the network directly, i.e. rewrite unwind. >> >> RES_USE_DNSSEC has been there since some time already and it's used by >> software in the ports tree, precisely to detect AD=1 - and not so much >> for the key records I think. > > BTW clearing AD might break software that depends on it for stuff like > DANE. postfix uses RES_USE_DNSSEC for this, but also force-enables > RES_TRUSTAD if available so it shouldn't be affected (upstream's stance > is that you should only use a trusted resolver when running postfix).
Ambitious... I actually had considerd to only do automatic trust-ad without any way for users and programs to change it / expand it to non-localhost. But then I thought it might be nice in a datacenter setting where you might trust the path to the resolver. And then postfix comes along :( > On the other hand mail/exim knowlingly doesn't force RES_TRUSTAD. I don't think we'll brake anything, at leat it should not stop progress. DANE verification has to be oportunistic, no? Good luck sending/receiving mail while requiring that certificates are either signed by a known CA or TLSA records are published. That will probably lose you a whole lot of the internet... > I don't know of other ports using RES_USE_DNSSEC and caring about the AD > flag. > > The effect of RES_TRUSTAD/trust-ad on RES_USE_DNSSEC ought to be > documented, but let's do that in another diff: the documentation of the > latter option is already lacking. > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE > -- I'm not entirely sure you are real.
