On 07/12/17 18:49, Jeremie Courreges-Anglas wrote:
Eric Faurot <e...@faurot.net> writes:
On Wed, Jul 12, 2017 at 07:45:36AM +0200, Christian Barthel wrote:
Hi,
earlier this year, jca@ worked on support for DNSSEC and the EDNS0
extension [1] and committed this work at [2] (thanks!). I tried this
with SSHFP records to check authenticity of hosts with DNSSEC; but ssh
reported that the hostkey fingerprints were insecure.
I am using this configuration file:
# cat /etc/resolv.conf
nameserver 8.8.8.8
options edns0
And ssh reports the following:
$ ssh -o VerifyHostKeyDNS=yes -vvvv doamin_with_sshpf_dnssec
...
debug3: verify_host_key_dns
debug1: found 8 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
The authenticity of host 'xxxxxxxxxxx (xxxxxxxxxxxx)' can't be established.
ECDSA key fingerprint is ....
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
...
I tried to find out why and after going through the asr code, I found
the following:
Index: lib/libc/asr/res_send_async.c
===================================================================
RCS file: /cvs/src/lib/libc/asr/res_send_async.c,v
retrieving revision 1.36
diff -u -p -r1.36 res_send_async.c
--- lib/libc/asr/res_send_async.c 15 Mar 2017 15:54:41 -0000 1.36
+++ lib/libc/asr/res_send_async.c 11 Jul 2017 20:09:59 -0000
@@ -385,7 +385,7 @@ setup_query(struct asr_query *as, const
_asr_pack_query(&p, type, class, dname);
if (as->as_ctx->ac_options & (RES_USE_EDNS0 | RES_USE_DNSSEC))
_asr_pack_edns0(&p, MAXPACKETSZ,
- as->as_ctx->ac_options & RES_USE_DNSSEC);
+ as->as_ctx->ac_options & (RES_USE_EDNS0 | RES_USE_DNSSEC));
if (p.err) {
DPRINT("error packing query");
errno = EINVAL;
The current code is correct, RES_USE_EDNS0 does not imply RES_USE_DNSSEC.
The real problem is that there is no resolv.conf option for RES_USE_DNSSEC.
RES_USE_DNSSEC is set by applications that *do* care about the AD bit.
There's no point in setting globally RES_USE_DNSSEC, so I don't think we
need a resolv.conf option.
I recently ran into the same problem regarding the ssh(1) warning. I
don't understand yet why a global option in resolv.conf would be
pointless or a bad idea. For example, the following simple patch seems
to work for me, and I didn't observe any side effects yet:
Index: src/lib/libc/asr/asr.c
===================================================================
RCS file: /cvs/src/lib/libc/asr/asr.c,v
retrieving revision 1.57
diff -u -p -u -r1.57 asr.c
--- src/lib/libc/asr/asr.c 27 Feb 2017 10:44:46 -0000 1.57
+++ src/lib/libc/asr/asr.c 7 Sep 2017 15:15:44 -0000
@@ -597,6 +597,8 @@ pass0(char **tok, int n, struct asr_ctx
ac->ac_options |= RES_USEVC;
else if (!strcmp(tok[i], "edns0"))
ac->ac_options |= RES_USE_EDNS0;
+ else if (!strcmp(tok[i], "dnssec"))
+ ac->ac_options |= (RES_USE_DNSSEC |
RES_USE_EDNS0);
else if ((!strncmp(tok[i], "ndots:", 6))) {
e = NULL;
d = strtonum(tok[i] + 6, 1, 16, &e);
What am I missing here?
It can only be set in user code by tweaking _res.options.
ssh(1) uses getrrsetbyname(3) to look at SSHFP records, so the fix is to
teach getrrsetbyname to request DNSSEC processing. Eric and I have
already discussed this and need to settle on the implementation.
