Subject: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00

From: Paul Wouters <[email-masked]>
Date: Tue, 10 Jul 2012 14:50:06 -0400 (EDT)

Hi,

At Quebec City I volunteered for a use cases document for automating
parent-child DNS updates. I've submitted a draft for it, and hope to
get feedback before and in Vancouver...

Paul

https://datatracker.ietf.org/doc/draft-wouters-dnsop-secure-update-use-cases/

DNSOP                                                         P. Wouters
Internet-Draft                                                   Red Hat
Intended status: Informational                              July 9, 2012
Expires: January 10, 2013

                 Secure parent-child DNS update use cases
            draft-wouters-dnsop-secure-update-use-cases-00.txt

Abstract

    DNS zone administrators occasionally need to update data published by
    a parent zone, such as NS and DS records.  Traditionally these
    updates have happened out-of-band: through DNS registrar interfaces,
    EPP, websites, or manually by operators.  Some updates could also be
    done using DNS Dynamic Update [RFC2136].

    The IETF's DNSOP working group is considering proposing additional
    mechanisms for such updates, possibly leveraging DNSSEC for
    authentication.

    This document presents some use cases to drive this design work.

---

From: Chris Thompson <[email-masked]>
Date: 11 Jul 2012 16:09:02 +0100

>https://datatracker.ietf.org/doc/draft-wouters-dnsop-secure-update-use-cases/

| 3.2.  The NS RRset
|
|    Both the child and the parent have a copy of the NS RRset.  These
|    RRsets are supposed to be identical.  If they differ, it is referred
|    as a "Lame Delegation".

I have always thought that a "Lame Delegation" was something more specific:
an NS record in the delegation that points to a server that is not in fact
authoritative for the zone at all. Is the above actually common usage?

[That's not to say that any differences between the two NS RRsets is ever
desirable, except as may be necessary or expedient during a change.]

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Jim Reid <[email-masked]>
Date: Wed, 11 Jul 2012 16:37:30 +0100

> authoritative for the zone at all. Is the above actually common usage?

There's no formal definition of the term AFAICT. So it can mean  
whatever anyone wants it to mean.

RFC4697 seems to be the closest thing to a (somewhat indirect)  
definition but is only a BCP and RFC1912 is just Informational. That  
said, "lame delegation" is commonly understood to be a delegation to a  
server which should be authoritative but isn't. This may or may not be  
the same thing as a parent and child disagreement about some zone's NS  
RRset.

So it may be better if the draft uses a different term for the  
scenario where the parent and child do not have the same NS RRset.  
Perhaps that can be called a Broken Delegation? Because that's what it  
is....

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Jul 2012 12:03:54 -0400 (EDT)

On Wed, 11 Jul 2012, Jim Reid wrote:

> So it may be better if the draft uses a different term for the scenario where 
> the parent and child do not have the same NS RRset. Perhaps that can be 
> called a Broken Delegation? Because that's what it is....

I've changed it from lame delegation to broken delegation.

Thanks,

Paul

---

From: Andreas Gustafsson <[email-masked]>
Date: Wed, 11 Jul 2012 21:16:21 +0300

> I've changed it from lame delegation to broken delegation.

I suggest simply dropping the sentence 'If they differ, it is
referred as a "Lame Delegation"' instead.  I don't think Jim's
suggestion of "broken delegation" is common usage for the
particular situation of "parent and child NS RRsets differ"
any more than "lame delegation" is, and as far as I know,
there is no established shorthand term that refers
specifically to this situation.
-- 
Andreas Gustafsson, [email-masked]

---

From: "Blacka, David" <[email-masked]>
Date: Thu, 12 Jul 2012 14:26:17 +0000

> specifically to this situation.

"broken delegation" suggests to me (at least) that the delegation cannot be successfully followed.  That is possible, of course, but most of the time when the parent and child disagree, the delegation works but is not optimal.  If we want a term for this (very common) case, I suggest "mismatched delegation".

--
David Blacka                          <[email-masked]> 
Principal               Verisign Infrastructure Engineering

---

From: Joe Abley <[email-masked]>
Date: Thu, 12 Jul 2012 16:07:36 -0400

> desirable, except as may be necessary or expedient during a change.]

That's a good rule of thumb, but so long as the union of the delegation and apex NS sets contains no lame delegations, everything will still work as far as the client is concerned.

I have seen someone use a deliberately different apex and delegation NS set (with all servers authoritative) in order to try and identify differences in the traffic pattern (e.g. to see whether there are clients who reliably cache and re-use the delegation NS set in spite of the apex NS set).

When submitting NS set changes to the root zone it is required to update the apex NS set before submitting the change request, and until the change request is completed the delegation set will be definitively different. Other registries that perform configuration checks on child zones might behave differently. I realise this was encapsulated in your use of "necessary" but I thought perhaps it was worth spelling out.

Joe

---

From: Peter Koch <[email-masked]>
Date: Fri, 13 Jul 2012 13:57:51 +0200

> referred as a "Lame Delegation"' instead.  I don't think Jim's

while this discussion is refreshing, the reason Paul (was) volunteered
to write this document was less the (re-)definition of the lame delegation
terminology but more to address (potential) requirements for an in-band
child parent key exchange. Let's leave the bikeshed black for the moment
and focus on the design of the bikes instead.

-Peter

---

From: Doug Barton <[email-masked]>
Date: Sat, 14 Jul 2012 13:50:27 -0700

On 07/11/2012 11:16, Andreas Gustafsson wrote:
> referred as a "Lame Delegation"' instead. 

I agree with Chris that "Lame" has the common meaning that a server in
the NS set is not authoritative for the zone.

I would argue further that a child NS set which is a superset of the
parent is not lame, or broken. There are valid reasons to do this,
(outside the scope of this document, certainly) and I'd hate to see this
instantiated as "an RFC violation" as a side effect.

> I don't think Jim's

Agreed.

I would express 3.2 like this:

Both the child and the parent have a copy of the NS RRset. The child's
zone should contain each of the NS records listed in the parent, and
each of the servers in the NS RRset should be authoritative for the
zone. Modifying the NS RRset ...

-- 
    If you're never wrong, you're not trying hard enough

---

From: Joe Abley <[email-masked]>
Date: Sat, 14 Jul 2012 17:05:02 -0400

> instantiated as "an RFC violation" as a side effect.

Or a subset, or a completely different set. The relative sizes of the NS sets and the size of the intersection is not really relevant; the important thing for resolution is whether the union of both sets contains lame servers.

Any new work which needed to assert that both sets were the same would meet with little objection though, I think. It's commonly-shared wisdom that both sets should be the same, and "are consistent and remain so" (RFC 1034 section 4.2.2) is fairly clear.

Joe

---

From: Doug Barton <[email-masked]>
Date: Sat, 14 Jul 2012 14:35:19 -0700

On 07/14/2012 14:05, Joe Abley wrote:
>> I would argue further that a child NS set which is a superset of
>> the parent is not lame, or broken. There are valid reasons to do
>> this, (outside the scope of this document, certainly) and I'd hate
>> to see this instantiated as "an RFC violation" as a side effect.
> 
> Or a subset, or a completely different set.

The subset you can usually get away with, (assuming, as you have, that
the omitted server actually answers authoritatively for the zone) but in
practice that's a meaningless exercise because so many resolver
implementations will continue to query the server if it answers
authoritatively.

The "completely different set" case is a whole different can of worms,
and is likely to cause damage. (Both of these observations are based on
my experience.)

> The relative sizes of the
> NS sets and the size of the intersection is not really relevant; the
> important thing for resolution is whether the union of both sets
> contains lame servers.

My experience tells me differently regarding the 2 cases you mention
above. However, you'll note that the text I proposed does take what you
wrote into account when the child set is identical or greater than the
parent set.

> Any new work which needed to assert that both sets were the same
> would meet with little objection though, I think.

It's already met with at least 2 objections, so I'm pretty sure you're
wrong. :)

> It's
> commonly-shared wisdom that both sets should be the same, and "are
> consistent and remain so" (RFC 1034 section 4.2.2) is fairly clear.

Sure, that's the ideal, and I always advise people to "make it so."
However 25 years after 1034 was written we know quite a bit more about
how DNS works in the real world, and the case of the child zone having a
superset of NS records is a real, valid configuration.

Doug

---

From: Joe Abley <[email-masked]>
Date: Sat, 14 Jul 2012 17:54:29 -0400

> It's already met with at least 2 objections, so I'm pretty sure you're

Well, my note wasn't an objection and yours just made assertions with no explanation, so I didn't count them.

Joe

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 16 Jul 2012 09:40:41 +0200

> and focus on the design of the bikes instead.

Because I find the registrar/registry description be non-complete, and in some cases wrong, let me suggest that portion of the draft is just removed, and instead that the draft actually talk about what it is supposed to talk about.

For example:

- I recommend strongly to not talk about sub-registrars
- I recommend as strongly to not talk about registrant/registry relationship
- The protocol to use to communicate with registrar is normally private API, not epp
- It varies what and how the registrars are to send data to the registry, even if epp is in use, so just skip trying to describe it as registries have too much difference in policy and ideas on how that is to be done

Etc...

   Patrik

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Jul 2012 07:10:00 -0700

> - It varies what and how the registrars are to send data to the registry, even if epp is in use, so just skip trying to describe it as registries have too much difference in policy and ideas on how…

Patrik's partial list of problems with the document can be summarized as:

What is the intention of this document: is it describing current operations, or operations that we want to see?

If it is the former then, yes, there is a lot of completely incorrect statements. If it is the latter, it will be interesting to imagine how we can get consensus because current operators won't want to change to this new design or to run two or more different operations in parallel.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 16 Jul 2012 10:25:45 -0400 (EDT)

On Mon, 16 Jul 2012, Paul Hoffman wrote:

> Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00
> 

The goal was to describe use cases, not requirements. We can change that
if we want, but then we will have the use-cases discussion anyway on the
list. If the WG wants that, it's fine with me.

>> - I recommend strongly to not talk about sub-registrars

It's a very important use case unfortunately, with the second largest
reseller not supporting DNSSEC, while powering dozens of smaller
sub-registrars.

>> - I recommend as strongly to not talk about registrant/registry relationship

How else would you describe the relationships where parent and child do
not communicate with each other directly, but use a third party?

>> - The protocol to use to communicate with registrar is normally private API, not epp

Unless in the case of the sub-registrar.

>> - It varies what and how the registrars are to send data to the registry, even if epp is in use, so just skip trying to describe it as registries have too much difference in policy and ideas on ho…

Can these be folded into use cases?

> What is the intention of this document: is it describing current operations, or operations that we want to see?

It is trying to describe the use-cases that any solution that tries to
automate parent-child related records with DNSSEC-based authentication
should attempt to support.

> If it is the former then, yes, there is a lot of completely incorrect statements. If it is the latter, it will be interesting to imagine how we can get consensus because current operators won't wan…

I think this statement confuses "operator" with "registrar". There are
many other use cases too. It would be unfortunate if we leave the entire
RRR ecosystem out of any possible solution, because part of the
motivation for this document is to speed up adoption of DNSSEC in the
many different RRR eco-systems.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Jul 2012 07:53:28 -0700

> list. If the WG wants that, it's fine with me.

The use cases in section 3 are fine because they are use cases for standardized things. Patrik's objections were (all?) about the "use cases" in section 4, which in fact are business models, some of which exist today and others which do not.

I disagree that this WG needs to have a discussion of the latter as long your use case document describes the three parties: "zone operator", "registry", and "organization that might have a business relationship between those two". Any discussion about the business model of the third party and the first or second doesn't feel like a use case to me at all.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Mon, 16 Jul 2012 11:48:31 -0400

> I disagree that this WG needs to have a discussion of the latter as long your use case document describes the three parties: "zone operator", "registry", and "organization that might have a busines…

I agree.

There are technical/protocol aspects involved in this idea which need to be documented and standardised. There are also changes required to the business ecosystem of the various types of actor involved in the maintenance of records in DNS registries.

This working group's role is surely to concentrate on the former. There are other bodies whose mandate might allow them to address the latter.

Joe

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 16 Jul 2012 21:50:04 +0200

> reseller not supporting DNSSEC, while powering dozens of smaller

The problem is that there are large disagreements in the TLD business whether something like subregistrar really should be (let me use computer terminology here) a first order object or not. Specifically because there are disagreements whether special restrictions should be put on resellers, or if "only" the requirements on registrars should be automatically transferred to the reseller. Plus of course whether resellers are allowed at all -- and that dives into the issues where there are discussions on how you define whether two organisations have "too close relationship", i.e. "are the same organisation". And people against the term reseller very strongly is against it because any such text might risk removing responsibilities on the registrar, and because of that the ability for registries to blame resellers (because resellers live under not only agreement with the registrar, but also separate agreement with the registry or some accreditation agency).

Etc.

This is a can of worms.

> not communicate with each other directly, but use a third party?

If you do, then you must describe the relationship given the different kind of agreements that exists. In most cases there are agreements between the registry and the registrant that the registrant must live up to. But how that is implemented, when the registrant is agreeing to the rules, and how the registry is to ensure the registrant is living up to the rules is very very different between different registries. In some cases the rules are technical, in others not. In some you also have a relationship between the DNS hosting provider and the registry.

> Unless in the case of the sub-registrar.

My experience is that majority of communication with the registrar is not epp. Regardless of whether we talk about registrants, sub-registrars or dns hosting providers that communicate with the registrar.

> Can these be folded into use cases?

If you write lots of lots of text that describe the different cases. :-P

And remember that registries do change their policies and rules every third to fourth year, that changes things.

> should attempt to support.

I still think you should just concentrate on discussing what you actually want to do. If we concentrate on that part I am happy to help commenting on how those ideas fit (or not) into the world I see (as a registrar mainly in the ccTLD world).

For example, do you think DS is to be passed to the registry or DNSKEY?

Even *that* discussion have stalled in the epp discussions because registries want to (for possibly correct reasons) have a freedom to build their own business models. 

But if you manage to write only that "simple" thing in a document that we can give registries and registrars, getting that implemented will not be easy.

   Patrik

---

From: Paul Wouters <[email-masked]>
Date: Mon, 16 Jul 2012 16:07:52 -0400 (EDT)

> This is a can of worms.

I understand, though this document is trying to be a technical one, not
a legal one. If the examples in the RRR model can be made more generic
or "fixed", I think that would help us determine what has a use and what
has no use, getting implemented.

> My experience is that majority of communication with the registrar is not epp. Regardless of whether we talk about registrants, sub-registrars or dns hosting providers that communicate with the reg…

One of the possible outcomes of this document would be a way where the
DNS hoster and the registry can talk via a DNSSEC-authenticated method.
I imagine that could be useful to registrants, DNS hosters, registrars
and registries. But also within the non-RRR model of parent-child
relationship. The private/different API/EPP implementations is not
helping making DNSSEC deployment easy. That's what we're trying to
address.

> And remember that registries do change their policies and rules every third to fourth year, that changes things.

If we have technology in place that can accomodate most, then over time,
hopefully that will change. Just like going from a non-EPP to an EPP
solution has slowly but surely gained more traction, and eased
deployment for registrars.

> For example, do you think DS is to be passed to the registry or DNSKEY?

That is something that would come up when discussing the use cases
document. If we know all the answers to these questions, we would not
need a use cases document.

What I think (though the idea is that this becomes a WG document and I'm
just the editor) is that a likely solution would be for the child to
store something in its zone, that the parent can read and validate. It
seems reasonable to suggest people would want to be able to pre-publish
DS records without yet revealing the public DNSKEY, so in my personal
(no hats) opininion, I would say that the DS option should be there. I
also think the DNSKEY option should be there to accomodate those parents
that have to generate the DS themselves for whatever (technical or not)
reason.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Jul 2012 13:19:34 -0700

On Jul 16, 2012, at 1:07 PM, Paul Wouters wrote:

> a legal one.

It would be better if it was really a "use cases" one.

> If the examples in the RRR model can be made more generic

Fully disagree. Trying to say which of the use cases for the R between the zone operator and the registry "has use" and "has no use" belongs in ICANN, not the IETF. It is not an operations issue.

> DNS hoster and the registry can talk via a DNSSEC-authenticated method.

Err, how could that be the outcome of a use cases document? Or are you envisioning this as also being a protocol document? (FWIW, I would love to have such a protocol, but I think it's a bad idea to do it as a "use case".)

> helping making DNSSEC deployment easy. That's what we're trying to

So this is now a list of current practices that are not working?

> deployment for registrars.

That's a business argument.

> that have to generate the DS themselves for whatever (technical or not)

That all seems fine. What does it have to do with describing the practices today?

--Paul Hoffman

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 16 Jul 2012 22:30:47 +0200

> has no use, getting implemented.

Fair. A good goal. I hope you can manage to describe something. Because I agree it would be useful. I am just myself a bit tired over all the different "technical" explanations I have heard from registries and registrars lately... :-P

> DNS hoster and the registry can talk via a DNSSEC-authenticated method.

Please stay away from that discussion (i.e. whether the registry should have direct communication with the dns provider). That is *directly* impacting the business models of among other things registrars. And the discussion will be everything BUT technical.

So, if you want a technical discussion, have one.

But, as you say yourself, you MUST stay away from business models and legal stuff.

> and registries.

Depends on what "that" is of course :-)

> But also within the non-RRR model of parent-child
> helping making DNSSEC deployment easy.

The private API is absolutely helping as epp is not suitable for the transactions you want.

How many epp implementations have you written, or rather, how many state machines for epp have you worked on for what number of TLDs that implement what you want to do?

The transactions are dead simple if you have for example a JSON based "thing", but a pain in the back if you try to do it in epp. Specifically in cases where one or more of the registrant, dns hosting provider and registrar changes while you still want to have the domain operational.

> That's what we're trying to address.

Understood.

> deployment for registrars.

Well, one can question how easy it has become.

Yes, it is easier for registrars to either be bound to one non-gTLD or as an accredited ICANN registrar address most gTLD registries. But to support more than one of these (more than one non-gTLD or a non-gTLD and gTLDs), it is a royal pain. We can discuss over a beer whether it is easier than what it would have been without epp.

And, note, I *was* the responsible Area Director when epp was created!

So I am blaming no one else than myself for rather wanting a solution people could agree on than something that lead to interoperability. Today, I claim people over-use the 'e' in epp.

ANYTHING that can reverse that I am thankful to.

And that is why I say "please just start agreeing on whether you want DS or DNSKEY" passed to the registrar. That would clean up so many things that you can not imagine.

> need a use cases document.

Well, I think the problem is that people know the *possible* answers, but they can not agree on what to pick.

> store something in its zone, that the parent can read and validate.

This might very well create a race condition between the DNS provisioning path and the epp path.

But this is exactly what we could have a look at. And "ignore" (note the quotes) the background information where I think most issues are tied to the business models.

> It

Personally, I think many issues I bring up is because different registries have a mix of:

- Extremely restrictive implementations of DNSSEC in their epp
- Extreme interest in policing what is done in child zones

If registries just had (as I see between the lines you suggest) a combination, or multitude, of approaches, then a few different things would be resolved:

1. There would be easier for registrars to find _one_ mechanism or algorithm or state machine that works on more than one TLD

2. There would be easier to implement a multitude of use cases with the same registry

   Patrik

---

From: Paul Wouters <[email-masked]>
Date: Mon, 16 Jul 2012 16:37:00 -0400 (EDT)

> It would be better if it was really a "use cases" one.

What I meant was, we are looking at use cases without looking at legal
limitations. If some use cases will not be legally suitable for some TLD
or non-TLD cases, that is not a reason to remove the use case from this
document.

> Fully disagree. Trying to say which of the use cases for the R between the zone operator and the registry "has use" and "has no use" belongs in ICANN, not the IETF. It is not an operations issue.

See above. I meant with "has use" in that someone can see deploying a
use case on its technical merits.

> Err, how could that be the outcome of a use cases document? Or are you envisioning this as also being a protocol document? (FWIW, I would love to have such a protocol, but I think it's a bad idea t…

Eventually. Not through this use-cases documen, but a protocol document
that is written taking the use cases of this document into
consideration.

> So this is now a list of current practices that are not working?

That's part of it. Another part is new shiny awesome things we could
never do before :P

> That's a business argument.

internet is business, yes?

> That all seems fine. What does it have to do with describing the practices today?

I attempted to describe how we could better facilicate automation using
DNSSEC - clearly that involves showing where the lack of DNSSEC now is
hampering automation currently.

Paul

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 16 Jul 2012 22:37:25 +0200

Suggestion:

JUST talk about things like:

1. we have registry, registrar, registrant and DNS operator"

2. any of those might give the right to a third party to act on their behalf

3. we only know there are direct connections and knowledge between registry-registrar, registrar-registrant and registrant-dns operator

What we MUST have is:

- Enough data in the registry so that DS can be created that refer to key material used to sign the zone published by the dns operator

Today we know that we have cases like:

A. The DS is passed to the registry

B. The DNSKEY is passed to the registry that create the DS

C. The DNSKEY is fetched from the zone of the DNS operator and the DS is created

We have the following plus and minuses:

bla bla bla

   Patrik

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 24 Jul 2012 16:07:46 +0200

On 16-07-12 22:37, Patrik Fältström wrote:

> 1. we have registry, registrar, registrant and DNS operator"

In the DNSSEC transfer issues we discussed, we did enter a reseller,
so the administrative chain that is general enough for any current
relationship is:

Registry-Registrar-Reseller-Registrant-DNS_operator.

Where there may be 0-1 Registrars and 0-multiple resellers in the
administrative chain.

The more general mistake is that one entity can play multiple roles.
So one entity may act as both Registrar and DNS_operator for a certain
delegation where in another delegation one entity may be both
registrant and DNS_operator. So they are roles, not players. This is
often not understood in discussions. (you may even have entities that
combine registrar and multiple reseller roles).

> 3. we only know there are direct connections and knowledge between
> registry-registrar, registrar-registrant and registrant-dns
> operator

The issue for the administrative chain is the question as to who
offers the authoritative data.

For a Registry, the registry database IS the authoritative data, which
is fed into the DNS parent zone.

So from the point of view of the parent zone, it only accepts changes
from the Registry database and not from another source.
Or to put it in pictures:

Registrant/Reseller/Registrar => Registry database => DNS Parent zone

If we only look technically at the DNS, what we're trying to do here is:

Parent zone <=> Child zone

To keep them both in sync.

But this leads to problems in the administrative chain:

Registrant/Reseller/Registrar => Registry database <=> DNS parent zone

Which data is authoritative for the Registry database, The registrar's
input, or the DNS input ?
Registrars claim they are always right, we DNS people claim DNS is
always right.
We need the registrar's input for bootstrapping the delegation at least.
The question is who is authoritative for the delegation after that.
DNS or the registrar's input.

> What we MUST have is:
> 
> - Enough data in the registry so that DS can be created that refer
> to key material used to sign the zone published by the dns
> operator
> 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
> 

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 24 Jul 2012 16:38:07 +0200

On 24 jul 2012, at 16:07, Antoin Verschuren wrote:

> On 16-07-12 22:37, Patrik Fдltstrцm wrote:
> 

My point is that you complicate things by including reseller. A reseller can be viewed as the down-facing portion of the registrar.

The problem is not there, The problem is the gap between the others (see below).

> The more general mistake is that one entity can play multiple roles.

Yes. And too many do believe the registrar do run DNS, in the form of saying "registrar" when they mean "DNS operator".

> offers the authoritative data.

Agree, but that is a different issue from what I am talking about.

I am talking about the problem that you have one path like this:

dns operator - registrant
registrant - registrar
registrar - registry

...as the three connections we know we have to create a chain between dns operator and registry.

Then you have the potential difference between what the dns operator have and what is in the zone that the registry produces from the content of their database.

Now, if you create a mechanism where the parent zone is produced by data fetched from a merge between what is in the registry database and in the child zone, then you still must recognize that the only data you have to bridge that gap are the three connections I list above.

And btw, this is not something new for DNSSEC, as we have same issue with NS record or glue in the cases that is needed.

> To keep them both in sync.

Correct as a goal.

> input, or the DNS input ?

I do not see that as a problem, although I agree that is one. What is the problem is for the registry (or mechanism that produces the parent zone) to know what is the correct DNS child.

> DNS or the registrar's input.

What I am talking about is how the registry knows that the child DNS is really the child DNS. If you do, then of course you can as parent "just" fetch the data from there.

   Patrik

---

From: Edward Lewis <[email-masked]>
Date: Tue, 24 Jul 2012 12:25:50 -0400

At 17:05 -0400 7/14/12, Joe Abley wrote:

>Any new work which needed to assert that both sets were the same would
>meet with little objection though, I think.

I disagree.

I would object to any strengthening of what is said in STD 13.

Yes, the two sets are designed to be the same.  But if they had to 
always be the same, it would bi impossible to add or delete NS 
records.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: Joe Abley <[email-masked]>
Date: Tue, 24 Jul 2012 12:30:51 -0400

> always be the same, it would bi impossible to add or delete NS 

In this context, "the same" refers to the steady state: i.e. a mechanism which standardised the promotion of an updated, signed apex NS set to form a replacement delegation set in the parent would be one that enforced that steady-state similarity. This is in contrast to a conscious operational decision to keep the delegation and apex NS sets different in the steady state (which at least a couple of us have observed).

My point was that prevalent deployment of such mechanisms which prevented (or made difficult to maintain) such conscious dissonance would likely meet with little objection.

Joe

---

From: Chris Thompson <[email-masked]>
Date: 24 Jul 2012 18:43:01 +0100

On Jul 24 2012, Joe Abley wrote:

[...]
>In this context, "the same" refers to the steady state: i.e. a mechanism
>which standardised the promotion of an updated, signed apex NS set to form
>a replacement delegation set in the parent would be one that enforced that
>steady-state similarity.

Even if the intent is for the sets to converge, it isn't obvious that
upward propagation ("promotion") is always the best way to do things.
In theory, at least, I try to make changes in this order:

 Adding an NS:   1. Set up the slaving arrangement.
                 2. Add to the in-zone NS RRset.
                 3. Add to the delegation NS RRset.

 Dropping an NS: 1. Delete from the delegation NS RRset.
                 2. Delete from in-zone NS RRset.
                 3. Tear down the slaving arrangement.

It's true, though, that I wouldn't much care about the order of the first
two actions in the latter case if I could be sure that the updating of the
delegation could always be done in a timely fashion.