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

Mark Andrews marka at isc.org
Mon Feb 16 20:34:37 UTC 2015 

In message <20150216163453.GA363 at nic.fr>, Stephane Bortzmeyer writes:
> [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
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

This is Unbound being overly picky unless support for algorithm 5
has been disabled / removed.  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.  The job of the validator is to
determine if the data returned is what was entered.  It is NOT to
check if every signing rule has been followed.  If the rules have
not been followed then validation will fail for some clients.

If the validator only supports algorithm 5 then you get secure.
(You have a matching DNSKEY (5/36778) + RRSIG that you can verify.)

If the validator only supports algorithm 8 then you get bogus.
	(You do not have a matching DNSKEY)

If the validator supports algorithm 5 + 8 then you get secure.
(You have a matching DNSKEY (5/36778) + RRSIG that you can verify.)

The "MUST" sign with is there to prevent the failure when the
validator only supports algorithm 8, not it trigger a failure in
the other cases.

DNSSEC checkers on the other hand should be looking for and reporting
this error.  Their job is to detect errors in the signing process.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

More information about the bind-users mailing list