Spurious "TYPE65534" at the end of a NSEC3, why?
Stephane Bortzmeyer
the AEP keyper HSM), with DNSSEC enabled, dynamically signing
records. Most of the time, the typical NSEC3 looks like ('dig +dnssec
@a.nic.fr A www.toto.fr' if you want to see it):
meqimi6fje5ni47pjahv5qigu1lv3jlj.fr. 5400 IN NSEC3 1 1 1 BADFE11A O5SMCS6CUNUQC5RFJ6S94TGGRFH1TVC7 NS SOA TXT NAPTR RRSIG DNSKEY NSEC3PARAM
The list of NS records is sound. But from time to time, we see BIND
producing strange NSEC3 records like:
meqimi6fje5ni47pjahv5qigu1lv3jlj.fr. 5400 IN NSEC3 1 1 1 BADFE11A O5SMCS6CUNUQC5RFJ6S94TGGRFH1TVC7 NS SOA TXT NAPTR RRSIG DNSKEY NSEC3PARAM TYPE65534
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.
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.
The problem occurred twice
<http://operations.afnic.fr/en/2011/02/12/dnssec-validating-resolving-issue.html>
and, at least in the second case, it was when updating a DNSKEY record
(an old ZSK was retired).
Stephane Bortzmeyer
Stephane Bortzmeyer <bortz...@nic.fr> wrote
> 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.
Phil Mayers
> 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.
Phil Mayers
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?
Stephane Bortzmeyer
Phil Mayers <p.ma...@imperial.ac.uk> wrote
> 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 :-)
Phil Mayers
> On Sun, Feb 13, 2011 at 11:01:48AM +0000,
> Phil Mayers<p.ma...@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.
Stephane Bortzmeyer
Phil Mayers <p.ma...@imperial.ac.uk> wrote
> 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.
Stephane Bortzmeyer
Stephane Bortzmeyer <bortz...@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. 5400 IN NSEC3
1 1 1 BADFE11A O5SMCS6CUNUQC5RFJ6S94TGGRFH1TVC7 NS SOA TXT NAPTR
RRSIG DNSKEY NSEC3PARAM TYPE65534
sig: meqimi6fje5ni47pjahv5qigu1lv3jlj.fr. 5400 IN 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.
Phil Mayers
> On Sun, Feb 13, 2011 at 10:51:30AM +0000,
> Phil Mayers<p.ma...@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.
Mark Andrews
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-...@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
Stephane Bortzmeyer
Mark Andrews <ma...@isc.org> wrote
> 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...
Stephane Bortzmeyer
Stephane Bortzmeyer <bortz...@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.