Spurious "TYPE65534" at the end of a NSEC3, why?

Phil Mayers p.mayers at imperial.ac.uk
Sun Feb 13 10:51:30 UTC 2011


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.



More information about the bind-users mailing list