Subject: [DNSOP] Updating the DNS Registration Model to Keep Pace with Today’s Internet

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 5 Feb 2015 17:58:11 +0100

"CloudFlare is advocating to gain the ability to update NS records for
our customers and address records associated with them using automated
channels. Our goal is to be able to add and remove nameservers from
customer domains without the customer being involved." Possible work
for this working group?

https://blog.cloudflare.com/updating-the-dns-registration-model-to-keep-pace-with-todays-internet/

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 5 Feb 2015 15:27:37 -0500

> On Feb 5, 2015, at 11:58 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Thanks Stephane, 

Possible work in DNSOP or as this may involve registries and registers
a new single topic WG might be the way to go. 
It is, almost, too too late to ask for a BoF in Dallas, but if DNSOP can spend some  time on
this topic and what it involves that would be great. IMHO

Olafur

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Feb 2015 08:58:34 +1100

In message <[email-masked]>, Olafur Gudmundsson 
> this topic and what it involves that would be great. IMHO

It's not like support for automated updates hasn't been raised before
but another attempt is always useful.

Mark

http://tools.ietf.org/id/draft-andrews-dnsop-update-parent-zones-04.txt

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

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Thu, 5 Feb 2015 17:30:35 +0000

The sad fact is that only a tiny fraction of IT professionals even understand the importance of the NS record.

It is the *definition* of who (what) controls a domain.

I applaud CloudFlare in trying to improve customer service (and/or reduce costs, depending on how you look at it).

It is important that domain owners are aware of the supreme nature of the NS record.  They may choose to 
hand that over for a, or many domains.  Should relationships between major hosting/CDN providers and registrars (etc.)
be established to facilitate easier migrations of DNS operations, great.  Perhaps even a standard for the process.

But be careful.  There be dragons here.  Computers updating computers to control who controls the domains?

/Hugo Connery (Tech. Uni Denmark)

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Feb 2015 09:59:50 +1100

In message <[email-masked]>, 
Hugo Maxwell Connery writes:
> hand that over for a, or many domains.  Should relationships between major ho
> sting/CDN providers and registrars (etc.)

Computers update computers all the time.  It's about establishing
the right controls.  There is nothing technologically hard about
giving someone the right to update just the NS records.

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

---

From: hellekin <[email-masked]>
Date: Thu, 05 Feb 2015 21:19:50 -0300

> giving someone the right to update just the NS records.
*** Except when they do it on your behalf without your consent and under
the (invisible, unspeakable) pressure of a police state.

For the record, as a regular Tor user, I do not have the same reverence
to Cloudflare's customer service.  Although they keep defending the
thesis that "website owners" must select an emergency defense mode to
actually block Tor traffic, as more websites use Cloudflare services,
they become unusable without a proprietary javascript-powered CAPTCHA.

Given their jurisdiction, and the current war on cryptography, the
potential for abusive breaches of privacy with this system are
non-negligible.  Adding to that the power to update the authoritative
name servers for a domain, and you have a perfect Internet for Police
State.  And until now, without any IETF-approved alternative.

==
hk

---

From: Daniel Stirnimann <[email-masked]>
Date: Fri, 06 Feb 2015 09:23:44 +0100

Jacques Latour (CIRA.CA) made a proposal on the
[email-masked] mailing list some weeks ago:

Adding External DNS Operator Role in RRR Model to better support DNSSEC
Deployment.docx

https://elists.isoc.org/pipermail/dnssec-auto-ds/2014-November/000001.html

Daniel

---

From: Ed Pascoe <[email-masked]>
Date: Fri, 6 Feb 2015 15:32:02 +0200

I don't think this needs to fall under DNSOP at all. Its probably more
appropriate for the eppext group.

You would need to convince the registry to allow you access to the host
object for a particular domain, probably an out of band operation requiring
agreement between registry, registrar, registrant, and yourselves.

After that standard EPP update commands could be used with the registry
enforcing limits as to what could be changed. You would probably also need
to be able to change the TTL at the registry as well, most registries use
24 or 48 hours by default .  I can't find the reference, but I think Gavin
Brown from Centralnic was involved in an EPP extension for TTLs.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 06 Feb 2015 07:21:09 -0800

> Ed Pascoe <mailto:[email-masked]>
> Friday, February 06, 2015 5:32 AM

+1.

-- 
Paul Vixie

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 06 Feb 2015 08:54:02 -0800

not true.
> When this model was created, no one one thought that DNS service might 
> be provided by someone other than Registrant and Registrar. 

and +1 on sending this to eppext.

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Feb 2015 17:00:47 +0000

> and +1 on sending this to eppext.

Why do NS records get treated differently from DS records?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet: Northeasterly 5 or 6, occasionally 7 in south. Moderate or
rough in south, moderate in north. Mainly fair. Good.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Feb 2015 09:25:58 -0800

> Why do NS records get treated differently from DS records?

History: some registries still think that DNSSEC is a new experiment and don't want to spend the effort to support it until it is "real".

Risk: a registry saying that it will update DS records in a timely fashion is a cost with no perceived benefit to the registry.

--Paul Hoffman

---

From: Paul Vixie <[email-masked]>
Date: Fri, 06 Feb 2015 09:49:00 -0800

> Paul Hoffman <mailto:[email-masked]>
> Friday, February 06, 2015 9:25 AM
>
> History: some registries still think that DNSSEC is a new experiment
> and don't want to spend the effort to support it until it is "real".

perhaps the apparent need for negative trust anchors has bolstered the
sense that DNSSEC is still experimental. or perhaps it's the fact that
after 19 years of development, the protocol still isn't finished and no
application depends on DNSSEC or behaves differently in the presence of
DNSSEC?
>
> Risk: a registry saying that it will update DS records in a timely
> fashion is a cost with no perceived benefit to the registry.

if i were a registrar that's the position i'd take, until i saw
counter-risk of customer migration away from me. because as of this
moment, DNSSEC adds risk and cost always, benefit never. we can't make
that not-so by wishing or pretending otherwise, or by ignoring the facts
as they clearly are.

note: i'm not a hater. i want DANE, and other DNSSEC-enabled
applications. i think we need DNSSEC. i'm just incredibly sympathetic to
anyone who says it's not here yet and that it demonstrates very little
inevitability.

see also:
<http://www.circleid.com/posts/defense_in_depth_for_dnssec_applications/>.

-- 
Paul Vixie

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 06 Feb 2015 10:16:05 -0800

On 2/6/15 9:49 AM, Paul Vixie wrote:
> note: i'm not a hater.

color me a "hater". the imposition of dnssec on all 2013 new gtld 
applicants was abuse of applicants, not all of whom are speculators 
burning other peoples' money in pursuit of the trademark 
defense-and-infringement and clickbait sales.

insisting it has unlimited utility is indistinguishable from insisting 
it has no utility.

and i reluctantly wrote a funnel request to sign a zone because the 
customer just wanted to be first in its region, nothing but a marketing 
ploy.

if anyone is actually making honest money from offering DS to generic 
$6/yr (plus annual auto-approved increments) registrants, let me know, 
please.

-e

---

From: Paul Wouters <[email-masked]>
Date: Fri, 6 Feb 2015 15:27:32 -0500 (EST)

On Fri, 6 Feb 2015, Ed Pascoe wrote:

> I don't think this needs to fall under DNSOP at all. Its probably more appropriate for the eppext group. 

And in fact we tried it in dnsop a few years ago, leading to a use-cases
document failure stuck between the Registrant-Registrar-Registry model
people, and the rest of the world. It dies and people just focused on
the DNS record updating part.

So yes, +1 to taking this to eppext.

Paul

---

From: Rubens Kuhl <[email-masked]>
Date: Sat, 7 Feb 2015 04:44:07 +0800

Moving to peppiest is a market concentration movement, since it's expected that only a few DNS providers will be able to justify having permanent connection to registries to use them as DNS updating mechanisms. 

DNS itself can be the enabler of a more inclusive way to do this. If it makes sense to do both, like a "hot channel" for Cloudflare, Dyn, UltraDNS and other massive providers, and one in-band signalling mechanism for the long tail, then let's do both... but it should probably start with the more open approach (roads) and then a more planned high-capacity method (railways). 

Rubens

> On Feb 7, 2015, at 4:27 AM, Paul Wouters <[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 6 Feb 2015 22:02:13 -0000

>application depends on DNSSEC or behaves differently in the presence of

At my registry, development is prioritized by a combination of
expected revenue and amount of customer whining.  As far as I can
tell, I am a double digit percentage of the whiners.

Its Tucows, who already have a perfectly workable XML-based API that
all of their clients use, so it's not like the development would be
a vast amount of new and exotic code.  We already update the name
servers through the API.

R's,
John