On Wed, Nov 17, 2021 at 12:26:00PM -0800, [email protected] wrote:
> On Wed, 17 Nov 2021 20:00:21 +0000, Otto Moerbeek <[email protected]> said:
> > You seem to be confused about the meaning of the ad bit. It is a bit
> > that only has significance on replies, see
> > https://datatracker.ietf.org/doc/html/rfc4035#section-4.6
>
> Ah, wireshark calls this bit the "AD bit" when sent by dig, so that's
> why I used that incorrect term:
>
> Domain Name System (query)
> Transaction ID: 0x4bea
> Flags: 0x0120 Standard query
> 0... .... .... .... = Response: Message is a query
> .000 0... .... .... = Opcode: Standard query (0)
> .... ..0. .... .... = Truncated: Message is not truncated
> .... ...1 .... .... = Recursion desired: Do query recursively
> .... .... .0.. .... = Z: reserved (0)
> .... .... ..1. .... = AD bit: Set
> .... .... ...0 .... = Non-authenticated data: Unacceptable
>
> From what you linked it looks like a separate bug in dig.
Well, I should have been more clear as well, dig sets both the AD bit
(by default) and the DO bit (on +dnssec). More clienst do this. This
is part of the can of worms.
>
> > Signalling that yo want a DNSSEC validated answer is normally done by
> > setting the DO bit in the EDNS options.
>
> You're right. Looking more carefully though without RSS_USE_DNSSEC
> (which is not possible to set) OpenBSD doesn't do that though:
>
> Domain Name System (query)
> Transaction ID: 0x4dbe
> Flags: 0x0100 Standard query
> 0... .... .... .... = Response: Message is a query
> .000 0... .... .... = Opcode: Standard query (0)
> .... ..0. .... .... = Truncated: Message is not truncated
> .... ...1 .... .... = Recursion desired: Do query recursively
> .... .... .0.. .... = Z: reserved (0)
> .... .... ...0 .... = Non-authenticated data: Unacceptable
> Questions: 1
> Answer RRs: 0
> Authority RRs: 0
> Additional RRs: 1
> Queries
> XXXXXXXXXXXXX: type SSHFP, class IN
> Name: XXXXXXXXXXXXXX
> [Name Length: 21]
> [Label Count: 3]
> Type: SSHFP (SSH Key Fingerprint) (44)
> Class: IN (0x0001)
> Additional records
> <Root>: type OPT
> Name: <Root>
> Type: OPT (41)
> UDP payload size: 4096
> Higher bits in extended RCODE: 0x00
> EDNS0 version: 0
> Z: 0x0000
> 0... .... .... .... = DO bit: Cannot handle DNSSEC security
> RRs
> .000 0000 0000 0000 = Reserved: 0x0000
> Data length: 0
>
> DO is not set unless RSS_USE_DNSSEC is set.
>
> >> It seems the unwind DNS server *unconditionally* returns with 'ad' set, so
> > Nope, unwind sets the ad bit only on DNSSEC validated answers, and
> > other resolvers can be configured to do so.
>
> Sorry, I was told this on #openbsd, but should have checked myself.
>
> >> it works if (and only if?) unwind is the server queried. This seems like a
> >> bug, and it should probably work with all DNS servers (e.g. 8.8.8.8[3]).
> > Quad8 already sets the ad bit on DNSSEC validated answers, just as unwind.
>
> If given edns0 DO, yes. But (per above) it's never provided by the
> getrrsetbyname() path.
>
> >> I believe that the fix here should be:
> >>
> >> else if (!strcmp(tok[i], "dnssec"))
> >> ac->ac_options |= RES_USE_DNSSEC;
> > you are opening a can of worms.
>
> How should RES_USE_DNSSEC be enabled for getrrsetbyname(), then?
>
> Hard coding it in getrrsetbyname() presumably risks it not being able
> to retrieve the SSHFP records at all, which makes it not even possible
> to fall back to "ask" for VerifyHostKeyDNS?
You are forcing *all* clients resolving to use dnssec. Only a solution
that limits the scope to the the smallest case (ssh doing an
getrrsetbyname() for DNS_RDATATYPE_SSHFP is likely acceptable. Sadly
the context used by resolving is program-wide, so setting a flag in
_res is also not going to work.
-Otto
