On Wed, 17 Nov 2021 20:00:21 +0000, Otto Moerbeek <o...@drijf.net> 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.
> 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?
--
typedef struct me_s {
char name[] = { "Thomas Habets" };
char email[] = { "tho...@habets.se" };
char kernel[] = { "Linux" };
char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt"; };
char pgp[] = { "9907 8698 8A24 F52F 1C2E 87F6 39A4 9EEA 460A 0169" };
char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;
