On Mon, Nov 22 2021, Florian Obser <flor...@openbsd.org> wrote: > 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. I also think that'trust-ad" is good thing to support. > And then postfix comes along :( If we don't want uptreams to use RES_TRUSTAD and thus force the admin to do a conscious choice, we could hide it as an implementation detail in asr/ or make it a noop (decoupling it from "options trust-ad" and your automatic detection). It would require careful thinking about how people use the API. Personnally I don't feel too strongly about giving people rope... >> 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... Some people in the corporate world actually start to require the use of certificates signed by a known CA. I only spotted this twice so far. Regarding DANE and TLSA, one of the goals is to be able to use strong authentication without deferring to commercial CAs. So I'm pretty sure some nerdy admins have started enforcing it where they can, just because they can. >> 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. Proposal below. Feedback / oks? Index: res_init.3 =================================================================== RCS file: /home/cvs/src/lib/libc/net/res_init.3,v retrieving revision 1.5 diff -u -p -p -u -r1.5 res_init.3 --- res_init.3 22 Nov 2021 20:18:27 -0000 1.5 +++ res_init.3 23 Nov 2021 12:25:01 -0000 @@ -218,6 +218,19 @@ uses 4096 bytes as input buffer size. Request that the resolver uses Domain Name System Security Extensions (DNSSEC), as defined in RFCs 4033, 4034, and 4035. +The resolver routines will use the EDNS0 extension and set the DNSSEC DO +flag in queries, asking the name server to signal validated records by +setting the AD flag in the reply and to attach additional DNSSEC +records. +Note that the resolver routines will clear the AD flag in replies unless +the name servers are considered trusted. +Also, client applications are often only interested in the value of the +AD flag, making the additional DNSSEC records a waste of network +bandwidth. +See the description for +.Dq options trust-ad +in +.Xr resolv.conf 5 . .It Dv RES_USE_CD Set the Checking Disabled flag on queries. .El -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
