Subject: Re: [DNSOP] automatic update of DS records

From: [email-masked]
Date: Tue, 2 Mar 2010 04:02:11 +0000

granted that this discussion is important and folks
	interested in this might be at the IETF77, could we
	either have a bof (formal) or a small lunch mtg 
	during the week of IETF77?

	I'd be glad to attend.

--bill

On Fri, Feb 26, 2010 at 10:12:48AM +0100, Wolfgang Nagele wrote:
> Hi,
> 
> > What are the arguments against using somthing like RFC 5011 to
> > automatically update DS records? (If you can do that I suppose
> > you could update the rest of the delegation too.)
> There has been some work on a draft for this after an inofficial BoF during the
> Stockholm IETF. So far it did not make it to the light of day because of claimed
> intellectual property issues. Anybody interested can contact me for more details.
> 
> Regards,
> Wolfgang
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Wolfgang Nagele <[email-masked]>
Date: Tue, 02 Mar 2010 10:04:46 +0100

Hi,

> 	during the week of IETF77?
There has been interest in this at least since IETF75. Anyway, a BoF is a good
idea. I will not be in Anaheim since the DURZ roll-out for K is in that week.
However Matthijs (in CC) has done the heavy lifting on the current draft and is
going to be there and he agreed to attend the BoF.

Cheers,
Wolfgang

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 02 Mar 2010 10:43:24 +0100

> 	during the week of IETF77?
     ...

Note, it is way past the time to request a BOF so I geuss the only
option is something informal.

	jaap

---

From: Edward Lewis <[email-masked]>
Date: Tue, 2 Mar 2010 09:38:50 -0500

>option is something informal.

I'm on the verge of putting together a Bar BoF call on the IETF list. 
There have been two work items I wanted to cover - EPPbis and the 
issue of provisioning DS records.

Only in the last week did it sink into me that the problem is that we 
need a way to push DS records along the established registration path 
and not the DNS operations path.  What this means - for registries 
that operate DNS and have direct dealings with registrants, the DS 
can go from the registrant's designated DNS operator to the registry. 
For registries that deal exclusively with registrars, the 
registrant's DNS operator has to know how to get the DS to the 
registrar (who in turn will use some other protocol to reach the 
registry).

Unfortunately, I doubt that many registrars will be at the IETF. 
(Maybe they will be.)  This means we might not get the word out to 
those who should help shape the requirements for this.

My concern - if the IETF produces a solution for transferring DS 
records in-band to the DNS protocol we will repeat a mistake made in 
pushing EPP to Full Standard.  Pushing EPP to Full Standard is in 
itself a true accomplishment and there is no controversy, the process 
was followed faithfully.  The problem is, once it was Full Standard 
it was found to not be applicable to the general population that it 
was designed to serve.  The protocol works and is interoperable; the 
requirements didn't grow as the use cases grew.

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

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: "Antoin Verschuren" <[email-masked]>
Date: Tue, 2 Mar 2010 16:53:53 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Edward Lewis
> Subject: Re: [DNSOP] automatic update of DS records
> 

The path is usualy even more complicated.
I've identified this stream of contractual relationships in a registration process:

registry-registrar-reseller-registrant-dns_operator

(some roles may be duplicated or absent, some market players may perform 2 or more roles at once, but this is their contractual relationship)

> those who should help shape the requirements for this.

The question is whether we need to follow this administrative path.
Queries don't follow this administrative path.
DNSSEC validation doesn't follow this administrative path.

So why should DS_updates follow this administrative path ?

NS updates (technical information) -at this moment- only follow this administrative path because of a lack of a different secure channel.
If there was a secure channel between child and parent (like with DNSSEC), then none of the administrative channels would need to process NS updates or other technical updates.

The only thing where we still need the administrative channel is for:
- -administrative updates, ownership, contractual relations, everything not DNS.
- -Bootstrapping (the first NS and DS set sent to the registry)
- -Emergency error resolution

I believe that the administrative channel is not waiting to process NS, DS or other technical updates.
It does not bring them money, it costs them money, and there is a strict QOS to be met.
Some players in the administrative path (pure resellers, pure registrants) are not even capable or knowledgeable enough to process this technical information.
There is in fact more customers to be lost when you do it wrong, than can be gained by doing it right.
Automate it. Over DNS.

Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, 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: Edward Lewis <[email-masked]>
Date: Tue, 2 Mar 2010 11:33:28 -0500

>The question is whether we need to follow this administrative path.

"We" do for some value of $we.  If you are a registry, then you can 
develop one interface that all of your registrants have to use.  But 
if you are not a registry you will deal with bunch and commonality 
will be a good thing.

>So why should DS_updates follow this administrative path ?

The answer is apparent when the perspective is from the point of view 
of a DNS operator.  Some registries do not have an public interface 
to the process that populates the zone they manage.  For the same of 
interoperability in operations, there is a need to establish a common 
mechanism.

E.g., we (speaking in the voice of our commercial DNS hosting 
department) have to deal with names registered in COM and in other 
ccTLDs.  It would be nice to have a consistent interface amongst the 
registries.

And if we want to pull out the "what about the children" 
(http://en.wikipedia.org/wiki/For_the_children_(politics)) argument - 
the end customers get tied up having to get information from the DNS 
operator (or their DNS operations) at a regular interval and having 
to carry this to the registration system.  If they have a small cache 
of names and there is no general solution, they will have to remember 
how to update each name.

Ok, but why should DS updates follow an administrative path.  For 
traceability.  For logging.  For accountability.  For forensics.  For 
reasons that differentiate the activity of registration from the 
serving of DNS zones.  DNS does not maintain history, logging of 
registration does.

>NS updates (technical information) -at this moment- only follow this
>administrative path because of a lack of a different secure channel.

That is an incorrect characterization of the problem.  Currently 
updates to name servers and glue addresses follow the administrative 
channel because such information is easy to "cut'n'paste" and it is 
relatively static.  Customers of DNS operations are accustomed to 
being given a list of name servers and addresses which they carry to 
their registrar (if applicable) "portal".  The data, in format, is on 
par with administrative contacts, billing contacts, technical 
contacts, etc. (which have much higher security requirements IMHO 
than DS records).

>If there was a secure channel between child and parent (like with DNSSEC),
>then none of the administrative channels would need to process NS updates
>or other technical updates.

Security is not the main problem - basic transfer of the 
randomized-looking hash is the first step.  Security has to be 
built-in, but it's the tail of the dog here.

>Automate it. Over DNS.

I think it is very short-sighted to maintain this position.  This 
statement assumes that the registration body involved is running DNS. 
I've learned that not all registration entities do this.  One 
environment was described to me as "folks running a domain name 
selling point" (aka domain name reseller/retailer) with just a web 
page and a cell phone number.  A customer of this kind of entity may 
run their own DNS infrastructure and need to get DNSSEC keys to the 
TLD the name is registered under.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Alex Bligh <[email-masked]>
Date: Tue, 02 Mar 2010 19:17:48 +0000

Ed,

--On 2 March 2010 09:38:50 -0500 Edward Lewis <[email-masked]> wrote:

> need a way to push DS records along the established registration path and
> not the DNS operations path.  What this means - for registries that
> operate DNS and have direct dealings with registrants, the DS can go from
> the registrant's designated DNS operator to the registry. For registries
> that deal exclusively with registrars, the registrant's DNS operator has
> to know how to get the DS to the registrar (who in turn will use some
> other protocol to reach the registry).

I'm probably being very thick here, but could you explain why conceptually
this needs to be any different from the path taken to populate the NS
record and glue records (whether under DNSSEC or not)? Or are you only
suggesting this is the case where some sort of automatic pull is
in place?

-- 
Alex Bligh

---

From: Edward Lewis <[email-masked]>
Date: Tue, 2 Mar 2010 14:39:45 -0500

>suggesting this is the case where some sort of automatic pull is

Two reasons why the transfer is different although the path is the same:

1) Timing of the transfer.

1a First the DS record will be "in motion" much more frequently than 
an NS or address record would be.

1b Second the DS record will go "in motion" based on some time cycle 
and not all that event based.

2) The difficulty factor.

Telling someone one to change the name server from "ns1.example.tld." 
to "newdns.example." or "127.0.10.2 to 192.0.2.3" is easier than 
saying change something from:
"94DC01F2763CCB12F4B66AC63910830BC34082F6FE95CD75DAA3C5B37F99DD81"
to:
"6CDE2DE97F1D07B23134440F19682E7519ADDAE180E20B1B1EC52E7F58B2831D"

To explain 1a further - in today's environment, simple sites will be 
set up and left alone.  With DNSSEC, keys are expected to be changed 
more frequently.  Granted give some recent talk, maybe not all that 
more often.

As far as 1b - the transfer of the DS might be "because it is March 
1st" or "because we suspect bad activity."  Before the NS's really 
changed when "I've had it with that DNS provider, that was the last 
time!"

Now, really, if the *path* from org to org is the same as NS and 
glue, that would be good.  It's just that we can't see the consumer 
wanting to handle the ugly data (part 2).  Yes, we want security, 
but, we also want the same security as the NS and glue data - they 
are more important (and already have been shown to be more 
vulnerable, see SQL injection attack : 
http://en.wikipedia.org/wiki/SQL_injection_attack.)

---

From: Jay Daley <[email-masked]>
Date: Wed, 3 Mar 2010 08:51:36 +1300

On 3/03/2010, at 8:39 AM, Edward Lewis wrote:

> 1a First the DS record will be "in motion" much more frequently than an NS or address record would be.
> 
> 1b Second the DS record will go "in motion" based on some time cycle and not all that event based.

That I agree with.

> Telling someone one to change the name server from "ns1.example.tld." to "newdns.example." or "127.0.10.2 to 192.0.2.3" is easier than saying change something from:

That I don't.  Currently the registrant's DNS provider tells them "cut and paste this blob from here into the field marked 'nameservers' in your registrar's interface" and to that they will add "cut and paste this blob from here into the field marked 'DS record' in your registrar's interface.  No danger of the registrant needing to understand what they are doing.

regards
Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: Jay Daley <[email-masked]>
Date: Wed, 3 Mar 2010 08:52:57 +1300

On 3/03/2010, at 3:38 AM, Edward Lewis wrote:

> Only in the last week did it sink into me that the problem is that we need a way to push DS records along the established registration path and not the DNS operations path.  

Did you mean to exclude the DNS path for those that choose it?  Isn't it is a registry/DNS parent policy decision.

Jay

> What this means - for registries that operate DNS and have direct dealings with registrants, the DS can go from the registrant's designated DNS operator to the registry. For registries that deal exclusively with registrars, the registrant's DNS operator has to know how to get the DS to the registrar (who in turn will use some other protocol to reach the registry).
> 
> Unfortunately, I doubt that many registrars will be at the IETF. (Maybe they will be.)  This means we might not get the word out to those who should help shape the requirements for this.
> 
> My concern - if the IETF produces a solution for transferring DS records in-band to the DNS protocol we will repeat a mistake made in pushing EPP to Full Standard.  Pushing EPP to Full Standard is in itself a true accomplishment and there is no controversy, the process was followed faithfully.  The problem is, once it was Full Standard it was found to not be applicable to the general population that it was designed to serve.  The protocol works and is interoperable; the requirements didn't grow as the use cases grew.
> 
> --

---

From: Tony Finch <[email-masked]>
Date: Tue, 2 Mar 2010 19:57:58 +0000

On Wed, 3 Mar 2010, Jay Daley wrote:
>
> That I don't.  Currently the registrant's DNS provider tells them "cut
> and paste this blob from here into the field marked 'nameservers' in
> your registrar's interface" and to that they will add "cut and paste
> this blob from here into the field marked 'DS record' in your
> registrar's interface.  No danger of the registrant needing to
> understand what they are doing.

Even if the update cannot be automatically pushed from the DNS provider to
the registrar, it ought to be possible to just tell the registrar to fetch
the domain's new delegation records without any error-prone copy and
paste.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 02 Mar 2010 14:58:34 -0500

On 3/2/10 9:38 AM, Edward Lewis wrote:
> There have been two work items I wanted to cover - EPPbis and the issue
> of provisioning DS records.

I'm quite interested in the EPPbis area, and the DS provisioning
problem, but I'm spending my wicked limited travel time until mid-May
(my partner's a 1L at Cornell Law) on a CORE technical meeting.

I'll be happy to v-bar-bof from in front of a German beer, 9 timezones
distant.

> and not the DNS operations path.  What this means - for registries that
> operate DNS and have direct dealings with registrants, the DS can go
> from the registrant's designated DNS operator to the registry. For
> registries that deal exclusively with registrars, the registrant's DNS
> operator has to know how to get the DS to the registrar (who in turn
> will use some other protocol to reach the registry).
> 
> Unfortunately, I doubt that many registrars will be at the IETF. (Maybe
> they will be.)  This means we might not get the word out to those who
> should help shape the requirements for this.

There will be some meeting of registrars (ICANN accredited that is) a
week from today, and there is the RSG mailing list too.

> My concern - if the IETF produces a solution for transferring DS records
> in-band to the DNS protocol we will repeat a mistake made in pushing EPP
> to Full Standard.  Pushing EPP to Full Standard is in itself a true
> accomplishment and there is no controversy, the process was followed
> faithfully.  The problem is, once it was Full Standard it was found to
> not be applicable to the general population that it was designed to
> serve.  The protocol works and is interoperable; the requirements didn't
> grow as the use cases grew.
> 

+1

Eric

---

From: Alex Bligh <[email-masked]>
Date: Tue, 02 Mar 2010 20:05:38 +0000

Ed,

--On 2 March 2010 14:39:45 -0500 Edward Lewis <[email-masked]> wrote:

> Telling someone one to change the name server from "ns1.example.tld." to
> "newdns.example." or "127.0.10.2 to 192.0.2.3" is easier than saying
> change something from:

So, if the registrar is running DNS, then he pushes the DS keys directly
using EPP or whatever. And the problem arises, if I understand it right,
when someone other than the registrar (or for that matter the registry) is
generating the information that goes in the DS record. And whilst
nameservers (for instance) are likely to be static, this is relatively
volatile.

My concern is that whatever automatic update mechanism you choose has
to use some greater level of security than merely relying on the
zone being signed. So to pick a trivial example
 _DSKEY IN TXT [blob]
isn't going work, because if you are changing the DS key because
you fear your keys may have been compromised, that can be compromised
too. I may be having a failure of imagination but I don't immediately
see how without some external authentication (yet another key) you
can securely automatedly push DS key changes about.

-- 
Alex Bligh

---

From: Edward Lewis <[email-masked]>
Date: Tue, 2 Mar 2010 15:43:15 -0500

An omnibus reply.

>a registry/DNS parent policy decision.

At one level of description, yes, at another, no.  If the underlying 
mechanism for the interface uses a DNS query to get the data, that's 
fine.  The caveats of "is it secure" "is it logged" etc. apply.

>the domain's new delegation records without any error-prone copy and

We (as DNS operator) really would ideally not even bother the 
registrant with this at all, much less even risk them having to cut 
and paste.

One could imagine that the customer opens their account with a credit 
card and supplies a DNS operator in the contact field and some sort 
of automated secret generation happens and from then on the DNS 
queries are TSIG protected - thinking wildly here.

At 20:05 +0000 3/2/10, Alex Bligh wrote:
>zone being signed.

Certainly.

>I'll be happy to v-bar-bof from in front of a German beer, 9 timezones

A bar BOF is like a "beta", not even a "release candidate", ... I'm 
sure there will be more discussions - oh wait, you know a lawyer. 
I'll need you to sign a waiver. ;)

>week from today, and there is the RSG mailing list too.

I won't be there, but I am hoping someone there will carry the 
message.  (Haven't heard an ack from that volunteer yet though.)

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 02 Mar 2010 17:11:32 -0500

On 3/2/10 3:43 PM, Edward Lewis wrote:
> A bar BOF is like a "beta", not even a "release candidate", ... I'm sure
> there will be more discussions - oh wait, you know a lawyer. I'll need
> you to sign a waiver. ;)

I know several. My partner is merely a law student however. What would
you like waived? Serviceability of the bar???

> I won't be there, but I am hoping someone there will carry the message. 
> (Haven't heard an ack from that volunteer yet though.)

I've not gotten notice, anti-competition laws don't apply outside of
the Beltway, so I can't possibly carry the message.

Eric

---

From: [email-masked]
Date: Wed, 3 Mar 2010 00:30:05 +0000

> going to be there and he agreed to attend the BoF.

	long before IETf75... :) looks like a BOF is out of the question
	(too late) .. will have to be informal.  and good luck w/ the DURZ

--bill

---

From: [email-masked]
Date: Wed, 3 Mar 2010 00:36:12 +0000

> That I don't.  Currently the registrant's DNS provider tells them "cut and paste this blob from here into the field marked 'nameservers' in your registrar's interface" and to that they will add "cu…

	there is a problem w/ cut/paste ... surely we could do better than that?

==bill

---

From: Jay Daley <[email-masked]>
Date: Wed, 3 Mar 2010 13:40:53 +1300

> 	there is a problem w/ cut/paste ... surely we could do better than that?

I'm sure we could and an automated update of DS records is a good idea.  But my point is that in the absence of a similar automated mechanism for NS records we use cut and paste and it works fine and there is nothing about DS records that is any more complicated so cut and paste would work fine there too.

Jay

---

From: [email-masked]
Date: Wed, 3 Mar 2010 00:42:42 +0000

> can securely automatedly push DS key changes about.

	hum... maybe I should be hounding Ed on this... but I think we should
	draw a bright line...  we are (imho) talking about pushing DS records
	from child to parent.  entirely w/in the perview of the DNS protocol/wg.

	for non-DNSprotocol players (registries/registrars/registrants) that use
	EPP or its varients for pushing DNS data around - thats not w/in scope.
	at least for this WG's consideration.

--bill

---

From: [email-masked]
Date: Wed, 3 Mar 2010 00:49:28 +0000

> I'm sure we could and an automated update of DS records is a good idea.  But my point is that in the absence of a similar automated mechanism for NS records we use cut and paste and it works fine a…

	the trick there is that an NS update is somewhat humanly parsable.  if a cut/paste
	cocks up, its fairly easy to tell.  in my limited experience, DS records are not
	quite as humanly parsable and a cut/paste error is more likely to slip through.

--bill

---

From: Mark Andrews <[email-masked]>
Date: Wed, 03 Mar 2010 12:34:12 +1100

> 	at least for this WG's consideration.

I recommend something that is UPDATE + TSIG like.  The child's key manager
component can send the updates.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 2 Mar 2010 20:55:50 -0500

At 0:42 +0000 3/3/10, [email-masked] wrote:
>	for non-DNSprotocol players 
>(registries/registrars/registrants) that use

If you want to just get the DS from the child's servers to the 
parent's machines, we already have queries/responses and can secure 
that with TSIG or SIG(0).  What is there to solve?

There's certainly a larger problem to solve though - and yes it's not 
in the charter of this group.

>component can send the updates.

With the concern about keeping key management separate from the 
Internet, opening up the master server for across-the-'net dynamic 
update to insert a DS record seems a bit counter-productive.  This 
certainly wouldn't fly for "large" TLDs, it might be applicable for 
informal environments.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 02 Mar 2010 21:56:31 -0500

> I'm sure we could and an automated update of DS records is a good idea.  But my point is that in the absence of a similar automated mechanism for NS records we use cut and paste and it works fine a…

Jay,
EPP is one way an a necesary way to set up the domain the first time,
as for subsequent updates, I can imangine parent copying data from
child when the child is signed, no more cut and paste just DNS queries.
Just rolling keys in 10+ zones and going to through the web interaces is
time consuming and error prone.

Ed, count me in for the BOF.

	Olafur

---

From: Mark Andrews <[email-masked]>
Date: Wed, 03 Mar 2010 14:26:49 +1100

> certainly wouldn't fly for "large" TLDs, it might be applicable for 

Hence "like".

Today, with UPDATE we support forwarding of the request to another
box for processing.  There is no reason that this could not happen
for this process.

It would be nice if the UPDATE code could handle these requests but
not required.

Mark

---

From: Doug Barton <[email-masked]>
Date: Tue, 02 Mar 2010 20:15:50 -0800

> An omnibus reply.

A mini bus reply. :)

I've read through this thread and I generally agree with Ed's analysis.

Throwing in some more bullet points:
1. There MUST be an OOB (where the B is DNS) channel for initial zone
configuration, contact info changes, etc.
2. This channel already exists for Registrant/Admin/Billing/Technical
contact info, name servers, etc.
3. The existing elements of the channel that Antoin identified are all
familiar, and relatively comfortable with this channel, and get way more
stuff that flows through it right than they get wrong.
4. It's pretty easy to make the argument that DS records fit nicely into
that channel "like" NS records.
5. The very large number of misconfigured name servers out there now
argue strongly against considering DNS a "secure" channel.
6. There has to be an OOB mechanism for domain holders to enter DS key
data in any case to deal with emergencies, restarts, etc.

In my mind all of these points argue strongly against putting work into
this, even if the RRR channel was likely to adopt it, which I am
extremely skeptical about.

hth,

Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

---

From: Alex Bligh <[email-masked]>
Date: Wed, 03 Mar 2010 07:46:54 +0000

Jay,

--On 3 March 2010 13:40:53 +1300 Jay Daley <[email-masked]> wrote:

> I'm sure we could and an automated update of DS records is a good idea.
> But my point is that in the absence of a similar automated mechanism for
> NS records we use cut and paste and it works fine and there is nothing
> about DS records that is any more complicated so cut and paste would work
> fine there too.

I thought that yesterday. Ed convinced me otherwise. I think I have
about 20 or 30 domains registered (meaning I look after the registrar
interaction and the DNS for them) with variety of registrars. I don't
think the NS entries for any of them have changed in the past ten
years, and they are all either pair {a,b} or pair {c,d}. If they
had DS records, this would not apply.

Moreover, I suspect for the vast majority of zones, some third party
DNS service is going to be signing the zones and producing the DS
records. Unless there is an automated mechanism to move DNS, we
going to make it difficult for any third part authoritative DNS
service to exist unless they are also the registry operator.

My non-bar-based straw-man contribution is this (perhaps using a proper
record rather than TXT)
	_DSKEY	IN	TXT	"[DSKEY]:[HASH]"
where [HASH] is a truncated hash of the DS key and a secret shared
(once) between registrar/y and the registrant/DNS operator. Obviously
the record needs to then pass the normal signing checks too. If it
doesn't check out, the previous DS key stays.

-- 
Alex Bligh

---

From: Tony Finch <[email-masked]>
Date: Wed, 3 Mar 2010 14:24:42 +0000

On Wed, 3 Mar 2010, Jay Daley wrote:
> NS records we use cut and paste and it works fine

No it doesn't. Delegations are frequently partially broken. It would be
a wasted opportunity to automate DS maintenance without automating NS
maintenance. Reducing the inconsistency problem would be an ENORMOUS
improvement.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Wed, 3 Mar 2010 14:30:05 +0000

On Tue, 2 Mar 2010, Edward Lewis wrote:
>
> If you want to just get the DS from the child's servers to the parent's
> machines, we already have queries/responses and can secure that with TSIG or
> SIG(0).  What is there to solve?

What are the traps and pitfalls? What are the timing requirements?

There should be a specification along the lines of RFC 5011 that describes
how a parent can automatically update a delegation's DS, NS and glue RRs.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Wed, 3 Mar 2010 14:39:38 +0000

> data in any case to deal with emergencies, restarts, etc.

I think I agree with everything except point 5. The aim of automating this
is to reduce misconfiguration. You are arguing that delegations are
frequently a bit broken, so there's no point doing anything to reduce the
breakage. But we know DNSSEC makes breakage more likely (because of key
rollovers) and can turn minor breakage into serious breakage.

> extremely skeptical about.

It would be very helpful to be able to do automatic delegation updates
in lower levels of the DNS tree.

Tony.

---

From: jad <[email-masked]>
Date: Wed, 3 Mar 2010 16:11:34 +0000

> maintenance. Reducing the inconsistency problem would be an ENORMOUS

You excluded the previous line from Jay's email "I'm sure we could and  
an automated update of DS records is a good idea."

I agree an automated mechanism is a good idea (although I am not sure  
it will scale well to large zones). However, all registrants must  
already have some secure way to get their NS to the parent. There is  
no reason, as far as I can see, that with minimal work the same  
mechanism could not be altered to cope with DS records.

John

---
John Dickinson

Sinodun Internet Technologies Ltd.
Stables 4, Suite 11
Howbery Park,
Wallingford,
Oxfordshire,
OX10 8BA,
U.K.

---

From: Jay Daley <[email-masked]>
Date: Thu, 4 Mar 2010 08:32:18 +1300

Hi Alex

> had DS records, this would not apply.

Ed gave two reasons - one was timing and the other was difficulty.  I agreed with timing, which is the implicit issue in your para above, but not with difficulty.  Timing is a sufficient reason alone for this work but I would suggest that difficulty is a red-herring.  

> service to exist unless they are also the registry operator.

In your example above I personally would only use one set of keys for all those domains, it would make my life so much easier.  I suspect some DNS providers will similarly share keys across their customers (or per server) if they know they can control generation of RRs.

To be clear though, I agree entirely with an automated mechanism to move DS records, I just would not want "difficulty of cut and paste" to appear as a justification when it is both spurious and unnecessary.  Timing issues are more than sufficient justification.

cheers
Jay

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Wed, 3 Mar 2010 12:27:44 -0700

> In your example above I personally would only use one set of keys for
all
> those domains, it would make my life so much easier.  I suspect some
DNS
> providers will similarly share keys across their customers (or per
server)
> if they know they can control generation of RRs.

Bad idea, what happens when one customer would like to move his domain
from your name server to another name server. Do you give him your
mega-key or do you tell him to break his chain of trust during the move?

/S
----------------------------------------------------------------------
Stephan Lagerholm
Senior DNS Architect, M.Sc. ,CISSP
Secure64 Software Corporation, www.secure64.com
Cell: 469-834-3940

---

From: Jay Daley <[email-masked]>
Date: Thu, 4 Mar 2010 08:53:47 +1300

> mega-key or do you tell him to break his chain of trust during the move?

If those were the only two choices then that would be a disaster.  Luckily we have choice 3 - sign and publish his new keys to enable rollover

*Any* move from one DNS provider to another, where the DNS provider controls the key, means one of these three things:
1.  DNS provider supplies they key
2.  DNS provider cooperates in key rollover
3.  break in chain of trust

2 is just as easy to automate as anything else.

cheers
Jay

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Wed, 3 Mar 2010 12:50:31 -0700

> From: Jay Daley [mailto:[email-masked]]
> Sent: Wednesday, March 03, 2010 1:54 PM
> To: Stephan Lagerholm
> Cc: Alex Bligh; Jaap Akkerhuis; [email-masked];
> [email-masked]; Edward Lewis; Wolfgang Nagele;
> [email-masked]
> If those were the only two choices then that would be a disaster.
Luckily
> we have choice 3 - sign and publish his new keys to enable rollover
> 

Correct, but I have a hard time seeing that the loosing registrar would
be that helpful. It is more realistic to think that they could provide
access to the private key for their hosted customer. And in that case
the key can not be shared among customers.

/S

---

From: Jay Daley <[email-masked]>
Date: Thu, 4 Mar 2010 09:11:34 +1300

> the key can not be shared among customers.

On what basis do you think they would be unwilling to enable a rollover but willing to divulge a private key?

Consider the tradeoff a DNS provider might make:

Option 1.
- a set of keys per customer to manage (scale issues)
- divulge private key
- can immediately shutdown zone on transfer away (though that too causes problems)

Option 2.
- only one set of keys across per signing infrastructure (probably per server)
- automated key rollover
- must maintain zone for a period after transfer to ensure continuity

I know which one seems like less work to me.

cheers
Jay

---

From: John Dickinson <[email-masked]>
Date: Wed, 3 Mar 2010 20:13:53 +0000

> the key can not be shared among customers.

I agree the loosing registrar is unlikely to be much help. However,  
that is something that the registrant needs to know when selecting  
their registrar. Maybe some documentation providing advice to  
registrants would be useful? I am not sure at what level this would  
work. I suspect TLD operators might be best positioned to write this  
kind of advice for registrants using their TLD.

John Dickinson

c/o HR Wallingford,
Howbery Park,
Wallingford,
Oxfordshire,
OX10 8BA,
U.K.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 04 Mar 2010 08:00:25 +1100

> the key can not be shared among customers.

Actually it is totally unrealistic that the private key can be made
available.  Often it will be in hardware and there will be no way
they can get to it even if they wanted to share it.

All that they need to do is to add the public keys from the gaining
operator to the DNSKEY RRset and sign it.  The DS for the new KSKs
also need to be published.

---

From: [email-masked]
Date: Thu, 4 Mar 2010 04:30:10 +0000

> issue of provisioning DS records.

	re: registries not at the IETF...  if there is some general idea
	    for collecting registry requirements ... many will be in/around
	    the ICANN mtg next week.  I'll be there - if there is any benefit
	    to be gained by shooting a warning shot across their collective bow?

	https://datatracker.ietf.org/meeting/77/agenda.html  suggests 
	times that maybe better than others...

	I'd like to suggest monday - 1500-1700

--bill

---

From: Edward Lewis <[email-masked]>
Date: Thu, 4 Mar 2010 08:11:13 -0500

>	I'd like to suggest monday - 1500-1700

We can talk then, but the wheels were in motion to put it on 
Wednesday.  The reason for that was the crowd coming for the Escrow 
BoF has a good grip on the requirements (which is needed before 
figuring out the mechanism).

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 04 Mar 2010 10:51:56 -0500

> (Haven't heard an ack from that volunteer yet though.)

OK. Now I can volunteer for that.

---

From: [email-masked]
Date: Thu, 4 Mar 2010 16:36:32 +0000

> figuring out the mechanism).

	great! i suspect that both slots would be productive.

--bill

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Thu, 4 Mar 2010 14:05:27 -0700

Some folks did some work during IETF in Stockholm around the Auto-DS
question and there is an early document available here:
http://docs.google.com/Doc?docid=0AW-P61yxNNIAZHZjNXhzeF8xZjdwZzk2Y3g&hl
=en

The document is far from ready but it tried to cover some of the
discussions floating around here (registry-registrar-registrant issues,
notify mechanism, etc).

This could perhaps be useful as input for the BoF.

/Stephan

---

From: Doug Barton <[email-masked]>
Date: Thu, 04 Mar 2010 15:16:29 -0800

> the key can not be shared among customers.

The losing registrar is either going to be helpful, or unhelpful. Given 
that adding ANY kind of mechanism to enable secure transition of the 
domain is extra work without any direct benefit, the answer is 
overwhelmingly likely to be "unhelpful." At least in the case of the 
gTLD registrars this is an area where ICANN intervention is likely to be 
required, and may actually be beneficial.

Doug

--

---

From: Doug Barton <[email-masked]>
Date: Thu, 04 Mar 2010 15:23:01 -0800

> rollovers) and can turn minor breakage into serious breakage.

Actually I had a lot more than bad delegations in mind when I wrote 
"misconfigured" above, but I dialed back quite a bit. To speak more 
plainly, a very large percentage of people who do DNS at the moment do 
it badly. I agree with your point that DNSSEC is going to increase both 
the complexity and the impact of misconfigurations, which is why I am 
leaning in the direction of thinking that adding more bullets to the 
foot-shooting gun is probably not the right way to go.

> in lower levels of the DNS tree.

I'm not 100% dead set against the idea, just mostly thinking it's not a 
good avenue to pursue. It would be easier to judge if we had a more 
concrete proposal to chew on.

Doug

--

---

From: Alex Bligh <[email-masked]>
Date: Thu, 04 Mar 2010 23:33:27 +0000

--On 4 March 2010 15:16:29 -0800 Doug Barton <[email-masked]> wrote:

> overwhelmingly likely to be "unhelpful." At least in the case of the gTLD
> registrars this is an area where ICANN intervention is likely to be

Partly depends on thick vs. thin registry model though.

-- 
Alex Bligh

---

From: Doug Barton <[email-masked]>
Date: Thu, 04 Mar 2010 15:42:40 -0800

On 3/4/2010 3:33 PM, Alex Bligh wrote:
>
>
> --On 4 March 2010 15:16:29 -0800 Doug Barton<[email-masked]>  wrote:
>

Sorry for being dense, but I don't see how.

Doug

--

---

From: Alex Bligh <[email-masked]>
Date: Thu, 04 Mar 2010 23:52:25 +0000

> Sorry for being dense, but I don't see how.

In a thick registry model, it would be possible for the registrant
to specify a DS key that the registry (rather than registrar) would
store, just like NS records are specified. So if the registrar changes,
there is no registrar involvement re DS keys unless they are deliberately
obnoxious.

-- 
Alex Bligh

---

From: David Blacka <[email-masked]>
Date: Thu, 4 Mar 2010 19:04:22 -0500

> there is no registrar involvement re DS keys unless they are deliberately

Any registry has to store the DS record, since they have to publish it in the DNS.  I don't really see how this is different in thick vs. thin registries.

--
David Blacka                          <[email-masked]> 
Sr. Engineer          VeriSign Platform Product Development

---

From: Alex Bligh <[email-masked]>
Date: Fri, 05 Mar 2010 00:31:56 +0000

--On 4 March 2010 19:04:22 -0500 David Blacka <[email-masked]> wrote:

> Any registry has to store the DS record, since they have to publish it in
> the DNS.  I don't really see how this is different in thick vs. thin
> registries.

May be it's not a thick vs. thin distinction per se, but a "what happens
if registrant falls out with registrar" distinction. Thick registries
that have a direct contract with the registrant (e.g. Nominet) tend tob
be rather less willing to let a losing registrar intermeddle. May be
this is isomorphic to the beneficial ICANN involvement suggested.

-- 
Alex Bligh

---

From: Mark Andrews <[email-masked]>
Date: Fri, 05 Mar 2010 14:25:49 +1100

> there is no registrar involvement re DS keys unless they are deliberately

Thick or thin the DS is stored along with the NS.  This really isn't
a registrar problem.  It's a DNS operator problem.

Mark

---

From: Doug Barton <[email-masked]>
Date: Thu, 04 Mar 2010 19:53:52 -0800

> this is isomorphic to the beneficial ICANN involvement suggested.

You're undoubtedly aware of this but in RRR parlance "thick" means that 
the registry stores all of the registrant data, and in a "thin" registry 
they store a subset (generally a very limited one) and a referral to the 
registrar. The two terms have no reference to the nature of the 
relationship between the registrant and the registry.

In the gTLD world the registrars jealously guard their relationships 
with their customers (the registrants), and registries are not allowed 
to have direct contact with them. This situation is unlikely to change 
in any material way which is why I suggested ICANN involvement may be 
necessary if there is agreement that conscious acts on the part of the 
losing registrar will be required for the smooth transition of a secure 
zone.

hth,

Doug

--

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 04 Mar 2010 23:03:24 -0500

> losing registrar will be required for the smooth transition of a secure

<multiple hats, but in particular, registrar hat == on>

I suggest that some registrars will be collaborative, and the recourse
to ICANN's registrar compliance staff is not the first alternative to
seek.

Eric

---

From: Doug Barton <[email-masked]>
Date: Thu, 04 Mar 2010 20:08:49 -0800

> to ICANN's registrar compliance staff is not the first alternative to

Well your first statement is a truism, and I am not suggesting that 
getting ICANN involved is "the first alternative." In fact, I was 
careful both times to say "may" as I wish that we lived in a perfect 
world and that everyone acted in a manner that is best for the users. 
However, my previous experiences in this area tell me that in the 
universe of hundreds of registrars a non-trivial number of them are what 
is euphemistically referred to as "bad actors," and need an incentive 
stronger than "it's the right thing to do" in order to be convinced to 
actually DO what's right.

Doug

--

---

From: Alex Bligh <[email-masked]>
Date: Fri, 05 Mar 2010 07:03:28 +0000

--On 4 March 2010 19:53:52 -0800 Doug Barton <[email-masked]> wrote:

> In the gTLD world the registrars jealously guard their relationships with
> their customers (the registrants), and registries are not allowed to have
> direct contact with them. This situation is unlikely to change in any
> material way which is why I suggested ICANN involvement may be necessary
> if there is agreement that conscious acts on the part of the losing
> registrar will be required for the smooth transition of a secure zone.

Sure. And I don't want to expand a one-liner into more than it is
worth, nor start a discussion on the merits of various registry
models. All I was saying was that in a thin model, as the registry
has no direct contact with registrants, and as the canonical
source of zone data is in essence the registrar (that's
who the registrant gives his NS and DS records to), the DS (and, for
that matter the NS) records have more change to "get lost" when
moving between registrars than in a thick registry. As you point
out that means that ICANN involvement may be necessary/desirable
to fix that, and all I was saying was there may be less need for such
involvement in a thick registry model.

-- 
Alex Bligh

---

From: Edward Lewis <[email-masked]>
Date: Fri, 5 Mar 2010 09:32:43 -0500

At 15:23 -0800 3/4/10, Doug Barton wrote:

>I agree with your point that DNSSEC is going to increase both the complexity
>and the impact of misconfigurations, which is why I am leaning in the
>direction of thinking that adding more bullets to the foot-shooting gun is
>probably not the right way to go.

I think one point above has been understated in most discussions - 
the impact of a DNSSEC slip up is an outage and the unwitting victim 
will be the internet-service provider (ISP or otherwise) "help-desk." 
The stakes are a bit higher and the downside falls on the wrong 
people.

>I'm not 100% dead set against the idea, just mostly thinking it's not a good
>avenue to pursue. It would be easier to judge if we had a more concrete
>proposal to chew on.

I've been thinking about this and the bar BOF announced earlier.  I 
said before, there really might be two problems here.  I don't want 
to seem dismissive of some effort to automate DS updates in-line with 
the DNS protocol but such a mechanism would not solve the problem in 
registration.

The reason for the informal BOF (note - not even an IETF sanctioned 
BOF) is to first draw out the goals and requirements.  I'm really not 
interested in seeing a concrete proposal at this point.  The reason 
for that is the lesson from EPP - although the IETF could build it, 
it resulted in something that could have been much more.

EPP is by no means a failure, so I don't want to draw too strongly 
from that example.  There have been other protocols, like for 
instance IRIS, which seemed like good ideas and sound engineering 
went into them, but they fell flat on the ground because the real 
demand wasn't there.  What I am warning against here is thinking that 
"it would be cool to just shove a bit here, a flag there, a TSIG over 
that part" and think that we've come up with a mechanism that works. 
This wouldn't be used by the registration environment, even if it 
manages to have multiple implementations, etc., and rises to Draft 
and Full Standard.  If that happens the IETF may have "succeeded" in 
producing something to "solve" DS consistency, but the registration 
community would still be looking for something useful and we all 
would be back at the start of the process.

So, as far as non-registration activity, does anyone have a firm grip 
on what is required for automatic DS updates?  It would be good to 
have a scoping use case (or set of cases) so that the registry folks 
don't keep coming with fire hoses and saying "this won't work for us."
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Tony Finch <[email-masked]>
Date: Fri, 5 Mar 2010 16:57:33 +0000

> http://docs.google.com/Doc?docid=0AW-P61yxNNIAZHZjNXhzeF8xZjdwZzk2Y3g&hl

A small question about the QNAME in the NOTIFY message. The draft says it
should be the server's host name, but that doesn't make sense to me: the
server already knows its name, but it doesn't know which domain's
delegation is to be updated. Should the QNAME be the latter?

Regarding timing and security considerations. The draft has some
discussion about timing requirements for the sender of the NOTIFY, but it
also envisages that anyone is able to send these NOTIFY requests. That
implies that if there are timing constraints they MUST be enforced by the
parent domain, otherwise attackers would be able to screw up a delegation
by forcing a change too soon. So I think a better approach to specifying
this functionality would be to minimise the requirements that are imposed
on the sender, and explain carefully the validity and timing checks that
the recipient must perform.

Tony.

---

From: Doug Barton <[email-masked]>
Date: Fri, 05 Mar 2010 12:33:58 -0800

On 3/4/2010 11:03 PM, Alex Bligh wrote:
> has no direct contact with registrants, and as the canonical source
> of zone data is in essence the registrar (that's who the registrant
> gives his NS and DS records to), the DS (and, for that matter the NS)
> records have more change to "get lost" when moving between registrars
> than in a thick registry.

I don't want to belabor the point either, the problem (and I apologize 
if I haven't been clear) is that just about everything you wrote in that 
paragraph is wrong, and I think it's really important that the members 
of the WG have the correct information so that they can make informed 
choices about proposals in this area.

1. The canonical source of information about NS records is ALWAYS the 
registry. Whether the data passes through a registrar on its way from 
the registrant to the registry or not. (Whether or not the registrar is 
the canonical source of information about the registrant is a can of 
worms I don't want to open here.)

2. Thick vs. thin is simply a description of where the data is stored 
(and in an ancillary way how whois lookups work), it has no predictive 
value for whether or not the registrant has a direct relationship with 
the registry or not. There are thick registries who use registrars in 
both the g and cc TLD worlds.

> As you point out that means that ICANN involvement may be
> necessary/desirable to fix that, and all I was saying was there may
> be less need for such involvement in a thick registry model.

If you substitute "registry that communicates directly with registrants" 
for "think registry model" (which is what I think you actually mean) 
than I agree with you. However, those registries are very much in the 
minority.

I'm sorry to be so pedantic on this, but I think it's crucial that we 
get the terminology right. The issue of how to correctly pass DS records 
when a secure domain is transferred between registrars is really 
important, and we are going to need to interface with both the RRR folks 
and ICANN on this in order to figure out a model that will work. If we 
go into that process without speaking the language it's not only going 
to make us look foolish, but more importantly it's going to start us off 
a few squares back before we even get started.

Doug

--

---

From: Mark Andrews <[email-masked]>
Date: Sat, 06 Mar 2010 09:34:02 +1100

> a few squares back before we even get started.

As long as they both support DS it should be a non-issue.  Changing
registrars, by itself, does NOT change DNS data.

If the registrar is doing DNS hosting then one has to transition
from one DNS host to the next DNS host.   The simplest way that I
can see and maintain the secure status of the zone is to have the
loosing DNS host enter DNSKEYs the gaining DNS host supplies into
their zone and have DS records published for them.  Once the old
DS and DNSKEY RRsets have flush from caches the loosing DNS host
slaves the new zone content and the NS RRset is updated in the
parent and the old DS records are remove from the parent.  Once the
old NS RRsets have flushed from caches the loosing DNS host removes
the zone from their servers.

Remove all the DNSSEC from the above and you have how plain DNS
zones should be transfers from one DNS host to another.  Unfortunately
this doesn't happen as often as it should.

Mark

---

From: Wolfgang Nagele <[email-masked]>
Date: Fri, 12 Mar 2010 15:09:55 +0100

Hi,

> EPP is by no means a failure, so I don't want to draw too strongly from
> that example.  There have been other protocols, like for instance IRIS,
> which seemed like good ideas and sound engineering went into them, but
> they fell flat on the ground because the real demand wasn't there.  What
> I am warning against here is thinking that "it would be cool to just
> shove a bit here, a flag there, a TSIG over that part" and think that
> we've come up with a mechanism that works. This wouldn't be used by the
> registration environment, even if it manages to have multiple
> implementations, etc., and rises to Draft and Full Standard.  If that
> happens the IETF may have "succeeded" in producing something to "solve"
> DS consistency, but the registration community would still be looking
> for something useful and we all would be back at the start of the process.
I completely agree with this.

Cheers,
Wolfgang