You could drop "Note that". Either way, OK florian On 23 November 2021 13:39:51 CET, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote: >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 >
-- Sent from a mobile device. Please excuse poor formatting.
