You mean to say

Note that, you can drop "Note that".

I have no idea where this construct came from.  Maybe it should be replaced
with "PAY ATTENTION NOW".  It is just rude.

Imagine if the cat manual page went like this:

DESCRIPTION
     Note that the cat utility reads files sequentially, writing them to the
     standard output.  Note that The file operands are processed in command-line
     order.  Note that if file is a single dash (`-') or absent, cat reads from
     the standard input.




Florian Obser <flor...@openbsd.org> wrote:

> 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.
> 

Reply via email to