In message <51fb9c18.23133.401e...@tmorizot.sd.is.irs.gov>, "Scott Morizot" wri
tes:
> Hello all,
> 
> I ran into an interesting situation resolving dfas.mil. It appears that 
> they have attempted to roll their ZSKs to algorithm 8 while leaving their 
> KSKs on algorithm 7. Unfortunately, RFC 4035 specifies that if DNSKEYs 
> for multiple algorithms exist in the apex DNSKEY RRset, then an RRSIG for 
> each record set in the zone MUST include at least one RRSIG for each 
> algorithm. (The distinction between KSK and ZSK is an operational 
> convenience and not part of the standard, per se.) The relevant excerpt 
> from Section 2.2 of RFC 4035:
> 
>    There MUST be an RRSIG for each RRset using at least one DNSKEY of
>    each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
>    itself MUST be signed by each algorithm appearing in the DS RRset
>    located at the delegating parent (if any).
> 
> DNSViz and Verisign's DNSSEC debugger correctly report the error.
> 
> http://dnssec-debugger.verisignlabs.com/dfas.mil
> 
> http://dnsviz.net/d/dfas.mil/dnssec/
> 
> However, I discovered when I checked against DNS-OARC ODVR (and my own 
> personal validating recursive nameserver at home) that BIND 9 apparently 
> doesn't correctly enforce that requirement.

Because the requirement is *only* on the signer.  You will note
that the validator is NOT required to check for this as part of the
list of things it is supposed to check for and that is a deliberate
design decision.  If the signer follows this and the timing rules
the zone will not be treated as bogus.  The unbound developers
didn't realise this initially and added unspecified checks to their
validator.

As the zone currently stands a validator that only support alg 8
will treat it as insecure as there is no DS record from alg 8.  A
validator that only supports alg 7 will treat it as secure.  A
validator that supports alg 7 and alg 8 will treat it as secure.

Remember when you introduce a new algorithm you will have cached
records that only have old signature on them which are being returned
to down stream validators and their is no syncronisation of record
expiry.  You may have a old DNSKEY set and new signatures on other
records in the zone or you may have the new DNSKEY set and old
signatures on other records in the zone.  The validator has to work
under both circumstances.

The only RRset that it is possible to perform this consistancy check
on is the DNSKEY RRset itself and both algorithms exist in the RRSIGs.

; <<>> DiG 9.10.0pre-alpha <<>> +dnssec dfas.mil dnskey +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51859
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dfas.mil.              IN DNSKEY

;; ANSWER SECTION:
dfas.mil.               25300 IN DNSKEY 257 3 7 (
                                AwEAAXLZgixJU1KVrdcv+evwuKlDFDmUQR7FsC2zghPU
                                mERiPR9wwgpuKdkQ6BQizeObACqfUwepXuBp1b3t0480
                                Oyn7OlCaaV+M/O1hH5pkCaRV69iVuWRqPAXfCu6XvHUz
                                xL2ugzwr+uYeGrRLfDNsZ1VN/b1zc33c2qdepPbcMDv7
                                8ZzXlgy1DJ6DjylOQx7Jm/5uKQiA6sA+W9ViZTHZ9BX9
                                9mQcaRqFzY4eVCGid7sgrD71hTxSOnK3b1B1gQEv8CCP
                                eZwFsCOG2/9ToTXRxRP1dvIHoWkEEGHy2czb2FbGrfiW
                                sRF1uVwoMJRX28D4QndyFy1yWLOMKh0DNyjyePc=
                                ) ; KSK; alg = NSEC3RSASHA1; key id = 4069
dfas.mil.               25300 IN DNSKEY 256 3 8 (
                                AwEAAeIV8hHiYnEiREniwiz5NkAP2yuklG9b0iEBCij0
                                F/1Z//Yps0Kk3ss9DprQXqs5MlyCwVJZ1JOIlTe3dlhW
                                +fiTBGnSlo/VeBJIfflMAdbzQh7ls9mesdr2kOyjgZzg
                                iO8snht0kGYYlr3Qa+4zvSi4p7uJ7oMYEVc7OD13P2PN
                                2pM+lwGgB78m9BXLcibw6GBiqVL2M7sY3j0BV1Zbzjd6
                                /lEWN1QVktueetc1PfTco9RiJ7vnkw9VpI/FtaKQLDIp
                                YWCRPOUoUxLk/ji5r3jez8zQbbe8VxjuH+hyMvb69GMd
                                k6Y88vskrCotECqbG/TijhPnDjhfJ0IWY5Kj8Mk=
                                ) ; ZSK; alg = RSASHA256; key id = 8389
dfas.mil.               25300 IN DNSKEY 256 3 8 (
                                AwEAAXzmgOtId7xGSjccxMfW8WlEEJKH7GTnzD58VqhF
                                2CJBN0eiyKFxQVwmSdrr9TG/mCVTbAH7RGAP/R3pYxhB
                                fBybZp+WwlryBSQIeWpgLFwwv4oLlKxopcpsFcG23Oh5
                                BxTuBPW/NCWSu6deGpkA4WQP275Q0gRwjlBKZtD3b8wD
                                PsRhL9TsxsYNzLELIW2dnE82YcZB22XVyV0NVbNE1Ks0
                                S6oZznxXCp3d2lVw8ImgVm2hCD0c9EZUi7pYf6NedMVH
                                mxI5t/JGC22z0Z1/zmQu3z76ZsEhl/uetzSqK9VczmZ3
                                JPNNbOtyQHf23lne33mxnZaAuTn81sGLyaVLS6s=
                                ) ; ZSK; alg = RSASHA256; key id = 1213
dfas.mil.               25300 IN DNSKEY 257 3 7 (
                                AwEAAenwNSQi4dIwyzW8Sk27HDklyrQM/2n/TuPRR03k
                                ql1Ln4W05Hel9tBiPQ/bmZP5ce11JojB/hekKbKljHA4
                                snytiS9Wyd0YHLm7N+kIdDjt95k+aySuJ72YXqgSbexr
                                fAOWDtiatyJmd1S/cKvC3S71QIQEUVNS+UsYqAUj6pJ9
                                X5kF3L7KS+PoPw0DXBLK6+9KcF4k4RC9siJADVvZy9ay
                                fhLq8MxjHW6Qid8nTYn3IGd7nGWfpgrNbugi/BBoYWh1
                                +kwtShZcEFx17IkUlUjwuN5nDdvCY6ALofWY9x/sxQdM
                                IZi2bprJM71V/UOrsRvRYhwcx+qqYIRLeVa0K08=
                                ) ; KSK; alg = NSEC3RSASHA1; key id = 32598
dfas.mil.               25300 IN RRSIG DNSKEY 7 2 86400 (
                                20130808070034 20130801060034 4069 dfas.mil.
                                A2oCGrAHQ+3hlMHqKb5Cst90JyQsJgcWxrbcg4r+rul5
                                J2Kg++rIOzMneVI1XDbrke/qZkgkM6+FwGGl8eDpqb5O
                                VZdDLtZx4llXeyCKjWKon9gTJu1gdHal3nKZDJsJhfL3
                                tqEbPp29XNEyFxb3m+0V6ubYXXh6n/iCSHQfAIVBmWHL
                                A0Wp5I9jldzibLK5fqgNq65JTw6/a8WHkOWI/PZMV7g0
                                eej3WzUz0C2GC5k6ULgHmSS/wAHHzHz4z0IDGV3vGkJe
                                xqHj4FhsgYDNP1cVqw7b4mJyGjKa/samugq3sUnRw0C+
                                KRP8o0J0nZos65DmMpJtb5yA9EHwMVLMFg== )
dfas.mil.               25300 IN RRSIG DNSKEY 8 2 86400 (
                                20130808070034 20130801060034 8389 dfas.mil.
                                EEpPNXelw1QusMw8awFwf7ScAkRNZOEj9RCDk/V9BsTl
                                XXvP65lCPD/QEiInJ3I9rglNllzKZxXAWRDjcemwSgkO
                                bZdUy/8rsyWm7/KDx7DtzpmS5TS4spdNgmiutH6386YE
                                tBf7hjxPR3qE1SqyY+NN4R4QQ3o0M9LGaU4tg+i2laFx
                                Gl2K6H4svUbgR8yekVOLqwD9plKGxIpYslMBOK+JW/Zs
                                Cae4yY+qwpK6iBZYRdHcvdulEz1ODeRbMsjuec0EOuvw
                                DCSY23ltsUR1Hz/D/By/QsL922DUQ3NO2ZD0HcJa1aPp
                                lGS/s+q/4yHHd8xT2t7bOse/Ro3CyQkZ5g== )

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug 02 22:18:34 EST 2013
;; MSG SIZE  rcvd: 1733


> https://www.dns-oarc.net/oarc/services/odvr
> 
> The BIND 9 resolver returns an answer with the AD bit set. Unbound 
> returns SERVFAIL. Secure64 Caches also return SERVFAIL. Those are the 
> only three nameservers I've tested.

Version 1.4.8 onwards should validate the zone.  Earlier versions were
broken.  http://www.unbound.net/documentation/info_algo.html 

> It looks like a validation bug in BIND to me, but I thought I would see 
> what others thought. It's probably a pretty rare situation, since I can't 
> imagine most people who choose to use separate KSKs and ZSKs would try to 
> migrate only their ZSKs to a new algorithm while leaving their KSKs at 
> the old algorithm.

It is not a bug.  Named is working as expected.
 
> Thanks,
> 
> Scott
> 
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
> 
> 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: ma...@isc.org
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to