In message <e754e90904051454m8a240cbh17a177a069455...@mail.gmail.com>, R Dicair
e writes:
> On Sun, Apr 5, 2009 at 5:40 PM, Mark Andrews <mark_andr...@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@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_andr...@isc.org
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to