openssh VerifyHostKeyDNS=yes can not verify sshfp-rr via dnssec

[enko]

When I try to ssh into a box where I have configured some sshfp-rr with dnssec, I get get the prompt that the authenticity of the host could not be established. Here is a trimmed debug output:

$ ssh -v -o "VerifyHostKeyDNS yes" xmpp.int.datenknoten.me
OpenSSH_6.9p1, OpenSSL 1.0.1q 3 Dec 2015
[…]
debug1: found 6 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
The authenticity of host 'xmpp.int.datenknoten.me (192.168.122.4)' can't be established.
ECDSA key fingerprint is SHA256:Znv9jefZTVrOGqovEI+sg29V1Nyo6d19qid+eFVqxiE.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

When I dig the the corresponding sshfp record I get the ad flag, so they should be secure?:

$ dig xmpp.int.datenknoten.me -t sshfp                                                                                       ~

; <<>> DiG 9.10.3 <<>> xmpp.int.datenknoten.me -t sshfp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63175
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;xmpp.int.datenknoten.me.       IN      SSHFP

;; ANSWER SECTION:
xmpp.int.datenknoten.me. 2955   IN      SSHFP   1 1 EEFA7FC1182780197F8D499FD2A4D7D1D3828F7C
xmpp.int.datenknoten.me. 2955   IN      SSHFP   3 1 7E27B08A6BFB87882A3255CE9424C85748DFF54B
xmpp.int.datenknoten.me. 2955   IN      SSHFP   2 2 471620FB90B43B2C757091CE23F883D665CF148D1F4A750A28053685 40A4F654
xmpp.int.datenknoten.me. 2955   IN      SSHFP   2 1 D1E16C35F86A1F23EB518813E94923C0E359E6AB
xmpp.int.datenknoten.me. 2955   IN      SSHFP   3 2 667BFD8DE7D94D5ACE1AAA2F108FAC836F55D4DCA8E9DD7DAA277E78 556AC621
xmpp.int.datenknoten.me. 2955   IN      SSHFP   1 2 D2C812B6EA990AC9E1BA8FD6ECAAE9E3F01301D31F5461ED79541F0A C3BEBBF7

On a freebsd box with OpenSSH_6.6.1p1 and a debian box with OpenSSH_6.7p1 this feature works flawless: I can login without manual intervention.

[enko]

I dug a bit into it and seems debian is patching its ssh with this patch:

http://anonscm.debian.org/cgit/pkg-ssh/openssh.git/plain/debian/patches/dnssec-sshfp.patch

Which seem to fix this issue.

[enko]

Setting options edns0 also fixes this option. What should be done? Closing this ticket? If yes how would I set this option in my configuration.nix?

[peti]

Is this options edns0 documented somewhere? I cannot find that in the OpenSSH man pages.

[enko]

Sorry to mention this, it is an option of resolv.conf.

[peti]

The option networking.extraResolvconfConf from configuration.nix allows you to set extra things to pass to the resolvconf program that generates that file. Maybe that helps?

[enko]

So setting networking.extraResolvconfConf = "resolv_conf_options='edns0'"; made it.

Maybe this could be made into an extra option like dnsSingleRequest? Promoting the use of dnssec and making it more easy to use would be a good thing?

[vcunat]

Hmm, have you found a reason not to enable edns0 by default? The RFC defining it is very old now and all reasonable DNS resolvers will support it now.

[peti]

I am not aware of any reason why edns0 should not be enabled by default. I know that other distributions don't enable it, but it's probably an arbitrary choice. Personally, I don't find DNSSEC very useful, so I lean towards not enabling it. I don't feel strongly about this issue though.

[vcunat]

DNSSEC is mainly interesting on resolver side. Resolvers should validate data (according to DNSSEC) even if the client doesn't express any interest in that.

There are other advantages in client setting edns0 in the query, though probably nothing that would feel significant to most users. For example, it permits to get much longer reply in a single UDP. Without it only 512B is allowed.

I'll test that locally for some time to check for larger problems.

[vcunat]

Pushed 11696e2.

[peti]

Uh oh.

[vcunat]

(I'm not sure how to understand that :)

[vegai]

Perhaps this is what peti meant: #24433 breaks for me :)

Perhaps this can still be the new default, but it should be probably documented properly since the risk of breaking against consumer routers.