Only tangential relevant: RFC 6840:
5.7. Setting the AD Bit on Queries The semantics of the Authentic Data (AD) bit in the query were previously undefined. Section 4.6 of [RFC4035] instructed resolvers to always clear the AD bit when composing queries. This document defines setting the AD bit in a query as a signal indicating that the requester understands and is interested in the value of the AD bit in the response. This allows a requester to indicate that it understands the AD bit without also requesting DNSSEC data via the DO bit. I'm currently on a small device, so let me just add that this is a problem space I wanted to explore. I firmly believe that we must only trust AD answers if they are coming from localhost (i.e. unwind). I have not looked what we need to do in asr for this. On 17 November 2021 21:00:21 CET, Otto Moerbeek <o...@drijf.net> wrote: >On Wed, Nov 17, 2021 at 10:45:45AM -0800, Thomas Habets wrote: > >> OpenSSH calls getrrsetbyname() in dns.c:verify_host_key_dns(). >> It then checks for RRSET_VALIDATED, which is only set if the DNS response >> has the 'ad' attribute set. >> >> getrrsetbyname() in turn uses res_.* to do DNS requests, but doesn't set >> RES_USE_DNSSEC when doing so. >> Thus the DNS query that goes out does not have the 'ad' bit set, causing >> the response too to not have 'ad' set. > >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 > >Signalling that yo want a DNSSEC validated answer is normally done by >setting the DO bit in the EDNS options. > >> >> From my looking at the call stack there's actually no way for OpenSSH, or >> the user via env or /etc/resolv.conf, to set RES_USE_DNSSEC. >> >> 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. > >> 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. > > >> 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. > >> >> else if (!strcmp(tok[i], "edns0")) >> ac->ac_options |= RES_USE_EDNS0; > > -Otto > >> >> >> [1] >> https://cvsweb.openbsd.org/src/usr.bin/ssh/dns.c?rev=1.41&content-type=text/x-cvsweb-markup >> [2] >> https://cvsweb.openbsd.org/src/lib/libc/asr/asr.c?rev=1.66&content-type=text/x-cvsweb-markup >> [3] I realize that the path from the recursive resolver to the machine must >> be secure. I'm using 8.8.8.8 as an example. >> https://serverfault.com/questions/1063853/sshfp-not-working >> >> -- >> typedef struct me_s { >> char name[] = { "Thomas Habets" }; >> char email[] = { "tho...@habets.se <tho...@habets.pp.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; > -- Sent from a mobile device. Please excuse poor formatting.
