Subject: [dnsext] SOA without NS

From: Casey Deccio <[email-masked]>
Date: Thu, 4 Oct 2012 13:41:43 -0700

What is the proper way to handle resolution of names within a "zone" in
which an SOA exists but there are no NS records (neither in the delegating
parent nor in the child itself)?  Is it really a zone since there is no
delegation via NS records?  More specifically, where is the zone cut, as it
pertains to DNSSEC?  If the undelegated zone is signed with DNSKEY RRs
co-existing with the SOA, do/should resolvers treat names in that namespace
like: 1) names that have no legitimate RRSIGs (they point to the DNSKEYs
whose name is not at the zone apex) and are therefore "bogus"; 2) signed
names in a "zone" without any DS records and therefore "insecure"; or
something else?  As far as I can tell with a little experimentation, BIND
and unbound both treat it as insecure.  DNSViz is a little more harsh, but
only because I hadn't considered the case (and the DNSKEYs aren't being
retrieved... yet).  But I'd like to throw a warning or error as
appropriate.  One example of this is buero.former03.de.

Cheers,
Casey

---

From: Jim Reid <[email-masked]>
Date: Thu, 4 Oct 2012 22:32:33 +0100

On 4 Oct 2012, at 21:41, Casey Deccio wrote:

> parent nor in the child itself)?

Remedial lessons in DNS school for the admin and whoever implemented a  
broken name server that allowed such brokenness. :-)

A zone cannot exist unless it has a SOA record and at least one NS  
record.

A zone has exactly one SOA record.

BIND9's named-checkzone will show what errors are reported when you  
try to load a zone file that breaks these fundamental rules. Other DNS  
software is available and may (or may not) be more forgiving about  
this level of brokenness.

When a zone has no NS records, it can't be resolved. [Well, not unless  
there's zone-specific forwarding in place in some name server's  
configuration.] Lookups for names in such a zone will return NXDOMAIN  
since the zone does not exist. SERVFAILs might be returned if there is  
a delegation for such a zone in the parent and no NS record(s) in the  
child. A broken DNS implementation might answer authoritively and  
return "normal" answers when one of its zones has no NS records. It  
depends.

> More specifically, where is the zone cut, as it pertains to DNSSEC?

DNSSEC has no impact on the location of a zone cut. The zone cut is  
found in the parent at the place where it has NS records for the  
child, just as it's always been. Those NS records (and any related  
glue) are beneath the zone cut. Everything else is above it. The child  
should have a SOA record, signifying the start of a new zone of  
authority, and an NS RRset that's identical to (best case) or has at  
least one record in common with (worst case) those at the zone cut in  
the parent.

> One example of this is buero.former03.de

This "domain" is badly broken. Fixing it is a topic for another list.

---

From: Casey Deccio <[email-masked]>
Date: Thu, 4 Oct 2012 14:48:48 -0700

Hi Jim,

On Thu, Oct 4, 2012 at 2:32 PM, Jim Reid <[email-masked]> wrote:

> DNSSEC has no impact on the location of a zone cut. The zone cut is found
> in the parent at the place where it has NS records for the child, just as
> it's always been.

What I'm referring to is proper validation of RRSIGs by the resolver, as
documented in RFC 4035 5.3.1:

"The RRSIG RR's Signer's Name field MUST be the name of the zone
that contains the RRset."

Unless this is loosely interpreted to mean that the signer's name field
must be a superdomain of the owner name, then there must be some
determination made by the resolver as to whether the signer is the name of
the zone or not.

Those NS records (and any related glue) are beneath the zone cut.
> Everything else is above it. The child should have a SOA record, signifying
> the start of a new zone of authority, and an NS RRset that's identical to
> (best case) or has at least one record in common with (worst case) those at
> the zone cut in the parent.
>
>
I would suggest that more important than names is the addresses they point
to (i.e., the resulting SLIST from glue and/or resolved addresses), rather
than the names themselves.  Additionally, I would think that in the worst
case there is *no* intersection between SLISTs generated from names in the
parent and those in the child.

> This "domain" is badly broken. Fixing it is a topic for another list.

Agreed--merely an example that brought the issue to my attention.

Casey

---

From: Mark Andrews <[email-masked]>
Date: Fri, 05 Oct 2012 08:22:08 +1000

The parent zone is signed using NSEC3 + OPTOUT.  The "delegation"
fails into a optout range.  At this point it is irrelevent if the
child zone is properly delegated, signed etc.

Even if the parent zone used NSEC records as long as there is a DS
record it would still validate for almost all queries.  You have
signature from a DNSKEY which has a DS which is signed by the parent
zone.  As the two zones are on the same server the resolver will
never need to do a NS query.

In message <[email-masked]>
> that contains the RRset."

It is.
 
> determination made by the resolver as to whether the signer is the name of

You take the signer, look for a DNSKEY, look for a DS, look for the
DNSKEY of its signer ....  A DS's signer MUST NOT match the owner
of the DS.  You follow the zone cuts using DS + DNSKEY rather than
NS.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Casey Deccio <[email-masked]>
Date: Thu, 4 Oct 2012 15:45:17 -0700

On Thu, Oct 4, 2012 at 3:22 PM, Mark Andrews <[email-masked]> wrote:

> record it would still validate for almost all queries.

Perhaps in theory, although both my BIND and unbound resolvers return
responses without the AD bit set:

$ dig +dnssec @localhost mail.buero.former03.de | grep flags
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 5
; EDNS: version: 0, flags: do; udp: 4096

$ dig +dnssec @localhost mail.buero.former03.de | grep flags
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags: do; udp: 4096

> of the DS.  You follow the zone cuts using DS + DNSKEY rather than
If this is the case for complete chains of trust, then perhaps it should
this be clarified further in dnssec-bis.

However, for insecure delegations this violates dnssec-bis 4.4:

   "The validator also
   MUST check for the presence of the NS bit in the matching NSEC (or
   NSEC3) RR (proving that there is, indeed, a delegation), or
   alternately make sure that the delegation is covered by an NSEC3 RR
   with the Opt-Out flag set.

   Without this check, an attacker could reuse an NSEC or NSEC3 RR
   matching a non-delegation name to spoof an unsigned delegation at
   that name.  This would claim that an existing signed RRset (or set of
   signed RRsets) is below an unsigned delegation, thus not signed and
   vulnerable to further attack."

Of course the above example also lacks DS records, but because it's covered
in the opt-out range there's not check for the NS bit.

Casey

---

From: Jim Reid <[email-masked]>
Date: Thu, 4 Oct 2012 23:47:41 +0100

> determination made by the resolver as to whether the signer is the  

Not really. The signer has to be the name of the enclosing zone so  
there's nothing for the validating resolver to determine about whether  
that constitutes a zone cut or not. The name of the signer must be the  
name of the zone. QED. DNSSEC validation doesn't care about zone cut  
semantics at all. Provided of course the relevant DNSSEC RRs are in  
their proper places at the zone cut. The text you quoted does not  
mention zone cuts, so I don't know why you mentioned them or thought  
they mattered to DNSSEC. Zone cuts are still where they've always  
been. DNSSEC just complicates their semantics.

What RFC4035 is saying is there are key(s) which sign the zone as a  
whole and there can be no discrete keys which sign individual RRsets.  
ie in the foo.com zone, there can't be a key bar.foo.com which only  
signs foobar.foo.com or some RRset of bar.foo.com or foo.com. In other  
words, the signer's name field of an RRSIG could be a superdomain of  
the owner-name (as you say) but it is always the name of the closest  
enclosing zone.

DNSSEC validation works by finding the DS record(s) for the DNSKEY(s)  
identified by and RRSIG's Signer's Name field(s). You then find the  
DNSKEY(s) for the RRSIG(s) which signed those DS record(s) in the  
parent zone and validate those signatures. This process iterates up  
the name space until the validator hits a trust anchor or something  
breaks. It's a wee bit more complex than this -- ZSKs and KSKs -- but  
that detail is not germane to this discussion, so please let's not  
rake over those nits.

> than the names themselves.

Of course, but you're just picking nits that are somewhat off-topic.  
It would have been more precise of me to repeatedly mention NS records  
and accompanying A and AAAA records. However I had hoped that it  
wasn't necessary to explicitly spell out things that should be self- 
evident to the membership of this list.

> Additionally, I would think that in the worst case there is *no*  
> intersection between SLISTs generated from names in the parent and  
> those in the child.

We had already discussed and eliminated that irredeemably broken  
possibility. But if you want to pick that nit too, be my guest.

---

From: Casey Deccio <[email-masked]>
Date: Thu, 4 Oct 2012 17:13:03 -0700

On Thu, Oct 4, 2012 at 3:47 PM, Jim Reid <[email-masked]> wrote:

> Not really. The signer has to be the name of the enclosing zone so there's
> nothing for the validating resolver to determine about whether that
> constitutes a zone cut or not. The name of the signer must be the name of
> the zone. QED. DNSSEC validation doesn't care about zone cut semantics at
> all. Provided of course the relevant DNSSEC RRs are in their proper places
> at the zone cut. The text you quoted does not mention zone cuts, so I don't
> know why you mentioned them or thought they mattered to DNSSEC. Zone cuts
> are still where they've always been. DNSSEC just complicates their
> semantics.
>

It appears to me from dnssec-bis section 4.4 that zone cuts are indeed
relevant to validators, particularly when using NSEC and NSEC3 for
determining insecure delegations.  Anyway, the problem with the domain I
was troubleshooting was obvious (lack of NS RRs), but my objective in
bringing this up to this group was to ensure that I was understanding the
consequences accurately, so I can effectively describe both the problem and
consequences to administrators troubleshooting DNS(SEC) configurations.
 And if additional clarification to specification is needed, then it can be
added appropriately.

Casey

---

From: Mark Andrews <[email-masked]>
Date: Fri, 05 Oct 2012 10:33:03 +1000

In message <CAEKtLiS8pBeW==x=ztngFvD0y8d+v=[email-masked]>
> responses without the AD bit set:

	Which is because the zones are not set up as described
	in the hypothetical situation introduced with "Even if".

> in the opt-out range there's not check for the NS bit.

Remember the point of DNSSEC it to prevent spoofed answers being
accepted not to ensure that every DNS zone is properly constructed.
If you don't properly construct the zones involved then you may or
may not have failures.  Additionally the validator needs to work
with zones that are in the process of being changed through caches
which may have RRsets that were cached at different points in time.

If the parent presents a signed DS that validates then a validator
can legitimately deduce that there is a zone cut at that name without
seeing the NS RRset.

Mark

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 05 Oct 2012 13:41:27 +0200

Hi Casey,

On 10/05/2012 02:33 AM, Mark Andrews wrote:
> 
> In message
> <CAEKtLiS8pBeW==x=ztngFvD0y8d+v=[email-masked]>
>
> 
, Casey Deccio writes:
>>> Even if the parent zone used NSEC records as long as there is a
>>> DS record it would still validate for almost all queries.
>> 
>> 
>> Perhaps in theory, although both my BIND and unbound resolvers
>> return responses without the AD bit set:
> 
> Which is because the zones are not set up as described in the
> hypothetical situation introduced with "Even if".

So, what unbound thinks as it validates this, is that this data falls
inside the optout span of an NSEC3 (which is valid) above it.  And no
zone cut was observed, thus, these zones are co-hosted on the same
server, it is in insecure-space.  It does not 'check' the zone-cut for
misconfiguration, because it was already insecure.  Realistically, the
data does not conform to the RFC text that you quote; it is misconfigured.

It could also be bogus, if the parent did not use optout (or NSEC) and
also did not make a zone-cut (the misconfiguration), then the
validator sees the data, but cannot get an optout span NSEC3 above it.
 Instead finds out 'the zone cut does not exist', and data from the
child zone is bogus.

To make it work, the operator needs to insert NS records for the
lower-zone into the parent-zonefile (and child DS record if it
exists).  This (after signing) creates the proper NSEC/NSEC3s.  For
buero.former03 this means inserting DS records for buero.former03 into
the former03 zone (and NS records).

Best regards,
   Wouter

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 5 Oct 2012 09:22:07 -0700

On Fri, Oct 5, 2012 at 4:41 AM, W.C.A. Wijngaards <[email-masked]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Casey,
>
> NS bit check does come into play if there is a matching NSEC or NSEC3
record in the parent zone. That's how you know it is a insecure delegation
in the case of an exact match. I agree that in the case of NSEC3 opt-out,
misconfiguration is ignored.

-mohan

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJQbsdnAAoJEJ9vHC1+BF+Ni2gQAIMY6k4tUlv0IwGE6syun/Xf
> 72H5QIJw5OBA1rMZKdY/+VjVBwLiH9RSf5StNFQeHdYymDqvgKXKews6KBBRVd3c
> Mq+OJ16anDjcxWN2yoAXIIOy8XtItoDv2YOyVwPo6nc+xs0H9faedWKUdLxDPsz8
> NlQ5YsGgBGaMRQJEAKEoJGL1crBx0Epk0z6fW5W7WVMkZUNEH3V+CpJ6WoiziKAt
> 6qG7XjJlnZQ5uRTNSh05f/0HKjX3xyLtka02yRZrNxXz+zFxJ2+ddlEmT0crRuRR
> II1K/jLU0jXOJOTvAdVEeYZXQGavtr3GU9h3EOMqnEyyPHQIdL8Z+5rkW/WyMSiO
> bryWXANnxDKdMqzs9Dp0wv0i0RBpQ+xbYn0l9nqexQLBlduM4P49QehH2VEjgawR
> 0vA3EPnNNuMOP8TrsZM2dFeqHoeihE1/ztpAjDUoBsomRAKw1zslGQbyFvUpchva
> jv8m8Q41izXgW9l0SCQrlAzNV4RcjAg0dCSvZuRyoBFo4ZKavyph01K/3SP2cKXv
> QHH0V/ogcXRzVv89NacfACFMJ3q5lp8nRVLr2aez59sbqD3HN4OAxD1x8+bsu2Mf
> qFSw8tSSDzi3lpby1GPHvQS7N69q7J2ckDjAx0zEnD2KKUt7RFkxfFuLDSBnvLx2
> Y6JTjx6l6UkDFLyq6faZ
> =w4Y3
> -----END PGP SIGNATURE-----
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>