Subject: [DNSOP] Adopted glue - what to do with RRSIG? (bind vs ods)

From: Paul Wouters <[email-masked]>
Date: Fri, 12 Oct 2012 14:22:45 -0400 (EDT)

I ran into a corner case where opendnssec and bind showed different
behaviour.

There was a domain that expired that had glue records. These records
got signed after the NS records were removed. A few days later, the
owner restored the domain, making the glue "adopted" again.

The RRSIGs were not removed by bind (dnssec-signzone with feeding old
RRSIGS back to it for filtering). They were removed by opendnssec.

Which approach is more correct"? I am leaning towards opendnssec.

(and if there are bind/opendnssec devs here, how to I get these two
  signers to behave the same regarding this issue, to avoid hitting
  a false positive of a broken signer engine)

Paul

---

From: Edward Lewis <[email-masked]>
Date: Tue, 16 Oct 2012 07:56:00 -0400

>Which approach is more correct"? I am leaning towards opendnssec.

Using the choices above, opendnssec is correct.  Once the NS set 
returns, the address records are demoted from authoritative data to 
glue.  (Akin to occluded records arising from dynamic update adding a 
DNAME or NS set.)

The software tools performing the signing function ought to detect 
this demotion and decide to remove the signature records for what has 
become glue.

>  a false positive of a broken signer engine)

I suppose (not speaking as a developer of the tools) if you were to 
force a "batch" signing of the zone in BIND, including manually 
removing all signatures the glue records would not get signatures. 
This solution doesn't scale well though, as you might imagine.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Oct 2012 10:17:56 +1100

> this demotion and decide to remove the signature records for what has 

There is nothing wrong with the signature remaining.  Authoratitive
servers are supposed to ignore them when generating responses to
QUERIES other than AXFR/IXFR the same as they ignore all other types
other than A and AAAA.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Oct 2012 22:56:06 -0400 (EDT)

> QUERIES other than AXFR/IXFR the same as they ignore all other types

Will dnssec-signzone's behaviour be modified to ensure these RRSIGs are
removed from the zone, or is it going to leave that up to the name server?

For those of us using multiple engines, the difference is a problem,
even if the nameserver would not actually serve the records.

Paul

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 Oct 2012 09:33:39 -0400

>QUERIES other than AXFR/IXFR the same as they ignore all other types

There's the principle of "be liberal in what you accept and 
conservative in what you send", which that tack violates.  By 
including the extraneous signatures you aren't being conservative.

My expectation of a DNSSEC signer is that it would produce a properly 
signed zone.  If a signer tool included signatures for which it is 
not authorized to make, even if they were just leftovers, I'd report 
a bug because that would not meet expectations.

What happens when a validator sees a non-authorized signature on 
data?  What happens when a validator sees that on glue?  There's no 
specific defined behavior there, so I would assert that the signer 
ought to be conservative.

But - that is just an opinion of mine.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468