Re: ISC DLV dnssec
In message e754e90904051051i60b347b6paf44a833c02a8...@mail.gmail.com, R Dicai
re writes:
Hi folks, last night the ISC server responsible for responding to DLV
lookups was apparently down. Since all lookups were failing due to a
lack of response from this server, bind couldn't resolve anything at
all. I had to comment out a couple lines in named.conf to restore
function.
bind-9.4.3-P2
Here's the dnssec configuration lines used in named.conf:
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside . trust-anchor dlv.isc.org.;
trusted-keys {
dlv.isc.org. 257 3 5
BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2
brhQv5rN32RKtMzX6Mj70jdzeN
D4XknW58dnJNPCxn8+jAGl2FZLK8t+
1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5
ymX4BI/oQ+cAK50/xvJv00Frf
8kw6ucMTwFlgPe+jnGxPPEmHAte/URk
Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM
QKtUdvNXDrYJDSHZws3xiRXF
1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh;
};
I'm not sure, but if a lookup fails dnssec auth, shouldn't bind treat
the answer as insecure, and return said answer?
No. Otherwise you could cause the nameserver to accept a
bogus answer when it shouldn't.
In the scenario described above, I wasn't even able to get answers,
let alone whether said answers could be authenticated.
Bv9ARM.pdf is unclear regarding how bind should behave regarding use
of dnssec-validation directive.
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?
No.
Perhaps there's a configuration issue I'm using that caused this
unexpected behaviour I describe?
There was a fault which caused RRSIG of the key signing key
to be missing. The key signing key is the one listed in
the trusted-keys clause above. This caused a break in the
chain of trust as the DNSKEY RRset could not be validated
which meant named could not determine if the answers to the
DLV queries were valid or not and in turn the answers to
all other queries.
Mark
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
Re: ISC DLV dnssec
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? No. May I ask why? 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? 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? I could see online businesses panicking when something like this happens. There was a fault which caused RRSIG of the key signing key to be missing. The key signing key is the one listed in the trusted-keys clause above. This caused a break in the chain of trust as the DNSKEY RRset could not be validated which meant named could not determine if the answers to the DLV queries were valid or not and in turn the answers to all 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
Re: ISC DLV dnssec
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. As I understand it (and I wasn't involved in diagnosing the problem, so I'm going by second-hand reports): ISC's signatures are kept up to date by a script. The private keys are stored offline for security, signatures are periodically generated by an internal, firewalled machine and then scp'd into place on the master server. The script that does all this failed, due to an unexpected variation in the input format, with the result that dnssec-signzone was run without all of the private keys in place. Signing with a subset of the private keys is legal, so dnssec-signzone didn't issue an error message. Unfortunately in this case it was also wrong, and it caused a temporary break in the chain of trust. Oops. Sorry. Lessons learned: The script is being improved, and we ourselves are more vigilant; this particular failure won't occur again. And we were already in the process of making dlv.isc.org substantially more robust, so hopefully any similar breakages that might have come along in the future will be stopped before they happen. I expect this to influence future BIND development too (for example, dnssec-signzone will probably be learning to print a few more warning messages when it sees legal-but-weird input.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC DLV dnssec
On Sun, Apr 5, 2009 at 7:02 PM, Evan Hunt evan_h...@isc.org wrote: vigilant; this particular failure won't occur again. And we were already in the process of making dlv.isc.org substantially more robust, so hopefully any similar breakages that might have come along in the future will be stopped before they happen. Excellent. But what about contingencies for continued dns resolution when an unintended break in the chain of trust occurs? I expect this to influence future BIND development too (for example, dnssec-signzone will probably be learning to print a few more warning messages when it sees legal-but-weird input.) This too is excellent, and I'd hope fixes be backported to 9.4 and 9.5 releases as well. Thanks Paul for the response, very helpful and informative! And kudos to the DLV folks for the service! -- 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
Re: ISC DLV dnssec
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 ( BEOlYGw53D+f01yCL5JsP0SB6EjYrnd0JYRBooAa GPT+Q0kpiN+7GviFh+nIazoB8e2Yv7mupgqkmIjObdcb GstYpUltdECdNpNmBvASKB9SBdtGeRvXXpORi3Qyxb9k HGG7SpzyYbc+KDVKnzYHB94pvqu3ZZpPFPBFtCibp/mk hw== ) ; key id = 64263 dlv.isc.org.6518 IN DNSKEY 256 3 5 ( BEPGBAwVFzuE6r0zjxHMug8if94gouJXT4xnKqOt BRNJ9KmIvHVh97hn5VN2T9z0SZ3Y2nPxTyksoX+X7L62 QveGvHzHSEuo8iYq6INevwFTX1beCj/dhk9ZfEYkleoB 4NUlHcam7juJWncRi/Vz/BpF2ec9fLqaAaP15AojoIoa Aw== ) ; key id = 49899 dlv.isc.org.6518 IN DNSKEY 257 3 5 ( BEPHMu/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
Re: ISC DLV dnssec
On Sun, Apr 5, 2009 at 8:48 PM, Mark Andrews mark_andr...@isc.org wrote: 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. The one thing I didn't do was a direct dig itself. I was tailing dnssec.log and watching the DLV lookups failing, and my web browser was failing to load any site, reporting the hostname couldn't be resolved. Above, you mention setting CD=1 in the query. How is this done by applications trying to resolve hostnames when there's a problem like last nights? Would setting the named.conf directive dnssec-validation no; do this? (as I mentioned previously, I had to comment out dnssec-validation and the trust anchor directive that points to ISC so I could resolve queries) -- 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
Re: ISC DLV dnssec
In message e754e90904051805i6ac1dda6k57f78be2cf00a...@mail.gmail.com, R Dicai re writes: On Sun, Apr 5, 2009 at 8:48 PM, Mark Andrews mark_andr...@isc.org wrote: 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. The one thing I didn't do was a direct dig itself. I was tailing dnssec.log and watching the DLV lookups failing, and my web browser was failing to load any site, reporting the hostname couldn't be resolved. Above, you mention setting CD=1 in the query. How is this done by applications trying to resolve hostnames when there's a problem like last nights? Only DNSSEC aware validating applications should do this. Would setting the named.conf directive dnssec-validation no; do this? (as I mentioned previously, I had to comment out dnssec-validation and the trust anchor directive that points to ISC so I could resolve queries) Which is a reasonable response. DNSSEC is a bit like digital TV it's all or nothing. Zones will work or not if there are operator errors. DLV is just a very critical zone in that it works out which zone are secure or not so it is involved in every lookup which is not part of a seperately configured island of trust. When the root is signed and you have a trust anchor for the root configured DLV will be used to bridge the gaps in the delegation chains. Lookups in secure zones for which there is a theoretical secure path won't use DLV. Mark -- = 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
