ISC DLV dnssec

[Mark Andrews]

In message <e754e90904051454m8a240cbh17a177a06945575b at mail.gmail.com>, R Dicair
e writes:
> On Sun, Apr 5, 2009 at 5:40 PM, Mark Andrews <Mark_Andrews at isc.org> wrote:
> >> Shouldn't the behaviour for DLV lookups be such that if the query
> >> can't be answered by the DLV server, then fall back to a non-dnssec
> >> lookup?
> >
> > =A0 =A0 =A0 =A0No.
> 
> May I ask why?

	You enable DNSSEC and DLV to prevent the nameserver from
	accepting forged answers from secured zones.  DLV tells
	named which zones are secured or not.  This needs to be
	secured to prevent named accepting forged answers from
	secured zones.

	B.T.W.  The servers did answer the queries.  The resolver
	just wasn't able to validate them as a signature was missing.

> I'm sure something was learned from whatever caused the DLV server to
> malfunction, but was that kind of malfunction something we can look
> forward to when . and TLDs are signed?

	Signing errors will happen.  Hopefully not too often.

> If that kind of breakage in lookups can occur, should there not be a
> contingency to be able to continue to use the Internet when such
> breakage occurs?

	Named is still able to return answers if you tell it not to
	validate the answers by setting CD=1 in the query.  This flag
	is usually used when you have a validating resolver using another
	validating resolver to get its answers.

	When the lookups were failing answers like this were returned.

; <<>> DiG 9.3.6-P1 <<>> dnskey dlv.isc.org +dnssec +cd +multi
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4255
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dlv.isc.org.		IN DNSKEY

;; ANSWER SECTION:
dlv.isc.org.		6518 IN	DNSKEY 256 3 5 (
				BEAAAAOlYGw53D+f01yCL5JsP0SB6EjYrnd0JYRBooAa
				GPT+Q0kpiN+7GviFh+nIazoB8e2Yv7mupgqkmIjObdcb
				GstYpUltdECdNpNmBvASKB9SBdtGeRvXXpORi3Qyxb9k
				HGG7SpzyYbc+KDVKnzYHB94pvqu3ZZpPFPBFtCibp/mk
				hw==
				) ; key id = 64263
dlv.isc.org.		6518 IN	DNSKEY 256 3 5 (
				BEAAAAPGBAwVFzuE6r0zjxHMug8if94gouJXT4xnKqOt
				BRNJ9KmIvHVh97hn5VN2T9z0SZ3Y2nPxTyksoX+X7L62
				QveGvHzHSEuo8iYq6INevwFTX1beCj/dhk9ZfEYkleoB
				4NUlHcam7juJWncRi/Vz/BpF2ec9fLqaAaP15AojoIoa
				Aw==
				) ; key id = 49899
dlv.isc.org.		6518 IN	DNSKEY 257 3 5 (
				BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn
				4MxDCE1+lLy2brhQv5rN32RKtMzX6Mj70jdzeND4XknW
				58dnJNPCxn8+jAGl2FZLK8t+1uq4W+nnA3qO2+DL+k6B
				D4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5ymX4BI/o
				Q+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte
				/URkY62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw
				/mRx/vwwMCTgNboMQKtUdvNXDrYJDSHZws3xiRXF1Rf+
				al9UmZfSav/4NWLKjHzpT59k/VStTDN0YUuWrBNh
				) ; key id = 19297
dlv.isc.org.		6518 IN	RRSIG DNSKEY 5 3 7200 20090504233310 (
				20090404233310 64263 dlv.isc.org.
				VXvnxUqXwPWDRL0eN3AW5obDm+8h/X+DbvqF/MPaD9NO
				1SYO6tcPvs+Ih3+kQQ/7PZxWHJjGpvIz/sSGWPUbqzyr
				LJBTq90+jUbIuCX0KYb4PAT1l5zhjC5UvOKY1Va4NoI7
				J/jGrE1hb6C/ZOlDuQR7mXTn/KwkkxK+JzpxT+0= )

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Apr  5 15:21:28 2009
;; MSG SIZE  rcvd: 786

	The trusted key entered into named.conf has key id 19297.
	There was not a signature for the DNSKEYs using this key.
	The only signature available was generated using key id 6426
	(7th field in the RRSIG record).

	Mark

> I could see online businesses panicking when something like this happens.
> 
> > =A0 =A0 =A0 =A0There was a fault which caused RRSIG of the key signing key
> > =A0 =A0 =A0 =A0to be missing. =A0The key signing key is the one listed in
> > =A0 =A0 =A0 =A0the trusted-keys clause above. =A0This caused a break in t=
> he
> > =A0 =A0 =A0 =A0chain of trust as the DNSKEY RRset could not be validated
> > =A0 =A0 =A0 =A0which meant named could not determine if the answers to the
> > =A0 =A0 =A0 =A0DLV queries were valid or not and in turn the answers to
> > =A0 =A0 =A0 =A0all other queries.
> 
> Could you provide more details as to what specifically caused the fault?
> Perhaps then other dns admins may learn something new to look for when
> having to troubleshoot a similar problem. I know it would help me
> further understand.
> 
> Thanks
> 
> -- =
> 
> aRDy Music and Rick Dicaire present:
> http://www.ardynet.com
> http://www.ardynet.com:9000/ardymusic.ogg.m3u
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org