[DNSSEC] BIND validates but not Unbound: who is right?

Stephane_Bortzmeyer · February 16, 2015, 4:34pm

[The domain has recently changed its configuration so do not test it.]

With Unbound, I get a SERVFAIL:

% dig DNSKEY cepn.asso.fr

; <<>> DiG 9.9.5-8-Debian <<>> DNSKEY cepn.asso.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62442
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;cepn.asso.fr. IN DNSKEY

;; Query time: 21 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon Feb 16 16:57:58 CET 2015
;; MSG SIZE rcvd: 41

But BIND accepts it (and so does Google Public DNS):

% dig @relay1.nic.fr DNSKEY cepn.asso.fr

; <<>> DiG 9.9.5-8-Debian <<>> @relay1.nic.fr DNSKEY cepn.asso.fr
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30861
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;cepn.asso.fr. IN DNSKEY

;; ANSWER SECTION:
cepn.asso.fr. 7808 IN DNSKEY 257 3 5 (
        AwEAAaBtXBNAyFHVvRBB4K9z79+1YRXkUDyycyCzPRpm
        Xi9lhB0Eg5vM3XlaS6OuN0dnFHItpZFNIDBDrPsN1OCf
        1ULKWpD3KDl1mE7zRK2W0HXeu4WOoFpUcC/1h06W26DT
        CkisntU9L8JfPi9osmI+CuzWZhdmyZt+hPvMpjmDthyh
        MZpb//kNv7+TUeczCo4MExHxjHHIVH0vRmhfyo/J1KBe
        6eS3G5lDbJEEFUdxuLyGQLaG2f6wlQxoHGnzvM+V/Mj8
        yGHae//7Z5rMCdaiLJy03u5+l2WVVy954dsrFC6mkB5s
        M4n8nvbo1d5ap7cI76dJi9X0IUJQohZk5b5eef0=
        ) ; KSK; alg = RSASHA1; key id = 36778
cepn.asso.fr. 7808 IN DNSKEY 256 3 5 (
        AwEAAc6AqnBoi+hfxMqtb0eokyqWT46Os5N6ZYoFm8Gb
        t90EF3hTpuwDClEsulKSckhr4zFTDj3SvHc9krzeQEl5
        UNCqmmZeMo/wsxKHTzIVU75fPrs1zOuM9m9zRNV4q9eG
        Y0+I2h4D7E/WlPE7n57E0lmPOxK9g46xE8p9eX3bWVVK
        FSm60VvginZfTzN3Zgt+peecrboEZnSzWvDVcHY2dq+o
        w0UEekI1+nfwcIgEOn0Wh8B5Gx3pG5XkV3QvHVN514FH
        eJLdsk0iFPHv1Xc0rLYWssFVS9s7Z8u0tEju6LshGaPQ
        +zrQr54RMD9IecwbMCERcrjV2Dm5CZq+Jf53pGc=
        ) ; ZSK; alg = RSASHA1; key id = 54030
cepn.asso.fr. 7808 IN RRSIG DNSKEY 5 3 10800 (
        20250115124200 20150216080551 36778 cepn.asso.fr.
        fc1YnbjbglVC8alL9NN9LUo54kUODgk6gblFt+CjDJ4+
        0i9HqEdbbW/49wksEMkFySPf24yRaswbf9W/OHeJtXid
        6CEcVdZiHfPuTzxBelQVfPiIQreJ9yvxBF1z/pmTBf0X
        o8TEMUjaV4f2c5eqELKdZ986RRk6J35tDd0w3cbeHGV1
        mnAagjT+SOLlmF8mx6MZkgsgFylBIt0MfEaX1ZS4PfAh
        TCIXi6shM0KcwZ7rI24nVGcu6wDfxdiwUZ5lJ6KWFBsM
        pC0beLiKRYlqnQidkech+dlSHQGj0DXAINi6ZrS+iRhv
        mCLlId4oezMaxx8P3dLo71cAqPGNBwM62A== )
cepn.asso.fr. 7808 IN RRSIG DNSKEY 5 3 10800 (
        20250115124200 20150216080551 54030 cepn.asso.fr.
        v1b7K0jZ4WH1yMCvJHOkxWp7EUHtsFPpKjwplu8EhqDs
        WAwB0ORSFMN6Y0PDMfSydXeSwn3+L75OKk1Ne6VNaE5E
        jeYi7BEChE0wZH1L6/qyIHgw0YCDfQN4HuG005RFRKgi
        p1t06h3iKnVHFzduSxSby5Oq3iZgbyaSPeAhDa/LZPXv
        oNb1cVmVrPKTIhZqSxKNC0t4XQ3iUffgrLvq1ErFeuut
        QQeD3uzwWXCUkZA5rK7fp9eKKlSOJpP3na2r8cEy0WlC
        jZ2HNPA6pIUnq+w7eD0oGp0aukJ1C85TeE1a8cr3Luf8
        LnSXm7cIxSWOdw9GZEjaavWFfpYdguFxQQ== )

;; Query time: 1 msec
;; SERVER: 2001:67c:2218:9::4:162#53(2001:67c:2218:9::4:162)
;; WHEN: Mon Feb 16 17:01:03 CET 2015
;; MSG SIZE rcvd: 1193

I also tested with OARC's ODVR service which confirmed that there is a
difference between BIND and Unbound.

At the time of the test, the DS were:

% dig DS cepn.asso.fr

; <<>> DiG 9.9.5-8-Debian <<>> DS cepn.asso.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6975
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;cepn.asso.fr. IN DS

;; ANSWER SECTION:
cepn.asso.fr. 171998 IN DS 36778 5 2 (
        D21FC827CF4621DF88D06A8F6EA5F4B4DE72A362AB2E
        03D440C315A9D8FE1407 )
cepn.asso.fr. 171998 IN DS 13585 8 2 (
        AB057D7A9BBDB721EBD33FC64F3C6CC53D9020D12F18
        BCEFC696494C9F9D6111 )
cepn.asso.fr. 171998 IN RRSIG DS 8 3 172800 (
        20150321132707 20150120132707 36264 fr.
        sotb2QNe0eJ6v6AxNaRgOzwYZVpg4XwDvRNp2S01kW/B
        ImMpX5oYo2EpIkmbcO+1y+yNjk0tqyiEo1OJbxzpyV1X
        xrUDQXjV1qbLgxZD3xLe9UG/VsMpImZJaiXjyd5xCT31
        sPmNdh8d/T5FzWTb6jGWUY1GC4WHp8Ib4I9GWgI= )

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon Feb 16 16:58:19 CET 2015
;; MSG SIZE rcvd: 299

DNSviz, like Unbound, says the domain is broken:

http://dnsviz.net/d/cepn.asso.fr/VOGwhA/dnssec/

But Zonemaster sees no problem:

http://zonemaster.net/test/3713

Stephane_Bortzmeyer · February 16, 2015, 9:28pm

a message of 171 lines which said:

The validator is *not* supposed to *check* if the zone has been
signed with all the alogorithms in the DS RRset. It is supposed to
keep trying all RRSIG/DS/DNSKEY combinations until it succeeds.

For the record, the relevant RFC seems to be RFC 6840, section 5.11,
"A signed zone MUST include a DNSKEY for each algorithm present in the
zone's DS RRset and expected trust anchors for the zone. The zone
MUST also be signed with each algorithm (though not each key) present
in the DNSKEY RRset."

It seems that the zone violated the first requirment (there was an
alg. 8 in the DS RRset but not in the DNSKEY RRset) but not the second
(there was only alg. 5 in the DNSKEY RRset).

Casey_Deccio · February 16, 2015, 9:50pm

With Unbound, I get a SERVFAIL:

...

But BIND accepts it (and so does Google Public DNS):

...

DNSviz, like Unbound, says the domain is broken:

<http://dnsviz.net/d/cepn.asso.fr/VOGwhA/dnssec/>

"Broken" is a loaded term. There are definitely errors with cepn.asso.fr,
namely that because both algorithms 5 and 8 show up in the DS RRset, the
zone MUST be signed with both, i.e., RRSIGs for each algorithm should be
MUST accompany any RRset in the response. This is specified in RFC 4035,
Sec 2.2.

However, this requirement is clarified in RFC 6840, Sec. 5.11 as follows:

   This requirement applies to servers, not validators. Validators
   SHOULD accept any single valid path. They SHOULD NOT insist that all
   algorithms signaled in the DS RRset work, and they MUST NOT insist
   that all algorithms signaled in the DNSKEY RRset work.

Thus, as Mark pointed out, these particular errors should not affect the
validation of cepn.asso.fr, for validators that understand both algorithms
5 and 8.

Note that DNSViz handles such cases by displaying the errors (i.e., with
the red error sign), but still showing the validation status of the RRsets
as "secure" (denoted by the blue-ish color).

http://dnsviz.net/d/cepn.asso.fr/VOGwhA/dnssec/

However, you can "see" the reason for the requirement of the signer (i.e.,
that it contains RRSIGs for each algorithm in the DS) in the following
example. Suppose a validator does not support algorithm 5 (e.g., due to
implementation deficiency, administrative policy, or because algorithm has
been declared obsolete for some reason). The chain of trust now looks like
this:

http://dnsviz.net/d/cepn.asso.fr/VOGwhA/dnssec/?rr=all&a=8&ds=all&ta=.&ta=dlv.isc.org.&tk=

As far as the validator is concerned, there should be a secure path for
both algorithms (as indicated by the algorithms in the DS records). It
can't choose one or the other because algorithm 5 is not an option. So it
turns to algorithm 8. However, because there is no path for algorithm 8,
the chain is broken.

Cheers,
Casey

Yuri_Schaeffer · February 16, 2015, 9:57pm

The validator is *not* supposed to *check* if the zone has been
signed with all the alogorithms in the DS RRset. It is supposed
to keep trying all RRSIG/DS/DNSKEY combinations until it
succeeds

For the record, the relevant RFC seems to be RFC 6840, section
5.11, "A signed zone MUST include a DNSKEY for each algorithm
present in the zone's DS RRset and expected trust anchors for the
zone. The zone MUST also be signed with each algorithm (though not
each key) present in the DNSKEY RRset."

It seems that the zone violated the first requirment (there was an
alg. 8 in the DS RRset but not in the DNSKEY RRset) but not the
second (there was only alg. 5 in the DNSKEY RRset).

It's only fair to include the rest of section 5.11:

   This requirement applies to servers, not validators. Validators
   SHOULD accept any single valid path. They SHOULD NOT insist that all
   algorithms signaled in the DS RRset work, and they MUST NOT insist
   that all algorithms signaled in the DNSKEY RRset work. A validator
   MAY have a configuration option to perform a signature completeness
   test to support troubleshooting.

Thus indeed "The validator is *not* supposed to *check* (...)". But it
does give the validator some leeway to actually enforce that MUST from
your quote. To come back at your question, who's right Unbound or
BIND?: Unbound is more strict. The authority was wrong.

//Yuri

Stephane_Bortzmeyer · February 18, 2015, 10:31am

a message of 28 lines which said:

That is a instruction to the signer. It is NOT a instuction to the
validator to check.

OK, I get it. Here is a summary of the issue. Does it seem OK? I
intend to file bug reports against Unbound and Zonemaster about it.

(attachments)

cepn-asso-fr.md (7.27 KB)
cepn-asso-fr.pdf (107 KB)

Stephane_Bortzmeyer · February 18, 2015, 7:23pm

a message of 2231 lines which said:

I intend to file bug reports against Unbound and Zonemaster about
it.

For Unbound, this is
<https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=644>

Note the text Wouter references:
<http://unbound.net/documentation/info_algo.html>