validns icon indicating copy to clipboard operation
validns copied to clipboard
verified publisher icon tobez

BIND auto-signing or validns?

Open bortzmeyer opened this issue 12 years ago • 6 comments

I get an error:

% validns -p all -z example example.signed-text 
example.signed-text:15: example. RRSIG(TYPE65534): bad signature
example.signed-text:3: example. RRSIG(SOA): bad signature

The zone is maintained by BIND "auto-dnssec maintain;" feature (auto-signing). Since the signed zone is in binary format, I extracted it with:

named-compilezone -j -i none -f raw -F text -o example.signed-text  example  example.signed

Is it a bad procedure? A bug in BIND? In validns?

The actual zone file is in https://gist.github.com/bortzmeyer/6105081

bortzmeyer avatar Jul 29 '13 15:07 bortzmeyer

On Mon, Jul 29, 2013 at 08:15:35AM -0700, Stéphane Bortzmeyer wrote:

I get an error:

% validns -p all -z example example.signed-text 
example.signed-text:15: example. RRSIG(TYPE65534): bad signature
example.signed-text:3: example. RRSIG(SOA): bad signature

The zone is maintained by BIND "auto-dnssec maintain;" feature (auto-signing). Since the signed zone is in binary format, I extracted it with:

named-compilezone -j -i none -f raw -F text -o example.signed-text  example example.signed

Is it a bad procedure? A bug in BIND? In validns?

Do you get this every time you sign that particular zone, or just once?

Are there other records in the zone (for which validns does not report problems)?

If you serve the zone with BIND, can a DNSSEC-supporting resolver validate the records?

\Anton.

Our society can survive even a large amount of irrational regulation. -- John McCarthy

tobez avatar Jul 29 '13 15:07 tobez

You can see in the zone file I posted that, yes, there are other types and they seem OK. I have setup a public zone you can test, auto.rd.nic.fr (the master allows zone transfers). The zone works and can be validated. I now get these results:

% validns -p all -z auto.rd.nic.fr auto.rd.nic.fr             
auto.rd.nic.fr:8: auto.rd.nic.fr. RRSIG exists for non-existing type NSEC
auto.rd.nic.fr:21: ns1.auto.rd.nic.fr. RRSIG exists for non-existing type NSEC
auto.rd.nic.fr:24: 7cc2008ib0aji6pn9m8njb59sacdfdb0.auto.rd.nic.fr. RRSIG(NSEC3): bad signature
auto.rd.nic.fr:13: auto.rd.nic.fr. RRSIG(TYPE65534): bad signature

bortzmeyer avatar Jul 30 '13 21:07 bortzmeyer

On Tue, Jul 30, 2013 at 02:13:55PM -0700, Stéphane Bortzmeyer wrote:

You can see in the zone file I posted that, yes, there are other types and they seem OK.

A question not unrelated to the actual problem, more to get a feel about how github issues work - in the mail I've got there was no link to the zone file. Did you edit the issue text at a later point?

At any rate, I think I am not handling repeated sigs correctly - as you can see for yourself, the SOA RRSIG, and the TYPE65534 RRSIG are in the zone file twice (with different values). So I guess that explains it.

Are you aware of any standards describing how to deal with such situations? There are mutliple possible interpretations, like:

  • ignore all encountered sigs in an RRSET except the first
  • ignore all encountered sigs in an RRSET except the last
  • try to check them all, and if one of them is fine, then all is fine

etc.

I have setup a public zone you can test, auto.rd.nic.fr (the master allows zone transfers). The zone works and can be validated. I now get these results:

% validns -p all -z auto.rd.nic.fr auto.rd.nic.fr             
auto.rd.nic.fr:8: auto.rd.nic.fr. RRSIG exists for non-existing type NSEC
auto.rd.nic.fr:21: ns1.auto.rd.nic.fr. RRSIG exists for non-existing type NSEC
auto.rd.nic.fr:24: 7cc2008ib0aji6pn9m8njb59sacdfdb0.auto.rd.nic.fr. RRSIG(NSEC3): bad signature
auto.rd.nic.fr:13: auto.rd.nic.fr. RRSIG(TYPE65534): bad signature

It's similar: bad signatures are because RRSIG(TYPE65534) and RRSIG(NSEC3) have duplicates with different (presumably bad) signature data, which "non-existing type" are real - there is an RRSIG for a type that is not there. This sounds like a zone bug, or at least something not-entirely-sane, no?

\Anton.

Our society can survive even a large amount of irrational regulation. -- John McCarthy

tobez avatar Jul 30 '13 21:07 tobez

On Tue, Jul 30, 2013 at 11:42:22PM +0200, Anton Berezin [email protected] wrote a message of 41 lines which said:

A question not unrelated to the actual problem, more to get a feel about how github issues work - in the mail I've got there was no link to the zone file. Did you edit the issue text at a later point?

Yes, I did.

This sounds like a zone bug, or at least something not-entirely-sane, no?

For the TYPE65534, indeed, it looks like a BIND bug. Reported to ISC as [ISC-Bugs #34439]

tobez avatar Jul 31 '13 08:07 tobez

On Wed, Jul 31, 2013 at 10:06:28AM +0200, Stéphane Bortzmeyer wrote:

On Tue, Jul 30, 2013 at 11:42:22PM +0200, Anton Berezin [email protected] wrote a message of 41 lines which said:

A question not unrelated to the actual problem, more to get a feel about how github issues work - in the mail I've got there was no link to the zone file. Did you edit the issue text at a later point?

Yes, I did.

This sounds like a zone bug, or at least something not-entirely-sane, no?

For the TYPE65534, indeed, it looks like a BIND bug. Reported to ISC as [ISC-Bugs #34439]

And for the rest (duplicated RRSIG for SOA and for NSEC3), and bogus RRSIG for non-existing record types, do you have an opinion?

\Anton.

Our society can survive even a large amount of irrational regulation. -- John McCarthy

tobez avatar Jul 31 '13 08:07 tobez

Hi Anton

And for the rest (duplicated RRSIG for SOA and for NSEC3), and bogus RRSIG for non-existing record types, do you have an opinion?

I think it is similar to the Algorithm Key Rollover issue (https://github.com/tobez/validns/issues/22). There should be a policy where I can instruct validns to stop moaning about duplicate/obsolete/irrelevant RRSIGs.

Daniel

stirnim avatar Mar 24 '16 18:03 stirnim