Subject: [DNSOP] DS without NS in a delegation?

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 27 Feb 2013 13:18:01 +0000

Hi,

We've been discussing internally whether or not including DS records into a zone without respective NS record(s) makes any sense (assuming that there are no other RRSETs for the respective label in the zone itself - pure "delegation" scenario)... My personal assumption is that it does not, since the DS record can never be used to verify the information in the (unreachable) delegated zone? 

On a related (although slightly off topic) issue, we were also assuming that EPP status values "serverHold" as well as "clientHold" do affect both NS as well as DS records.

Comments appreciated.

thanks,
Alex Mayrhofer

---

From: Roy Arends <[email-masked]>
Date: Wed, 27 Feb 2013 13:50:29 +0000

> We've been discussing internally whether or not including DS records into a zone without respective NS record(s) makes any sense (assuming that there are no other RRSETs for the respective label in…

When a parent and child zone are served from the same server set, like co.uk and uk, you could have _in_theory_ DS records without NS records in the parent zone. A resolver would never observe the delegation point NS record. A validating resolver would need to explicitly ask for the DS record. If the DS record is present, the DS plus signatures will be returned. However, absence of the DS record is problematic, as there is no NSEC(3) record indicating presence of NS, absence of SOA+DS. 

I think you'd need to implement these specifics though, as current authoritative servers and signers might throw an error when observing a DS without NS, but I haven't checked.

I wouldn't recommend it though, it might introduce corner cases. See RFC6840, section 4.1 as an example of what such a corner case might look like.

Hope this helps,

Roy Arends
Nominet Research Fellow

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 27 Feb 2013 17:59:27 +0100

> We've been discussing internally whether or not including DS records into a zone without respective NS record(s) makes any sense (assuming that there are no other RRSETs for the respective label in…

It sort of does not make any sense, but I would be nervous if you set a policy that force the NS to exist before you publish DS. This because adding NS and adding DS are two different epp operations, and you would set a constraint on in what order such things could happen. And for example that removing NS would not be allowed if not DS is removed first (or DS implicitly be removed if NS is removed). That in turn would create race conditions in the case NS is changed completely because even for a fraction of a section a domain name that is registered might exist in the registry without any NS records, but with DS.

So, I this "makes no real sense" be one of acceptable things that domain name holders should be allowed to do if they want. And/or the registrar of course that have their internal algorithms regarding in what order various epp commands are made.

   paf

---

From: Edward Lewis <[email-masked]>
Date: Thu, 28 Feb 2013 09:27:18 +0800

I don't know if there's a smoking gun "MUST NOT" but we did discuss a NS-less DS.  Unreliably I'd say it would be a protocol-level error to have.

But I did find this, which in as much as an RFC is ever a spec, infers that NS-less DS's aren't to be seen.  From RFC 4035:
3.1.4.1.  Responding to Queries for DS RRs

   The DS resource record type is unusual in that it appears only on the
   parent zone's side of a zone cut.

On Feb 28, 2013, at 0:59, Patrik Fältström wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 28 Feb 2013 07:16:53 +0100

Ok, let me phrase my statement differently then.

IF people do not want DS in the parent zone of a zone cut, then the registry should not publish the DS they have for domain names they do not have NS.

My only point was to not use this as an argument to make the epp transactions even more complicated and "stateful".

   Patrik

---

From: Edward Lewis <[email-masked]>
Date: Thu, 28 Feb 2013 15:03:35 +0800

> When a parent and child zone are served from the same server set, like co.uk and uk, you could have _in_theory_ DS records without NS records in the parent zone. A resolver would never observe the…

Roy, that idea bothers me.

It's true, if all of the name servers for the parent are all of the name servers for a child, the NS set is not necessary.  But claiming then you could have DS records means the same name would have to own DNSKEY records (for the DS to reference) and then an SOA to allow the owner to appear in the RRSIG's signer name field.  Sure you don't need the NS, but you need everything else that makes a zone cut.  But wait, there's more.  The NSEC/NSEC3 record really ought to indicate that there's a delegation there and for that the NS bit has to be turned on - so there's a need for an NS.

> I think you'd need to implement these specifics though, as current authoritative servers and signers might throw an error when observing a DS without NS, but I haven't checked.

Without specifically saying what error would be thrown (and when, on zone load?), current servers should have issues with a name owning a DS and no NS.

---

From: Roy Arends <[email-masked]>
Date: Thu, 28 Feb 2013 09:44:13 +0000

On Feb 28, 2013, at 7:03 AM, Edward Lewis <[email-masked]> wrote:

> It's true, if all of the name servers for the parent are all of the name servers for a child, the NS set is not necessary.  But claiming then you could have DS records means the same name would have to own DNSKEY records (for the DS to reference) and then an SOA to allow the owner to appear in the RRSIG's signer name field.

The DS record, in the parent zone, refers to the DNSKEY in the child zone. The RRSIG over the DS record contains a signer name of the DNSKEY of the parent. Both SOA's at child and parent do exist.

>  Sure you don't need the NS, but you need everything else that makes a zone cut.  But wait, there's more.  The NSEC/NSEC3 record really ought to indicate that there's a delegation there and for that the NS bit has to be turned on - so there's a need for an NS.

When parent and child are served from the same set, what does a resolver need to ask in order to see the parent side NSEC/NSEC3 record that proves presence or absence of the NS. IMHO, it won't be able to form a request so that the authoritative server would return the NSEC[3] that shows that there really was a zone cut (that is, served from the parent zone).

> Without specifically saying what error would be thrown (and when, on zone load?), current servers should have issues with a name owning a DS and no NS.

I think we're in complete agreement. Mixing a gun, a bullet and a foot in an unintended way will have unintended consequences, many of them not really desirable :-)

Roy