Subject: Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01

From: Tony Finch <[email-masked]>
Date: Fri, 1 Mar 2013 10:58:10 +0000

Edward Lewis <[email-masked]> wrote:
>
> I'm hoping to avoid yet another too-large RRset that could cause
> problems in abuse situations.

Hmm, I wonder if it would be enough to put only the key tag in the CDS
RDATA, and let the parent calculate the DS from the corresponding DNSKEY.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Fri, 1 Mar 2013 04:08:52 -0700

Friday, March 01, 2013 11:58 AM Tony Finch wrote:

> RDATA,
That wouldn't work because you might have two keys with exactly the same
key-tag. You can't be certain that the key-tag is unique.

> and let the parent calculate the DS from the corresponding
> DNSKEY.
Assuming that the parent knows the algorithm that the child wishes to
use for his DS record. That might not always be the case.

I'm more concerned that we bloat the zone apex even further so that
querying for 'example.com ANY' amplifies even more.

---

From: Tony Finch <[email-masked]>
Date: Fri, 1 Mar 2013 11:37:49 +0000

> key-tag. You can't be certain that the key-tag is unique.

True, however it's common for tools to ensure tags are unique.

> use for his DS record. That might not always be the case.

You could include an algorithm field.

Tony.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 1 Mar 2013 22:34:05 +0800

> RDATA, and let the parent calculate the DS from the corresponding DNSKEY.

I would have liked to go that way, but there are reasons why not:

There is an operational case of a TLD having a DS record in the root not pointing to a DNSKEY.  (Just to establish that this is not hypothetical.)  There's no requirement that the DS "point to" a published DNSKEY to allow for a key change that only wants to have one SEP at a time.

This allows the child to choose the hash fields it wants.

The key tag is not guaranteed to be unique.  In fact, there have been keys present in TLDs that have the same key tag but different algorithms.  To be clear, different TLD, different algorithm, different keys - same key tag/foot print.

And finally - I have this "moral objection" to having the registry calculate the hash - a registry should just be recording the objects thrown it's way.  Okay, pre-delegation checks, etc., but I draw the line at the parent "altering" data unilaterally.

PS - If a registry insists on calculating the hash, well, it won't be able to support pre-publishing of DS records.  But if the DNSKEY is there, it can ignore the hash and redo the work.

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

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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 01 Mar 2013 10:50:58 -0500

Tony,
CDS allows:
	publication of DS w/o inclusion in DNSKEY
	publication of DS w hash that the Parental Agent
		does not "support".
		
One CDS's goals is to get the "Parent" out of the habit of
calculating hash, just publish what the Child wants.
In theory a parent can amend what the Child wants by adding
a DS record for a strong digest algorithm, but then the parent
has to remove these records when the child removes the algorithm,
yes and that has the corner case that child could have two
keys same algorithm with the same key tag :-).

IFF we think that no one will use the two actions above we can
just use the SEP bit and let the parent calculate the hash but that
leaves the parent in a vulnerable position i.e. if the parent only
publishes Digest_alg X hashes and few implementations support X
thus those domains look unsigned to large part of the world.

	Olafur

---

From: Paul Wouters <[email-masked]>
Date: Fri, 1 Mar 2013 11:10:07 -0500 (EST)

On Fri, 1 Mar 2013, Olafur Gudmundsson wrote:

that's all local parent policy.

child just announces "these are the DS records you are looking for"

Whatever is published is the subset of child/parent policy overlap.

Paul

> Date: Fri, 1 Mar 2013 10:50:58
> From: Olafur Gudmundsson <[email-masked]>
> To: [email-masked]
> Subject: Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01
> 
> Tony,
> CDS allows:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Fri, 1 Mar 2013 09:29:43 -0700

Tony Finch Friday, March 01, 2013 12:38 PM:
> > > Hmm, I wonder if it would be enough to put only the key tag in the
> > > CDS RDATA,
> >
> > That wouldn't work because you might have two keys with exactly the
> > same key-tag. You can't be certain that the key-tag is unique.
> 

I know first hand of at least one tool that doesn't. It would be good if
any new RFC is backward compatible.

> > > and let the parent calculate the DS from the corresponding DNSKEY.
> >

The parent might not have access to the new algorithm in the software.
If for example the child wishes to use SHA-X but the parent only
supports SHA-Y. What should the parent do if the child flags for SHA-X
in this algorithm field but it is not available?

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 4 Mar 2013 11:39:02 +0100

> calculating hash, just publish what the Child wants.

I strongly disagree on this.
I don't think CDS goal should be to mandate registry policy.
Let me get some real world data in there.

The majority of DNSSEC delegations in TLD's today were set up by
sending DNSKEY to the registry and have the registry calculate the
hash it supports at the parent. Our registrars do it, and they have
absolutely no issue with it.

DS is on the parent side of the zone cut. The child should not bother
to calculate DS, certainly not with algorithms the parent doesn't
support. The risk is that childs can deliberately choose algorithms
that will diminish the integrity of the parent zone. It should only
care that the chain of trust points to the correct child DNSKEY.

It's the parent that mandates the policy of the zone and domain it
serves. From RFC 1034: "When some organization wants to control its
own domain, the first step is to identify the proper parent zone, and
get the parent zone's owners to agree to the delegation of control."

If a child wants a delegation from a parent, it should follow the
parent's policy. It's the parent that determines the policy and can
choose the algorithms it wants to support under it's domain. Let the
parent calculate the hash it needs to put into their zone.

I feel the argument that states that "the parent should just publish
what a child wants" is in violation of RFC 1034 and local registry
policy. It is not documented anywhere where that argument comes from,
and it is actually wrong. It's an anarchist attempt to bend the rules
for more influence that does not comply with the DNS structure. Out of
frustration that parents don't act as they would in supporting
algorithms. Then choose a different parent.

And it works just fine when everybody minds his own business.
Childs do DNSKEY, parents do DS.

- -- 
Antoin Verschuren

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

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email-masked]
XMPP: [email-masked]
HTTP://www.sidn.nl/

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Mar 2013 08:22:28 -0500

> I don't think CDS goal should be to mandate registry policy.

Contrarily, I don't think the goal should be for registry policy to dictate what DS records should be acceptable for a child. I think this should be the child's decision.

> absolutely no issue with it.

By the number of DS records published in registry zones, you might be right. But as a counter data-point, I have signed domains delegated from CA, ORG, NET, COM and NZ and I have never supplied a DNSKEY RRSet to the parent; I have only ever supplied a DS RRSet.

> support.

If as a child I want to use an experimental or newly-standardised algorithm, I should be able to do so. The parent zone operator should care that the DS RRSets are well-formed and legal; they should not care what the RDATA is.

The relying parties for my signatures in my zone might well not include the parent zone operator. Why should the choice of algorithms for those relying parties be restricted by what the parent zone operator thinks is acceptable?

We're threatening the future development and use of new algorithms by institutionalising these restrictions.

> The risk is that childs can deliberately choose algorithms
> that will diminish the integrity of the parent zone.

What is that risk? I don't see it.

Joe

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 4 Mar 2013 15:44:04 +0100

Op 04-03-13 14:22, Joe Abley schreef:

> Contrarily, I don't think the goal should be for registry policy to
> dictate what DS records should be acceptable for a child. I think
> this should be the child's decision.

That's for local policy to decide.
A domain might want to profile itself as only accepting tested and
secure algorithms so it's users know what to expect in that domain.
A single child stepping in with it's own unsupported algorithm to try
to break that expectation does not help us to a better place.

> If as a child I want to use an experimental or newly-standardised
> algorithm, I should be able to do so.

I expected that argument.
Experiments should be done in a lab.
On a network that we want to be reliable and secure, experiments from
children should not dictate parent policy.

> The relying parties for my signatures in my zone might well not
> include the parent zone operator. Why should the choice of
> algorithms for those relying parties be restricted by what the
> parent zone operator thinks is acceptable?

I want to experiment with MD5. Could the root please supply me with
MD5 signatures, as my relying party does not understand anything else..
If you want to use my domain, you should at least support the
algorithms I use for the hashes in my chain of trust to the root.
Anything else on top of that is fine, but you can't do without mine.

> We're threatening the future development and use of new algorithms
> by institutionalising these restrictions.

If you want to experiment with algorithms in your own zone, under your
own domain, with your own SEP as trust anchor, be my guest. Do that on
your own level in your own tree. But don't force your parent to
facilitate each and every experiment. Once an algorithm is tested and
considered deployed in the policy area the parent wants to serve, I'm
sure they will use it.

- -- 
Antoin Verschuren

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Mar 2013 10:02:05 -0500

Hi Antoin,

> That's for local policy to decide.

No, I think whether or not local policy should be able to restrict the choices of the child is wider than that.

> secure algorithms so it's users know what to expect in that domain.

Exactly, and "tested" and "secure" might well mean different things to the relying parties for the child zone's signatures than to the parent zone operator.

> to break that expectation does not help us to a better place.

"unsupported" also means different things to different people. How many TLD registries support the standardised ECC-GOST algorithms, for example?

> children should not dictate parent policy.

I fully support your right to make decisions about your own production infrastructure (cf "should be done in a lab"). I'm not sure why you would argue that the same courtesy should not be extended to registrants.

> MD5 signatures, as my relying party does not understand anything else..

I think that's valid, actually. But perhaps re-cast your example with GOST R 34.11-94 and see whether your argument is as persuasive.

> Anything else on top of that is fine, but you can't do without mine.

I can, actually. I can use whatever algorithms my relying parties find acceptable.

My expectation is that the operator of my parent zone is publishing data on my behalf (in return for money) to suit my requirements. I don't understand why the operational requirements of validators also operated by the operator of my parent zone need concern me.

> considered deployed in the policy area the parent wants to serve, I'm

Forget experiments; think "algorithms that have been standardised and for which code points have been issued". By encouraging the expectation that the registry gets to decide what is reasonable or not, and providing no reason for those decisions to ever be revisited, we've leaving no room for future algorithms (which might have substantial technical advantages over those commonly used today) to ever see deployment across a zone cut.

I think TLD registry operators should remove themselves from the business of providing quality control over DS RRSets, just as (most) do with NS RRSets. Such behaviour unnecessarily constrains technical decisions made by the operators of child zones, acts to suppress the use of new algorithms and provides no tangible benefit to child nor parent.

Joe

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 4 Mar 2013 17:21:20 +0100

Op 04-03-13 16:02, Joe Abley schreef:

> I think TLD registry operators should remove themselves from the
> business of providing quality control over DS RRSets, just as
> (most) do with NS RRSets. Such behaviour unnecessarily constrains
> technical decisions made by the operators of child zones, acts to
> suppress the use of new algorithms and provides no tangible benefit
> to child nor parent.

And gives room to all the miscreants that want to abuse that as it
only gives benefit to the use case of that one child, but a parent has
to watch over all his children.
We do check NS/DS/whois data, phishing and typo squating, DNS abuse
and DDOS attakcs and our constituency also wants us to do that to feel
comfortable under our domain. It has proven to create a safer environment.

It has little to do with TLD's, it has to do with being a good parent.

I'm all for experimenting and innovating. But I'm also for stability
and security for the ones that need that. That's also a use case that
needs to be supported. So do experiments in your own tree, not
affecting the tree others use for stability. Create your own. DNS is
perfectly suited to do that without including your parent and all it's
other children into your own experiment.

I don't see the difference in algorithm adoption when only a DS hash
at the parent is to be chosen freely when the parents DNSKEY is stil
set by parents policy. A DS is not a SEP, the DNSKEY is. I feel the
whole discussion is more emotion than fact. People want to influence
what their parent does, as little children asking for a higher
allowance. Not realizing that they can be a parent themselves if they
want to, but walk away from that responsibility.

I think the whole idea of sending a DS to your parent is also
historical, and has nothing to do with the model. Because BIND's
signing tools creates both your DNSKEY and a DS hash for convenience
of experimenting, everybody now thinks he has to do something with
that DS, and because you created it it's yours. We started off wrong
by accepting DS as parents, we should have started with DNSKEY right away.
Other processes need DNSKEY (Secure DNS operator transfers f.e.).

- -- 
Antoin Verschuren

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Mar 2013 12:16:30 -0500

Hi Antoin,

It's clear that we have different opinions on this, and I don't want to argue for the sake of noisemaking. However, I have a couple of clarifying questions (see below).

> to watch over all his children.

How is it safer for the operator of a parent zone to generate DS RRSets from supplied DNSKEY RRSets (constrained to only those algorithms the parent has blessed) than to accept any DS RRSets from children?

You seem to have a threat in mind that the former behaviour mitigates, but I can't see what it is.

> want to, but walk away from that responsibility.

So, to clarify, can the operator of a child zone who prefers to use an algorithm 14 DNSKEY send you that key, confident that you will accept it? What about algorithm 253?

> historical, and has nothing to do with the model.

I agree, it's a bit tangential to the question at hand (although it's relevant to the question of whether the operator of a child zone should have any influence over the digest algorithm used in the parent's DS RRSets).

I don't agree that sending a DS RRSet to your parent is historical, though, since it seems to me that most TLD registries accept a DS RRSet and not a DNSKEY RRSet. I've done no survey to confirm these numbers (as I mentioned before, it's just personal experience based on the TLDs I happen to interact with). Rather than "historical" I would have said "common practice today".

Joe

---

From: Paul Wouters <[email-masked]>
Date: Mon, 4 Mar 2013 12:20:43 -0500 (EST)

> to break that expectation does not help us to a better place.

Sometimes the child is wrong, sometimes the parent is wrong. I'd say
leave this all out of the discussion. Use simple DS format for CDS,
the child can steer the parent, the parent decides if it will give
the child their record or not.

> children should not dictate parent policy.

Unfortunately there are bad parents around too. Like those who remove DS
records for a transfer because "children do it wrong so often, we want
to help them by not having their domain go dark" and instead dictate to
the child they will be insecure during transfer.

> Anything else on top of that is fine, but you can't do without mine.

I fear the problem is more the reverse. Look at DS record and IPv6 glue
adoption. Hoards of children are waiting for their parents (or baby
sitting registrars) to get their act together. And don't tell me
adoption was slow in purpose for "security and stability" reasons :/

> facilitate each and every experiment.

Having done a bunch of FIPS work, let me tell you how HARD it is to
convince parents/upstream to switch from MD5 to SHA1 or better. Parents
need to update their policies too.

So please, cut down on the condescending parental talk :)

Paul

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 5 Mar 2013 11:25:40 +0100

> Hi Antoin,

Hi Joe

> It's clear that we have different opinions on this, and I don't
> want to argue for the sake of noisemaking. However, I have a couple
> of clarifying questions (see below).

And I'm shouting a bit too acting as a devil's advocate.
Please don't get me wrong in that I'm not trying to see your points.
I just think that a tree is either experimental or production, but it's
unwise to be both. The discussion is on where the subtree starts.

> How is it safer for the operator of a parent zone to generate DS
> RRSets from supplied DNSKEY RRSets (constrained to only those
> algorithms the parent has blessed) than to accept any DS RRSets
> from children?

There are some parents that check/verify the RDATA in their zone.
As a service to help children notice their mistakes or misconfigurations.
This service is often appreciated, except for children that willingly
want to be able to enter invalid data into the parent zone, and want
to force the parent to accept that.
For a parent to be able to validate, they need to understand and have
implemented the algorithm in their validation software.
If the parent generates the DS, he knows he understands that algorithm,
so there's one less thing to worry about.
Creating the DS yourself is easier than trying to verify a DS and
refusing the ones that are not understood. And when we want to change
the algorithm in the future with one that is more secure or cheaper
for our zone, we can do that ourselves without a painful migration
process that involves all our child operators.

> So, to clarify, can the operator of a child zone who prefers to use
> an algorithm 14 DNSKEY send you that key, confident that you will
> accept it? What about algorithm 253?

No.
If the child prefers to use an experimental algorithm as a SEP for it's
own experiment, he can happily enter that into his DNSKEY RRset. And he
can generate or accept DSes for all the children under that zone that
want to experiment with that algorithm in that tree. The chain of
trust for that experiment starts at that subtree.

But we don't accept that algorithm for the delegation in our chain of
trust that starts at the root until that algorithm is widely deployed in
the validating resolvers we serve. That's our local policy.
We do DNSSEC because we want all end users be able to validate the
delegations we make.
DNSSEC is only adopted if it works and is reliable. Our zone is not
(partly) experimental.
So we validate delegations, and receive validation errors from ISP's
that we distribute to the registrars so they can fix their errors.
We currently accept a wide range of algorithms we know are implemented
in most of the validating resolvers.
Using an algorithm we know is not widely implemented will cause
validation errors in the majority of resolvers we serve, and we feel
responsible that at least our zone and the delegations we make work.
What happens in trees below is the responsibility of the delegated party
and their local policy.

We wouldn't have seen the gigantic uptake of DNSSEC under .nl if we
didn't guarantee to our constituency that we would actively make
DNSSEC work for at least our zone. Our zone is not experimental
anymore, it's production.

> Rather than "historical" I would have said "common practice
> today".

Yes, I must agree if you count number of registries and not the number
of delegations.

I must say we could have lived with the "sending DS" with the knowledge
we had 5-10 years ago. We then thought that sending DS was less error
sensitive because of the shorter string, and we would still be verifying
DS submission over the phone.

But our recent experience with DNSSEC, where automation has improved,
shows that this is hardly an issue. More errors are being made within
smaller incapable operators creating and matching their DS from a
DNSKEY then when they just send in their DNSKEY and we create the DS
for them. So I also have a bias towards "sending DNSKEY" out of
experience and not theory.

But our major motivation for "sending DNSKEY" is the secure DNS operator
change I mentioned. This has not been implemented yet by these
registries, so there's no real world experience with most of the
registries that now only accept DS. Sending a key format for a DNS
operator change, and a DS format for a delegation request makes matters
complex for the child operators. That's why we accept key format for all.

- -- 
Antoin Verschuren

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 5 Mar 2013 07:34:46 -0500

> We do DNSSEC because we want all end users be able to validate the

So for clarity if a .NL domain tries to set a DS set like this you will reject it? 
    DS   12345 8 3 …… 

But will you accept 
	DS 12345 8 2 ….. 
	DS 12345 8 3 ….. 
? 

i.e. the child has both SHA256 and the other algorithms 

Second question: 
DO you accept 
	DS 12345 14 2 …… 

(ECDSA p384)

In all he cases above the validator can see when it gets the DS record if it supports the
algorithms in question it can treat the zone as validatable or unsigned. 

This is the same in my mind if a web site is only published in Dutch then it limits its potential 
readership to Dutch readers, if I sign my zone with ECDSA I limit my validators to only the latest and
greatest validators) 

….
> complex for the child operators. That's why we accept key format for all.

But in this case you NEED the ZSK not the KSK 

	Olafur

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 5 Mar 2013 17:29:53 +0100

Op 05-03-13 13:34, Olafur Gudmundsson schreef:

> But will you accept DS 12345 8 2 ….. DS 12345 8 3 …..
> 
> Second question: DO you accept DS 12345 14 2 ……

We do not accept any DS.
We accept DNSKEY with algorithms 3,5,6,7,8,10,12.
We always use
DS 12345 8 2 ... . .
in our zone, as we know you cannot use our chain of trust from the
root anyway if you don't support that algorithm.
Our zone is not the start of any chain of trust, so you have to be
able to use the DS we have chosen in the root for our zone to validate.

- -- 
Antoin Verschuren

---

From: Paul Wouters <[email-masked]>
Date: Tue, 5 Mar 2013 11:44:47 -0500 (EST)

On Tue, 5 Mar 2013, Antoin Verschuren wrote:

> Our zone is not the start of any chain of trust

That's a TLD corner case (and not entirely true at that, since you don't
really know what I configure as trust anchor in my resolver)

There are many more parent-child relationships then just the
registry-registrar-registrant case which involves other paths of
trusts like EPP.

The CDS draft, while it can also be used there, will likely see more
significant use elsewhere in the chain, so please let's not focus the
discussion of this draft to the RRR business.

That said, I'm still with the authors. Keep the CDS format identical to
the DS format. (and let parent and child local policy determine what to
do with the CDS RRset)

To get back to the draft: I have not seen too many people talk about the
CNS/GLUE record types. Should those be in this draft, a separate draft,
or no where?

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Mar 2013 08:54:53 -0800

> the DS format. (and let parent and child local policy determine what to

Seeing that at least a few zones have a good reason to take DNSKEY as input to their "add a DS" process, I propose the CDS add another type of record, CDNSKEY. Only one of CDS and CDNSKEY is allowed in an RRset to prevent silly states.

---

From: Joe Abley <[email-masked]>
Date: Tue, 5 Mar 2013 12:05:41 -0500

> Seeing that at least a few zones have a good reason to take DNSKEY as input to their "add a DS" process, I propose the CDS add another type of record, CDNSKEY. Only one of CDS and CDNSKEY is allowe…

I presume this has already come up, and there are good reasons why the apparent lexical flexibility in what I'm about to suggest are swamped by a sea of vicious snakes, but if the goal is "transmitting general information to the parent which in some cases they might care about" why not think about a more general RRType of the form

; zone cut
example.com. IN SOA ...
;
example.com. IN PARENT DS parental-hints.example.com. example.com.
example.com. IN PARENT A ns1.example.com. ns1.example.com.
example.com. IN PARENT A ns2.example.com. ns2.example.com.
example.com. IN PARENT AAAA ns2.example.com. ns2.example.com.
example.com. IN PARENT NS example.com. example.com.
;
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
;
ns1.example.com. IN A ....
ns2.example.com. IN A ....
ns2.example.com. IN AAAA ....
;
parental-hints.example.com. IN DS ....

A parent that cared (tm) could seek a secure answer to child/IN/PARENT and extract RRSets pertinent to the delegation (NS, A, AAAA, DS, etc). Each PARENT RR provides an RRType and an owner name where the record in question can be found, together with an owner name that the parent should presume applicability.

I have not thought this through very well, but in general it seems to me that if we're going to create a mechanism by which zone data in a child can be interpreted flexibly by a parent, standardising a new RRType for every possible interesting RRSet seems annoying.

Joe

---

From: Ralf Weber <[email-masked]>
Date: Tue, 5 Mar 2013 17:06:07 +0000

Moin!

> really know what I configure as trust anchor in my resolver)
Sure, but to validate on the public Internet I would strongly advise to use the root key. Anything else is calling for trouble and with a signed root we should assume that people do this unless they have a private DNSSEC deployment. I wouldn't see that as a corner case.

> registry-registrar-registrant case which involves other paths of
While EPP is used in lots of TLDs for domain registration this draft actually describes the case where it applies for (DNS operator is not registrar) and that also is a common case. I don't think we should leave out the RRR cases in that draft.

So long
-Ralf
---
Ralf Weber
Senior Infrastructure Architect
Nominum Inc.
2000 Seaport Blvd. Suite 400 
Redwood City, California 94063

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Mar 2013 09:09:03 -0800

On Mar 5, 2013, at 9:05 AM, Joe Abley <[email-masked]> wrote:

> example.com. IN PARENT SOMERRTYPE rrtype-specific-data...
> . . .

+1

--Paul Hoffman

---

From: Miek Gieben <[email-masked]>
Date: Tue, 5 Mar 2013 18:37:46 +0100

[ Quoting <[email-masked]> in "Re: [DNSOP] General comments on dra..." ]
> > parent which in some cases they might care about" why not think about a more
> > general RRType of the form
> > 
> > ; zone cut
> > example.com. IN SOA ...
> > ;

I like this approach too.

 Grtz,

-- 
    Miek Gieben                                               http://miek.nl

---

From: Joe Abley <[email-masked]>
Date: Tue, 5 Mar 2013 12:45:12 -0500

>> example.com. IN PARENT SOMERRTYPE rrtype-specific-data...

I thought of that approach too, but it seems inadequate for the purposes of signalling candidate glue to a parent (there's no obvious way to encode an owner name, and the owner name is necessary with glue, unlike NS or DS RRSets).

I guess another approach for that particular problem is to note the child's desired NS set and then use local policy to acquire secure answers for glue records where needed.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Mar 2013 09:51:08 -0800

> I guess another approach for that particular problem is to note the child's desired NS set and then use local policy to acquire secure answers for glue records where needed.

That seems sufficient. That is, the child doesn't get to say "this is the glue", but the parent can decide where to look for glue.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 5 Mar 2013 13:17:12 -0500 (EST)

> Seeing that at least a few zones have a good reason to take DNSKEY as input to their "add a DS" process, I propose the CDS add another type of record, CDNSKEY. Only one of CDS and CDNSKEY is allowe…

Oh, I like that!

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 5 Mar 2013 15:01:35 -0500 (EST)

> example.com. IN PARENT A ns1.example.com. ns1.example.com.

I'm very nervous about such a fundamental zone syntax change. It's going
to take forever for zone tools to take up on this.

It would be better to use a non-IN class PARENT

example.com. PARENT DS parental-hints.example.com. example.com.

Paul

---

From: Joe Abley <[email-masked]>
Date: Tue, 5 Mar 2013 15:04:34 -0500

> to take forever for zone tools to take up on this.

Every new RR is a zone syntax change.

> example.com. PARENT DS parental-hints.example.com. example.com.

If the record is not in the same class, then it's not in the same zone. That route takes us back to Vixie metazones.

Joe

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 5 Mar 2013 15:10:16 -0500

I will try to organize a face to face meeting on the topic of moving DNS delegation information in-band (inside DNS) 
from child to parent,  at the IETF next week (will send out report after meeting)
If you are interested in attending let me know and in general what times are good for you, 

	Olafur

---

From: Paul Wouters <[email-masked]>
Date: Tue, 5 Mar 2013 15:18:02 -0500 (EST)

> Every new RR is a zone syntax change.

Not true. I am still running generic record syntax in some opendnssec
signers because those systems don't know all new RRtypes.

> If the record is not in the same class, then it's not in the same zone. That route takes us back to Vixie metazones.

Ahh, I had not realised that.

Paul

---

From: Joe Abley <[email-masked]>
Date: Tue, 5 Mar 2013 15:49:06 -0500

> signers because those systems don't know all new RRtypes.

RFC 3597

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Mar 2013 12:50:00 -0800

> If you are interested in attending let me know and in general what times are good for you, 

Why not have this as port of the DNSOP WG meeting? We have an hour and, so far, only three items on the agenda.

--Paul Hoffman

---

From: Chris Thompson <[email-masked]>
Date: 05 Mar 2013 21:30:22 +0000

>On Tue, 5 Mar 2013, Joe Abley wrote:
[...]
>> If the record is not in the same class, then it's not in the same zone.
>> That route takes us back to Vixie metazones.
>

It dates all the way back to RFC 1033 - "A zone file should only contain RRs
of the same class". 

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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 5 Mar 2013 16:50:36 -0500

> Why not have this as port of the DNSOP WG meeting? We have an hour and, so far, only three items on the agenda.

We need more than one hour :-)  

	Olafur

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Mar 2013 17:29:12 -0800

> We need more than one hour :-)  

I'm sorry you feel this way. Given the level of interest on this list, it seems better to have the discussion in an WG session.

--Paul Hoffman

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 6 Mar 2013 11:42:34 -0500

Jim and Paul

Since we started this discussion I have got more private emails/IM's  about 
	"how <insert emotion> this <insert person> is"  
than ever before in working on IETF drafts. Thus I want some of the people that have strong opinions 
and feelings to clear the air and reach understanding or at least civility. I also want to listen to people that have different perspectives/roles. 

Warren and I have requested a time slice in DNSOP to report on what the status is and possible ways forward,
such as: 
	a) go ahead with possible minor changes 
	b) modify it to reflect what we think may work  
	c) drop it. 
	d) Propose a different way forward (say PARENT proposal) 
	e) Should we add NS and Glue to the effort ? 
and if should this belongs in DNSOP  or not. 

	Olafur

On Mar 6, 2013, at 10:26 AM, James M Galvin <[email-masked]> wrote:

> I'm interested in this topic and like Paul am disappointed you're not having during a WG session.
> 
> Scheduling will be difficult if you're looking to have it outside of WG sessions.
> 
> I suggest a doodle poll of some options, maybe all the options that fit your schedule and then we see how it shapes up.
> 
> Jim
> 
> 
> 
> -- On March 5, 2013 3:10:16 PM -0500 Olafur Gudmundsson <[email-masked]> wrote regarding [DNSOP] F2F meeting in Orlando Re: General comments on 	draft-kumari-ogud-dnsop-cds-01 --
> 
>> I will try to organize a face to face meeting on the topic of moving
>> DNS delegation information in-band (inside DNS)  from child to
>> parent,  at the IETF next week (will send out report after meeting)
>> >>> I presume this has already come up, and there are good reasons
>> >>> why the apparent lexical flexibility in what I'm about to suggest
>> >>> are swamped by a sea of vicious snakes, but if the goal is
>> >>> "transmitting general information to the parent which in some
>> >>> cases they might care about" why not think about a more general
>> >>> RRType of the form
>> >>>
>> >>> ; zone cut
>> >>> example.com. IN SOA ...
>> >>> ;
>> >> I'm very nervous about such a fundamental zone syntax change. It's
>> >> going to take forever for zone tools to take up on this.
>> >
>> > If the record is not in the same class, then it's not in the same
>> > zone. That route takes us back to Vixie metazones.
>> >
>> >
>> > Joe

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Mar 2013 15:58:03 +0000

> CNS/GLUE record types. Should those be in this draft, a separate draft,

Why not use the child's normal NS records?

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Mar 2013 11:36:28 -0500 (EST)

> Why not use the child's normal NS records?

To ensure that the child is aware and willingly telling the parent to
update.

Paul

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Mar 2013 16:58:42 +0000

> To ensure that the child is aware and willingly telling the parent to

Right. Do you need more than one bit to signal this behaviour?

dotat.at. 3600 IN SYNCNS

(I tend to think a good parent would keep the delegation in sync even
without this signalling but I understand the desire for a middle way.)

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Mar 2013 12:00:27 -0500 (EST)

> without this signalling but I understand the desire for a middle way.)

It's an option. Although I would then also lump in the A/AAAA sync in
there, so I would not call it SYNCNS.

Paul

---

From: Doug Barton <[email-masked]>
Date: Thu, 07 Mar 2013 10:18:26 -0800

> without this signalling but I understand the desire for a middle way.)

Yeah, that's what I have sort of been thinking about this ... I agree 
with Paul that you'd want something more general to cover DNSKEY, NS, 
glue, <something else?>. I was sort of thinking SCRAPEME had a nice ring 
to it. :)

I also think it makes more sense to signal the parent to act, rather 
than having the parent need to periodically poll the zone to detect the 
existence of special records, or updates to those records. I also like 
signalling in order to avoid cluttering the child zone with these types 
of hints to the parent.

Doug

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Mar 2013 13:26:25 -0500 (EST)

On Thu, 7 Mar 2013, Doug Barton wrote:

> I also think it makes more sense to signal the parent to act, rather than 
> having the parent need to periodically poll the zone to detect the existence 
> of special records, or updates to those records. I also like signalling in 
> order to avoid cluttering the child zone with these types of hints to the 
> parent.

signaling won't work for too many reasons:

- hidden primaries
- hidden DNSSEC signers
- unwillingness for large AUTH servers to add complexity to their main
   public servers.
- firewalls between child and parent
- firewalls between parent and signer
- additional security checks of the signalling, anti-DDOS measures, etc

If you have a parent-child signaling relationship that works, why not
use something like dynamic updates?

Or for the RRR case, you could do some signaling over EPP.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Mar 2013 12:29:46 +1100

> use something like dynamic updates?

Remember dynamic update don't have to go to the servers for the
zone.  They can be sent to any reachable address.  The only requirement
is that they be signed to prevent forgeries being ccepted.

>  Or for the RRR case, you could do some signaling over EPP.

Or just give the registrars a DNS to EPP translating server to use
in parallel with their HTTPS to EPP translating server.

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

---

From: Johan Ihrén <[email-masked]>
Date: Tue, 12 Mar 2013 14:52:34 -0400

> Why not use the child's normal NS records?

So, while I'm really late to this party due to travel, I would like to say that I strongly believe this to be the right approach.

As many of you know I've been advocating this for years, and am using this in production since about 2006 or so. I.e. "sync" of the NS RRset, and the glue is trivial really, because it is data that is authoritative in the child, has a signature by the child and can be validated by the parent.

The only reason that we're even discussing the CDS proposal (which I'm all in favour of) is that the DS record has the distinction of not being authoritative in the child, and hence not having a signature by the child anywhere.

So we need a new record for that, enter CDS.

Complicating this further than having the parent validate something that the child is authoritative for and if it validates then just copy it into the parent zone (assuming that's the parent's policy) does send off lots of danger signals and I fear we may rathole for a very long time. 

So while things like the swiss army knife approach a la "PARENT [subtype]" may look clever and flexible, I really think it is a howitzer disguised as an army knife. And all we need is a very small weapon to kill a rather small (but important) problem.

The KISS principle.

Regards,

Johan

---

From: Mark Andrews <[email-masked]>
Date: Wed, 13 Mar 2013 11:10:56 +1100

We really should be thinking of these in terms of a RFC 5011
replacement.  RFC 5011 is a kludge.

   start timestamp, end timestamp, refresh frequency

Mark

---

From: Doug Barton <[email-masked]>
Date: Wed, 13 Mar 2013 00:00:35 -0700

> So we need a new record for that, enter CDS.

If scraping NS is good enough for NS in the parent, why isn't scraping 
DNSKEY good enough for CD in the parent?

Doug

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Mar 2013 10:45:58 -0400

1. Because not all parents (by policy) construct DS records on behalf
of children;

2. Because sometimes you want to publish DS RRs in your parent that
correspond to standby keys that are not published in the child.

Aue Te Ariki! He toki ki roto taku mahuna!

On 2013-03-13, at 3:00, Doug Barton <[email-masked]> wrote:

> If scraping NS is good enough for NS in the parent, why isn't scraping DNSKEY good enough for CD in the parent?
>
> Doug
>

---

From: Doug Barton <[email-masked]>
Date: Wed, 13 Mar 2013 09:26:11 -0700

> 1. Because not all parents (by policy) construct DS records on behalf

So how likely are those parents to utilize CDS records to auto-publish 
DS? Or, put more simply, Do we have any indication that registry 
operators will actually use this? I know that registries are not the 
only zone parents, but without some significant buy-in from them I think 
that regardless of the merits of this idea it may be of low utility.

> correspond to standby keys that are not published in the child.

If the parents are actually using some method of accepting signals from 
the child to scrape the zone (whether CDS; actual scraping of NS, 
DNSKEY, etc.; or some other method) wouldn't that lower the barrier to 
entry for standby keys?

Doug

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Mar 2013 12:39:07 -0400

On 2013-03-13, at 12:26, Doug Barton <[email-masked]> wrote:

> So how likely are those parents to utilize CDS records to auto-publish DS? Or, put more simply, Do we have any indication that registry operators will actually use this? I know that registries are not the only zone parents, but without some significant buy-in from them I think that regardless of the merits of this idea it may be of low utility.

I am not a lawyer, but I understand that some interpretations of public gTLD contracts would prohibit registries from exchanging registry data directly with registrants (registrants should deal with registrars). However, there's nothing to stop registrars making arrangements with their registrants to receive change requests via signed RRSets. It may that for gTLDs (and other TLDs in a similar sitaution), we don't need buy-in from lots of registries; we need buy in from a registrar.

The question of how likely it is that anybody will implement this is difficult to answer without time travel capability. However, if there's no standardised mechansm, I think chances are good that nobody will implement anything.

> If the parents are actually using some method of accepting signals from the child to scrape the zone (whether CDS; actual scraping of NS, DNSKEY, etc.; or some other method) wouldn't that lower the barrier to entry for standby keys?

I don't understand the question. What does "lower the barrier to entry for standby keys" mean?

Joe

---

From: Doug Barton <[email-masked]>
Date: Wed, 13 Mar 2013 09:54:50 -0700

On 03/13/2013 09:39 AM, Joe Abley wrote:
>>> 1. Because not all parents (by policy) construct DS records on
>>> behalf of children;
>>
>> So how likely are those parents to utilize CDS records to
>> auto-publish DS? Or, put more simply, Do we have any indication
>> that registry operators will actually use this? I know that
>> registries are not the only zone parents, but without some
>> significant buy-in from them I think that regardless of the merits
>> of this idea it may be of low utility.
>
> I am not a lawyer, but I understand that some interpretations of
> public gTLD contracts would prohibit registries from exchanging
> registry data directly with registrants (registrants should deal with
> registrars).

The language tends to be focused around registries not contacting 
registrants directly. This sort of thing would likely be an exception to 
the rule, but I'm not a lawyer either. :)

It would be worth getting some clarity on this before moving forward 
though.

> However, there's nothing to stop registrars making
> arrangements with their registrants to receive change requests via
> signed RRSets. It may that for gTLDs (and other TLDs in a similar
> sitaution), we don't need buy-in from lots of registries; we need buy
> in from a registrar.

That makes the problem worse, right? As there are many more registrars 
than there are registry operators.

> The question of how likely it is that anybody will implement this is
> difficult to answer without time travel capability. However, if
> there's no standardised mechansm, I think chances are good that
> nobody will implement anything.

Um ... aren't you looking at it bass-ackwards? It doesn't matter if we 
develop a standard if it doesn't meet a real-world need. Communicating 
with the primary target audience for the thing we are developing would 
seem to be a good step in the process.

>>> 2. Because sometimes you want to publish DS RRs in your parent
>>> that correspond to standby keys that are not published in the
>>> child.
>>
>> If the parents are actually using some method of accepting signals
>> from the child to scrape the zone (whether CDS; actual scraping of
>> NS, DNSKEY, etc.; or some other method) wouldn't that lower the
>> barrier to entry for standby keys?
>

If I have confidence that as a result of whatever mechanism gets 
implemented that my parent is going to create a DS record for my new key 
in near real time, how important is it that I pre-publish standby keys?

Doug

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Mar 2013 13:02:30 -0400

On 2013-03-13, at 12:54, Doug Barton <[email-masked]> wrote:

> That makes the problem worse, right? As there are many more registrars than there are registry operators.

Depends what you think the problem is. I think it makes the problem better; you only need one registrar with a relationship with many registries to do this, and you have a one stop shop for all your domains that you want to manage this way.

> Um ... aren't you looking at it bass-ackwards? It doesn't matter if we develop a standard if it doesn't meet a real-world need. Communicating with the primary target audience for the thing we are developing would seem to be a good step in the process.

You weren't asking whether you thought there was a need; you were asking whether this particular mechanism would be implemented.

Anybody who has used existing tools to maintain even a modest portfolio of signed domains understands that there is a need, I think. What we have right now sucks.

> If I have confidence that as a result of whatever mechanism gets implemented that my parent is going to create a DS record for my new key in near real time, how important is it that I pre-publish standby keys?

It's important if you care about being able to retire compromised keys promptly and not have to wait the DS TTL for people to be able to see you again.

Also, I don't know how realistic "near real time" is, if you consider the problem of a parent operator having to poll 5,000,000 children for changes. "Some time today" would satisfy the need I see.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Mar 2013 13:05:11 -0400 (EDT)

On Wed, 13 Mar 2013, Doug Barton wrote:

> The language tends to be focused around registries not contacting registrants 
> directly. This sort of thing would likely be an exception to the rule, but 
> I'm not a lawyer either. :)
>
> It would be worth getting some clarity on this before moving forward though.

No it is not. That already killed the use-cases document. Let's not go
there again. Whatever we specify either can or cannot be used by certain
TLDs as dictated by their local policy. There is nothing for us to take
into consideration.

> develop a standard if it doesn't meet a real-world need. Communicating with 
> the primary target audience for the thing we are developing would seem to be 
> a good step in the process.

If a TLD contract does not allow registrant-registry contact directly,
then that prevents child-parent interaction, and so nothing we specify
here can be used. So this issue is fully out of scope for this document.

Send the lawyers home,

Paul

---

From: Doug Barton <[email-masked]>
Date: Wed, 13 Mar 2013 10:17:10 -0700

On 03/13/2013 10:02 AM, Joe Abley wrote:
>>> However, there's nothing to stop registrars making arrangements
>>> with their registrants to receive change requests via signed
>>> RRSets. It may that for gTLDs (and other TLDs in a similar
>>> sitaution), we don't need buy-in from lots of registries; we need
>>> buy in from a registrar.
>>
>> That makes the problem worse, right? As there are many more
>> registrars than there are registry operators.
>
> Depends what you think the problem is. I think it makes the problem
> better; you only need one registrar with a relationship with many
> registries to do this, and you have a one stop shop for all your
> domains that you want to manage this way.

Assuming that all of your domains are at registries that registrar has 
relationships with. In order to really make this work a non-trivial 
number of TLD registries (which have a variety of different rules and 
policies) AND registrars would have to be on board. Has anyone 
communicated with them about this topic? The ICANN forums for both 
groups would be a good place to start.

>>> The question of how likely it is that anybody will implement this
>>> is difficult to answer without time travel capability. However,
>>> if there's no standardised mechansm, I think chances are good
>>> that nobody will implement anything.
>>
>> Um ... aren't you looking at it bass-ackwards? It doesn't matter if
>> we develop a standard if it doesn't meet a real-world need.
>> Communicating with the primary target audience for the thing we are
>> developing would seem to be a good step in the process.
>
> You weren't asking whether you thought there was a need; you were
> asking whether this particular mechanism would be implemented.
>
> Anybody who has used existing tools to maintain even a modest
> portfolio of signed domains understands that there is a need, I
> think. What we have right now sucks.

You're defining "need" differently than I am. You're saying, "We need an 
automated mechanism to deal with DS records." I'm saying that unless the 
registries and registrars are on board with the mechanism we create, it 
doesn't matter how good it is, it isn't going to solve the real-world need.

Or put more simply, "Creating protocols in a vacuum is bad."

>>>>> 2. Because sometimes you want to publish DS RRs in your
>>>>> parent that correspond to standby keys that are not published
>>>>> in the child.
>>>>
>>>> If the parents are actually using some method of accepting
>>>> signals from the child to scrape the zone (whether CDS; actual
>>>> scraping of NS, DNSKEY, etc.; or some other method) wouldn't
>>>> that lower the barrier to entry for standby keys?
>>>
>> implemented that my parent is going to create a DS record for my
>> new key in near real time, how important is it that I pre-publish
>> standby keys?
>
> It's important if you care about being able to retire compromised
> keys promptly and not have to wait the DS TTL for people to be able
> to see you again.
>
> Also, I don't know how realistic "near real time" is, if you consider
> the problem of a parent operator having to poll 5,000,000 children
> for changes. "Some time today" would satisfy the need I see.

... which is why I agreed with the others that raised the idea of a 
special packet for the child to send to the parent to signal the need to 
scrape.

Doug

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Mar 2013 13:14:04 -0400

On 2013-03-13, at 13:05, Paul Wouters <[email-masked]> wrote:

> then that prevents child-parent interaction,

No, it just prevents direct child-parent interaction.

> and so nothing we specify
> here can be used.

There's nothing to stop a registrar from polling the zones it sponsors and sending EPP commands back to the registry if there are changes to make.

I agree that the topic at hand is a technical DNS issue, not a registry policy issue, and that if we run up against policy roadblocks we're probably doing it wrong.

Joe

---

From: Doug Barton <[email-masked]>
Date: Wed, 13 Mar 2013 10:22:43 -0700

On 03/13/2013 10:05 AM, Paul Wouters wrote:
>> registrants directly. This sort of thing would likely be an exception
>> to the rule, but I'm not a lawyer either. :)
>>

Errr ... your past bad experiences aside, let's take 2 possible 
theoretical scenarios.

1. There is nothing the TLD operators will accept in this space.

2. There is something that the TLD operators would gladly implement, but 
because we don't talk to them and find out what that is, the thing which 
we do end up creating gets ignored.

In both scenarios we've wasted our time. Of course there is some small 
utility for non-TLD parents, but that's in the margins.

I don't like wasting time, and I like even less giving the critics who 
say the IETF is out of touch and anachronistic more ammunition.

> here can be used. So this issue is fully out of scope for this document.

I didn't say raise the issue in the document. What I said was that we 
should understand the landscape before we try to build on it.

Doug

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Mar 2013 13:20:35 -0400

On 2013-03-13, at 13:17, Doug Barton <[email-masked]> wrote:

> In order to really make this work a non-trivial number of TLD registries (which have a variety of different rules and policies) AND registrars would have to be on board.

No. Where there are registrars involved, you just need a registrar that can handle your domain name to support it. The registry-registrar interactions can remain unchanged.

> Has anyone communicated with them about this topic? The ICANN forums for both groups would be a good place to start.

No doubt some of them have people here. But this is not an topic that deals with issues of registries and registrars; it's a DNS protocol issue. Changing the context to a policy one seems unlikely to result in additional light.

> You're defining "need" differently than I am. You're saying, "We need an automated mechanism to deal with DS records." I'm saying that unless the registries and registrars are on board with the mechanism we create, it doesn't matter how good it is, it isn't going to solve the real-world need.

I understand. I think you're wrong.

> ... which is why I agreed with the others that raised the idea of a special packet for the child to send to the parent to signal the need to scrape.

I think that's a non-starter.

Joe

---

From: Doug Barton <[email-masked]>
Date: Wed, 13 Mar 2013 10:34:13 -0700

On 03/13/2013 10:20 AM, Joe Abley wrote:
>> In order to really make this work a non-trivial number of TLD
>> registries (which have a variety of different rules and policies)
>> AND registrars would have to be on board.
>
> No. Where there are registrars involved, you just need a registrar
> that can handle your domain name to support it. The
> registry-registrar interactions can remain unchanged.

Sure, if you can accomplish getting the registrars that handle your 
domains on board then you've accomplished the goal for you. What about 
everyone else? Or do we only care about this problem to the extent that 
it affects certain TLDs?

>> Has anyone communicated with them about this topic? The ICANN
>> forums for both groups would be a good place to start.
>
> No doubt some of them have people here. But this is not an topic that
> deals with issues of registries and registrars; it's a DNS protocol
> issue. Changing the context to a policy one seems unlikely to result
> in additional light.

Why do you think I'm trying to turn it into a policy issue? I never even 
used the word policy. What I'm suggesting is that we talk to the people 
who may, or may not be willing to use this technique and find out what 
they think about it. You seem actively opposed to that, and I can't help 
but be curious about why.

>> You're defining "need" differently than I am. You're saying, "We
>> need an automated mechanism to deal with DS records." I'm saying
>> that unless the registries and registrars are on board with the
>> mechanism we create, it doesn't matter how good it is, it isn't
>> going to solve the real-world need.
>

Ok, show me why I'm wrong. How is this mechanism going to work for you 
if the registries and registrars don't implement it?

>>> Also, I don't know how realistic "near real time" is, if you
>>> consider the problem of a parent operator having to poll
>>> 5,000,000 children for changes. "Some time today" would satisfy
>>> the need I see.
>>
>> special packet for the child to send to the parent to signal the
>> need to scrape.
>

Why?

Doug

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Mar 2013 13:48:58 -0400 (EDT)

On Wed, 13 Mar 2013, Doug Barton wrote:

> Errr ... your past bad experiences aside, let's take 2 possible theoretical 
> scenarios.

(I just hit reply in alpine)

> 1. There is nothing the TLD operators will accept in this space.

In which case we don't need to consider them.

> because we don't talk to them and find out what that is, the thing which we 
> do end up creating gets ignored.

That makes it sound we can help them technically, when the problem
raised was political. Again, we tried that a year ago by just mentioning
that some of the technical solutions could intersect with politics and
everything ground to a halt.

> utility for non-TLD parents, but that's in the margins.

That's your opinion I strongly disagree with.

> I don't like wasting time, and I like even less giving the critics who say 
> the IETF is out of touch and anachronistic more ammunition.

And I don't like giving critics who say IETF works on standarising
yesterday's problems more ammunition.

> I didn't say raise the issue in the document. What I said was that we should 
> understand the landscape before we try to build on it.

We tried that. I did not get any feedback for

http://tools.ietf.org/html/draft-wouters-dnsop-secure-update-use-cases-00

other then "we will never do this, it violates our policy". And that was
just specifying the use cases, not even trying to state any technical
solution.

If the registry/registrar people want a specific solution that works for
them, they should see if this draft can be made to work for them, or
suggest improvements how this can work for them, or come up with
something else entirely. But let's not wait two years to fix the generic
parent-child secure update possibilities for others just because people
are knee deep in contractual law.

This draft only has to state that updating the parent records based on
the child records is subject to the local policy of the parent and its
representative. What else is there to say?

Paul

---

From: Alan Clegg <[email-masked]>
Date: Wed, 13 Mar 2013 21:13:51 +0300

Why is this argument so tied up in TLD operations when it is going to be so useful for all of the rest of us even if the TLDs don't use it?

It's NOT just for TLDs, it's for anyone that does secure delegations.

I know that there are lots of people that do secure delegations that would enjoy the ability to automate....

AlanC
-- 
Alan Clegg | +1-919-355-8851 | [email-masked]

---

From: Doug Barton <[email-masked]>
Date: Wed, 13 Mar 2013 11:20:06 -0700

> It's NOT just for TLDs, it's for anyone that does secure delegations.

... as I have acknowledged many times. :)

If we create a mechanism that TLD operators will use, it can also be 
used by other parents. If we create something that TLD operators will 
not use, it's utility will be extremely limited.

Doug

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Mar 2013 14:54:24 -0400 (EDT)

On Wed, 13 Mar 2013, Doug Barton wrote:

>> useful for all of the rest of us even if the TLDs don't use it?
>> 
> If we create a mechanism that TLD operators will use, it can also be used by 
> other parents. If we create something that TLD operators will not use, it's 
> utility will be extremely limited.

It's "inline signaling using signed DNS data". Regardless of the details of the
RRtype format, they will be able to see it, use it, or ignore it without
operational impact. It is the only method that satisfied all use-cases.

Which is why I think we do not need to reach out further/again to the
TLD people.

Paul

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Mar 2013 15:53:36 -0400

On 2013-03-13, at 13:34, Doug Barton <[email-masked]> wrote:

> Sure, if you can accomplish getting the registrars that handle your domains on board then you've accomplished the goal for you. What about everyone else? Or do we only care about this problem to the extent that it affects certain TLDs?

Doug, I don't understand your concern.

You insisted earlier that for gTLDs, we would need support by all TLD registries and all registrars. I said that's nonsense. Now I don't understand what your point is.

> Why do you think I'm trying to turn it into a policy issue?

Honestly, I have no idea why you're trying to do that. But by suggesting loudly that we need to build requirements from gTLD registrars and registries, that's indeed what you are doing. I'm actively opposed to that because I think it's unnecessary, and a distraction from the work at hand.

> Ok, show me why I'm wrong. How is this mechanism going to work for you if the registries and registrars don't implement it?

You said (earlier) we needed *all* registries and registrars to support it. I disagreed with that (there is non-zero utility in this scheme being implemented by just one registrar, or one registry that doesn't follow the RRR model). I disagree that registries that follow the RRR model need to be involved at all (the work can be done by registrars).

>> I think that's a non-starter.

I think it'd be a support nightmare, it can't work in cases where registries are not allowed to interact directly with registrants, and it's rife with DDoS potential.

Joe

---

From: Doug Barton <[email-masked]>
Date: Wed, 13 Mar 2013 13:27:37 -0700

On 03/13/2013 12:53 PM, Joe Abley wrote:
>>>> registries (which have a variety of different rules and
>>>> policies) AND registrars would have to be on board.
>>>
>>> No. Where there are registrars involved, you just need a
>>> registrar that can handle your domain name to support it. The
>> domains on board then you've accomplished the goal for you. What
>> about everyone else? Or do we only care about this problem to the
>> extent that it affects certain TLDs?
>
> You insisted earlier that for gTLDs, we would need support by all TLD
> registries and all registrars.

I did not say that.

> I said that's nonsense. Now I don't understand what your point is.

Perhaps because you're not reading my messages carefully? I'm not 
snarking here, you seem to be adding quite a bit of your own baggage to 
what I'm actually writing, and I think it's making it difficult for you 
to understand my meaning.

>>> No doubt some of them have people here. But this is not an topic
>>> that deals with issues of registries and registrars; it's a DNS
>>> protocol issue. Changing the context to a policy one seems
>>> unlikely to result in additional light.
>>
> Honestly, I have no idea why you're trying to do that.

I'm specifically not trying to do that. If that isn't clear to you, then 
you seriously don't understand what I've written at all.

> But by
> suggesting loudly that we need to build requirements from gTLD
> registrars and registries, that's indeed what you are doing. I'm
> actively opposed to that because I think it's unnecessary, and a
> distraction from the work at hand.

So you're not at all concerned about the scenario where we're going to 
create a really neat mechanism for handling this problem but it will 
never get deployed? In spite of the ample evidence of the IETF doing 
exactly that, over and over again? And, not only do you not think it's a 
good idea to talk to the people who may or may not implement this thing 
we create, you are actively opposed to doing so because it would be a 
distraction?

I'm flabbergasted ...

>>>> You're defining "need" differently than I am. You're saying,
>>>> "We need an automated mechanism to deal with DS records." I'm
>>>> saying that unless the registries and registrars are on board
>>>> with the mechanism we create, it doesn't matter how good it is,
>>>> it isn't going to solve the real-world need.
>>>
>> Ok, show me why I'm wrong. How is this mechanism going to work for
>> you if the registries and registrars don't implement it?
>
> You said (earlier) we needed *all* registries and registrars to
> support it. I disagreed with that (there is non-zero utility in this
> scheme being implemented by just one registrar, or one registry that
> doesn't follow the RRR model). I disagree that registries that follow
> the RRR model need to be involved at all (the work can be done by
> registrars).

And that will benefit those TLDs who use registrars, sure. What about 
the ones who allow registrants to deal with the registry directly? Or 
are you confirming that you're only interested in solving this for a 
subset of TLDs?

>>>>> 5,000,000 children for changes. "Some time today" would
>>>>> satisfy the need I see.
>>>>
>>>> ... which is why I agreed with the others that raised the idea
>>>> of a special packet for the child to send to the parent to
>>>> signal the need to scrape.
>>>
> I think it'd be a support nightmare, it can't work in cases where
> registries are not allowed to interact directly with registrants, and
> it's rife with DDoS potential.

I think the "support nightmare" would be overcome rather quickly by 
building the sending of this packet into the tools that do the work of 
zone maintenance. Users with enough experience to handle maintaining 
their zones by hand are also smart enough to handle sending the packet, 
so I don't agree with you here. But if I'm missing something please fill 
me in.

It's not at all clear that the prohibition against registrar-registry 
contact would apply to this case, and even if it did there are 
workarounds (such as a registry-registrar EPP channel that gets 
triggered when the registry receives the packet).

The DDOS argument I have sympathy with, but that's fairly easily managed 
with rate limits, and really isn't any worse than the many other DDOS 
vectors that already exist.

Doug

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Mar 2013 17:15:26 -0400

>> registries and all registrars.

You're right; you said "in order to really make this work a non-trivial number of TLD registries (which have a variety of different rules and policies) AND registrars would have to be on board." Which I think is wrong, as I mentioned.

Your opinion on this led you to think that policy groups should be consulted. I think that is unlikely to make our work here easier or better, as I mentioned.

> So you're not at all concerned about the scenario where we're going to create a really neat mechanism for handling this problem but it will never get deployed?

I have no idea where you got that from.

Joe