Re: Spurious TYPE65534 at the end of a NSEC3, why?
On Mon, Feb 14, 2011 at 01:50:49PM +1100, Mark Andrews ma...@isc.org wrote a message of 40 lines which said: I could reproduce it in 9.7.1-P1 by just adding a DNSKEY record at the apex I cannot reproduce it. Any more detailed instructions? It will be more difficult to convince the people in charge of the operations to upgrade if I cannot exhibit a test case... ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Spurious TYPE65534 at the end of a NSEC3, why?
On Mon, Feb 14, 2011 at 10:37:57AM +0100, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 10 lines which said: I cannot reproduce it. Now, it works. Bug report sent to ISC [ISC-Bugs #23232] No, it is not fixed in recent BINDs. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Spurious TYPE65534 at the end of a NSEC3, why?
On Sun, Feb 13, 2011 at 11:07:31AM +0100, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 35 lines which said: Here is a master server BIND 9.7.1-P2 (with patches for PKCS#11 and the AEP keyper HSM), with DNSSEC enabled, dynamically signing records. ... at least in the second case, it was when updating a DNSKEY record (an old ZSK was retired). I was not very clear, sorry: all provisioning is done (DNSKEY included) with dynamic updates. BIND is therefore responsible for keeping the NSEC3 chain (we use opt-out, by the way), and for signing, although the actual crypto is done by an AEP Keyper HSM. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Spurious TYPE65534 at the end of a NSEC3, why?
On 02/13/2011 10:07 AM, Stephane Bortzmeyer wrote:
Note the TYPE65534, which I cannot explain. Greping bind-users
archives, or googling, reveal that other persons saw them but I did
not find a final explanation.
This is documented in the Bind ARM (at least, the one that comes with
the 9.8 beta). See Chapter 4, Private-type records. Basically they
store signing process state.
i.e. the *presence* of the record is normal.
When this happens, the signature:
meqimi6fje5ni47pjahv5qigu1lv3jlj.fr. 5400 IN RRSIG NSEC3 8 2 5400
20110408081500 20110207081500 2331 fr.
OFDRwZAgzDT1y8fTJ1XCfHlajEAHzqk2dsJaCR1TSednnBSEkctIUP6AsZuD+EOZtEPCM2Oe3cI/fG2GfA1nAUDaS1INN3I6YRpB3n2/oCfKBvs68fvCexBOIgz+oc74VrPvjDtPkVyGbJ5ImSlwu8Uc8rTXKh47CdS0AdJLmso=
is flagged as invalid by a BIND ('meqimi6fje5ni47pjahv5qigu1lv3jlj.fr
NSEC3: no valid signature found') or an Unbound resolver ('debug:
verify: signature mismatch'). I fancy that the spurious TYPE65534 may have
been added after the signing.
That is, presumably, not normal.
I'm not very familiar with NSEC3 so can't say why it's happening.
Suffice to say we have these records in our NSEC zone and they don't
cause a problem.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Spurious TYPE65534 at the end of a NSEC3, why?
On 02/13/2011 10:40 AM, Stephane Bortzmeyer wrote: On Sun, Feb 13, 2011 at 11:07:31AM +0100, Stephane Bortzmeyerbortzme...@nic.fr wrote a message of 35 lines which said: Here is a master server BIND 9.7.1-P2 (with patches for PKCS#11 and the AEP keyper HSM), with DNSSEC enabled, dynamically signing records. ... at least in the second case, it was when updating a DNSKEY record (an old ZSK was retired). I was not very clear, sorry: all provisioning is done (DNSKEY included) with dynamic updates. BIND is therefore responsible for keeping the NSEC3 chain (we use opt-out, by the way), and for signing, although the actual crypto is done by an AEP Keyper HSM. The zone at the moment seems to be signed with NSEC; are you trying to perform an online transition from NSEC to NSEC3 via dynamic update? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Spurious TYPE65534 at the end of a NSEC3, why?
On 02/13/2011 11:30 AM, Stephane Bortzmeyer wrote: On Sun, Feb 13, 2011 at 11:01:48AM +, Phil Mayersp.may...@imperial.ac.uk wrote a message of 23 lines which said: The zone at the moment seems to be signed with NSEC; Hmmm, no, .FR has been signed by NSEC3 from the beginning. Could you post this strange dig output? Ignore me; I'm being an idiot and mis-reading the dig output. It is, of course, NSEC3. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Spurious TYPE65534 at the end of a NSEC3, why?
On Sun, Feb 13, 2011 at 11:01:48AM +, Phil Mayers p.may...@imperial.ac.uk wrote a message of 23 lines which said: The zone at the moment seems to be signed with NSEC; Hmmm, no, .FR has been signed by NSEC3 from the beginning. Could you post this strange dig output? are you trying to perform an online transition from NSEC to NSEC3 via dynamic update? I wouldn't dare :-) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Spurious TYPE65534 at the end of a NSEC3, why?
On Sun, Feb 13, 2011 at 10:51:30AM +,
Phil Mayers p.may...@imperial.ac.uk wrote
a message of 31 lines which said:
This is documented in the Bind ARM
OK, thanks, I missed this section.
i.e. the *presence* of the record is normal.
I'm not convinced (and the ARM is far from clear about it).
Most of the time, we have *no* such record ('dig @a.nic.fr ANY fr.' if
you want to check). When they appear, it seems to be always connected
with the problem.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Spurious TYPE65534 at the end of a NSEC3, why?
On Sun, Feb 13, 2011 at 11:07:31AM +0100,
Stephane Bortzmeyer bortzme...@nic.fr wrote
a message of 35 lines which said:
is flagged as invalid by a BIND ('meqimi6fje5ni47pjahv5qigu1lv3jlj.fr
NSEC3: no valid signature found') or an Unbound resolver ('debug:
verify: signature mismatch'). I fancy that the spurious TYPE65534 may have
been added after the signing.
I managed, by a lot of copy-and-paste from kept dig answers, to
reproduce the problem. Tests have been done with
http://www.verisignlabs.com/dnssec-tools/. When I use the NSEC3 with
TYPE65534, I get:
WARNING: Signature failed to verify RRset:
rr: meqimi6fje5ni47pjahv5qigu1lv3jlj.fr. 5400IN NSEC3
1 1 1 BADFE11A O5SMCS6CUNUQC5RFJ6S94TGGRFH1TVC7 NS SOA TXT NAPTR
RRSIG DNSKEY NSEC3PARAM TYPE65534
sig: meqimi6fje5ni47pjahv5qigu1lv3jlj.fr. 5400IN RRSIG
NSEC3 8 2 5400 20110408081500 20110207081500 2331
fr.
OFDRwZAgzDT1y8fTJ1XCfHlajEAHzqk2dsJaCR1TSednnBSEkctIUP6AsZuD+EOZtEPCM2Oe3cI/fG2GfA1nAUDaS1INN3I6YRpB3n2/oCfKBvs68fvCexBOIgz+oc74VrPvjDtPkVyGbJ5ImSlwu8Uc8rTXKh47CdS0AdJLmso=
Reason: Signature failed to verify cryptographically
If I remove by hand the TYPE65534, leaving the signature intact, the
problem disappeared.
% diff fr-with-type65534 fr-with-type65534-removed
4d3
fr. 0 IN TYPE65534 \# 0
25c24
meqimi6fje5ni47pjahv5qigu1lv3jlj.fr. 5400 IN NSEC3 1 1 1 BADFE11A
O5SMCS6CUNUQC5RFJ6S94TGGRFH1TVC7 NS SOA TXT NAPTR RRSIG DNSKEY
NSEC3PARAM TYPE65534
---
meqimi6fje5ni47pjahv5qigu1lv3jlj.fr. 5400 IN NSEC3 1 1 1 BADFE11A
O5SMCS6CUNUQC5RFJ6S94TGGRFH1TVC7 NS SOA TXT NAPTR RRSIG DNSKEY
NSEC3PARAM
I also checked again that TYPE65534 is *not* served by BIND in the
normal situation, even when I dynamically update the zone and BIND
modifies the NSEC3 chain and the signatures.
So, it really seems there is a BIND bug here. I guess that the
TYPE65534 was wrongly added to the NSEC3 after it has been signed.
Many thanks to Gilles Massen for his help and ideas and solutions.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Spurious TYPE65534 at the end of a NSEC3, why?
On 02/13/2011 11:35 AM, Stephane Bortzmeyer wrote: On Sun, Feb 13, 2011 at 10:51:30AM +, Phil Mayersp.may...@imperial.ac.uk wrote a message of 31 lines which said: This is documented in the Bind ARM OK, thanks, I missed this section. i.e. the *presence* of the record is normal. I'm not convinced (and the ARM is far from clear about it). Well, you're correct that they are absent most of the time. OTOH I have a zone (NSEC not NSEC3) which is managed by dynamic updates currently has a TYPE65534 at the apex, and the NSEC record names the TYPE65534 and it's RRSIG is valid - try: dig +dnssec bar.ic.ac.uk (assuming the TYPE65534 doesn't vanish... in the meantime) IOW, it sounds like a bug in the code for NSEC3, because I think it works for NSEC. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Spurious TYPE65534 at the end of a NSEC3, why?
In message 4d5806ef.7000...@imperial.ac.uk, Phil Mayers writes: On 02/13/2011 11:35 AM, Stephane Bortzmeyer wrote: On Sun, Feb 13, 2011 at 10:51:30AM +, Phil Mayersp.may...@imperial.ac.uk wrote a message of 31 lines which said: This is documented in the Bind ARM OK, thanks, I missed this section. i.e. the *presence* of the record is normal. I'm not convinced (and the ARM is far from clear about it). Well, you're correct that they are absent most of the time. OTOH I have a zone (NSEC not NSEC3) which is managed by dynamic updates currently has a TYPE65534 at the apex, and the NSEC record names the TYPE65534 and it's RRSIG is valid - try: dig +dnssec bar.ic.ac.uk (assuming the TYPE65534 doesn't vanish... in the meantime) IOW, it sounds like a bug in the code for NSEC3, because I think it works for NSEC. I could reproduce it in 9.7.1-P1 by just adding a DNSKEY record at the apex but not in 9.7.2. There were a number of NSEC3 fixes between 9.7.1 and 9.7.2. Upgrade. ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
