Subject: Re: [regext] EPP and DNAME records?

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 5 Jan 2018 12:10:14 +0100

On Sun, Nov 12, 2017 at 09:00:06PM +0800,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 19 lines which said:

> we could imagine a registry accepting registrations implemented as a
> DNAME record, not NS records.
> 
> Would it make sense to create an extension (may be an addition to RFC
> 5731) to allow these "DNAME registrations"?
> 
> I'll be at the meeting tomorrow, if you prefer to discuss it AFK.

After the discussion in Singapore, here is the draft. Comments and
criticisms are welcome.

https://datatracker.ietf.org/doc/draft-bortzmeyer-regext-epp-dname/

---

From: "Gould, James" <[email-masked]>
Date: Fri, 5 Jan 2018 15:46:28 +0000

Stephane,

Thanks for posting the draft for review.  The following is my initial feedback:

1. If the registry starts accepting more resource record types in addition to or as an alternative to the existing record types, why not define a more generic RR extension that allows for the CRUD of the RR associated with a domain name?  
a. DNAME could be one of the supported RR types.  
b. If new resource record types can be managed by the registry, do we need to create an EPP extension for each one?  
c. It would be up to server policy which RR types are supported.  A RR policy extension of the Registry Mapping could be leveraged to define the RR types supported by the server along with any RR restrictions.      
2. It would be best to reference eppcom:labelType for the dnameTarget element instead of a string.  One issue with the eppcom:labelType is that it has a minimum length of 1, so an empty element cannot be used to remove it.  The dnameDeleg schema could define its own labelType that sets the minimum length to 0.  
3. It may be best to make the setting or removing of the dname explicit in the extension to the update command, as in the following
<dnameDeleg:update>
  <dnameDeleg:set>foo.bar.example</dnameDeleg>
</dnameDeleg:update>

or 

<dnameDeleg:update>
  <dnameDeleg:delete/>
</dnameDelete:update>
4. I assume that return of the dnameDeleg extension in the info response would be based on the existence of the dnameDeleg data, server policy, and support of the client for dnameDeleg based on the EPP login services provided by the client.
a. An alternative to leveraging the EPP login services of the client, is to extend the EPP info command with an empty element like <dnameDeleg:info/> to explicitly specify the inclusion of the dnameDeleg extension in the response.  If it were explicit, then the case of no data would need to be handled.  One option is to support a <dnameDeleg:infData> element in the extension of the info response that includes the <dnameDeleg:dnameTarget> element if it’s set.  
i. One advantage to the explicit approach is that it’s clear which version of dnameDeleg is desired if there are multiple supported versions (e.g., urn:ietf:params:xml:ns:dnameDeleg-0.1, urn:ietf:params:xml:ns:dnameDeleg-0.2); otherwise the server would need to choose the highest version supported by the client based on the client’s login services.
5. For issue #3 listed at https://framagit.org/bortzmeyer/ietf-epp-dname/issues, I believe the client can determine support for DNAME via the services returned in the EPP greeting by the server.  
6. One additional complexity is how to handle transfers when the gaining registrar does not support dnameDeleg.  There are other mechanisms to determine the state of the transferred domain (e.g., DNS, reports), but the gaining registrar will simply not be able to get or set the dname via EPP until they support dnameDeleg.        
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 

On 1/5/18, 6:10 AM, "regext on behalf of Stephane Bortzmeyer" <[email-masked] on behalf of [email-masked]> wrote:

    

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 6 Jan 2018 17:30:22 +0100

On Fri, Jan 05, 2018 at 03:46:28PM +0000,
 Gould, James <[email-masked]> wrote 
 a message of 72 lines which said:

> Thanks for posting the draft for review.

And thanks for the detailed review.

> The following is my initial feedback:

Most of it has been incorporated
<https://framagit.org/bortzmeyer/ietf-epp-dname/commit/4be3162973bc5d64ad78a38e38a08d31d31bc4c4>
and will appear in -01. However:

> 1. If the registry starts accepting more resource record types in
> addition to or as an alternative to the existing record types, why
> not define a more generic RR extension that allows for the CRUD of
> the RR associated with a domain name?

Clearly, this is out-of-scope for me. The goal of this document is not
to allow arbitrary DNS Resource record types (such as TXT or
LOC). Such a mapping would allow the EPP server to implement a
"delegation-less" registry, letting the client add A, AAAA, etc
records. It would require more complexity, with the various RR
formats, and the ability to add, update and remove individual records
(RFC 5910 style)

Instead, I keep the idea that the EPP server registers only
delegations, either through NS records or, as here, a DNAME
record. This keeps the mapping much simpler.

> a. DNAME could be one of the supported RR types.

DNAME, like NS, is special. It cannot coexist with other records, for
instance.

> c. It would be up to server policy which RR types are supported.  A
> RR policy extension of the Registry Mapping could be leveraged to
> define the RR types supported by the server along with any RR
> restrictions.

Nice idea but clearly much more work. For someone braver than me :-)

> 2. It would be best to reference eppcom:labelType for the
> dnameTarget element instead of a string.  

Great. Done. 

>   <dnameDeleg:set>foo.bar.example</dnameDeleg>

I hesitate. More advices welcome (see
<https://framagit.org/bortzmeyer/ietf-epp-dname/issues/5>)

> 4. I assume that return of the dnameDeleg extension in the info
> response would be based on the existence of the dnameDeleg data,
> server policy, and support of the client for dnameDeleg based on the
> EPP login services provided by the client.

Yes (-00 did not mention the EPP login services. Added.)

> a. An alternative to leveraging the EPP login services of the
> client, is to extend the EPP info command with an empty element like
> <dnameDeleg:info/> to explicitly specify the inclusion of the
> dnameDeleg extension in the response.

https://framagit.org/bortzmeyer/ietf-epp-dname/issues/6

> 5. For issue #3 listed at
> https://framagit.org/bortzmeyer/ietf-epp-dname/issues, I believe the
> client can determine support for DNAME via the services returned in
> the EPP greeting by the server.

No, because it is only the general support by the server, not the fact
it is accepted for all domain names. 1) A server may handle two TLD,
with different policies 2) A server may allow DNAME for a given
subdomain (say, gov.example) but not for other names. So, the EPP
greeting is necessary but not sufficient.

> 6. One additional complexity is how to handle transfers when the
> gaining registrar does not support dnameDeleg.  There are other
> mechanisms to determine the state of the transferred domain (e.g.,
> DNS, reports), but the gaining registrar will simply not be able to
> get or set the dname via EPP until they support dnameDeleg.

Documented. (The obvious solution is for the transfer to fail. Note
that RFC 5910 is silent about that.)

---

From: Patrick Mevzek <[email-masked]>
Date: Sat, 06 Jan 2018 20:01:02 +0100

Hi Stéphane,

James beats me for an extensive review of your draft.

Here are some of my points however:

* I agree on your specific goal of just DNAME and its specific semantic (however you can have other records besides DNAME for a specific QNAME, like RRSIG. RFC6672 §6.1 has a clear example of DNAME+MX) but of course as soon as we add one RR through EPP, as James stated there is the question about all others.
There is even already an extension for that.
It had URN http://www.verisign.com/epp/zoneMgt-1.0 and I have the code implementing it
in my client, but I do not find it anymore on Verisign website.

* I would like to see more explanations on what happens if a registrar adds a DNAME
on an existing domain name that have in-bailiwick nameservers and hence glues in registry
zonefile. Should the change be forbidden (until the registrar removes the nameserver objects) or just the glues just be removed? Then should the nameserver object be deleted too automatically?

* Also what happens if the DNAME target is internal to the registry (same TLD)? Should the registry check the domain exists? What if the target has a DNAME record too?

* about transfers: you say in your new revision that the transfer may fail if the new registrar does not support DNAME delegation. How would the registry know that beforehand?
Clearly outside of the protocol definition, but does that mean there will be a need of
specific list of registrars supporting that or not, and a specific "accreditation"
I fear this can very soon go into the same rabbit-hole as the case of DNSSEC enabled transfers, and then you have only answers like the keepDS solution in frnic extension,
or something along the standard keyRelay extension.

* I have mixed feelings about section 10.
Specifically you state:
A trust relationship MUST exist between the EPP client and
   server, and provisioning of DNAME delegation MUST only be done after
   the identities of both parties have been confirmed using a strong
   authentication mechanism.

Does that mean that provisions in RFC5734 (specifically section 8) are not enough to provide that?
Otherwise why restating that here?

* On issue #3 and the issue of feature discoverability per domain, I do not think the EPP check command is appropriate for that. The DNAME record is not an object per se in the registry data model and hence no operations would apply to it. It would seem wrong to update
the domain:check to signal this. I fear right now the best way is for a registrar to just
try its create/update and mandate that the registry has a clear error essage in its answer
if DNAME is not supported (unfortunately there is no way to extend the protool in that direction -- coincidently I was about to send a draft related to handling of error codes).

It could however be a separate and specific other endeavour (auto-discovery of features/capabilities on a fine grained level, per registry object).

* On issue #5 I would prefer it stays with EPP terminology, so update+chg (not set) nodes.

* On issue #6 I feel it not necessary for the client to explicitely signal it wants
the info back for the following reasons:
- I expect the use of this feature to be very low, both per registry and per domain inside a registry (but would love to have more data points or wishlists expressed by actors if you have some - you give only RFC7535 as an example and I doubt that AS112 project would hany kind of public domain nam registry attached to it soon)
- if this element is present, it is minor in the reply and do not create parsing problems
(specifically since its presence is dependant on the login being done with the extension)
- I can not really imagine multiple versions of your extension in the wild at the same time (James/you speak about -01 vs -02), do you have a specific idea in mind?

If you really want to signal no data in all cases, you can also reply with an empty dNameTarget (but I am not sure it is useful: in the same way for a DNSSEC enabled domain, if there as no DS/DNSKEY records attached to it then you do not get the extension in the domain:info and everything is fine, and the client does not specify anything in its domain:info command)

HTH,

-- 
  Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Sat, 06 Jan 2018 20:05:52 +0100

On Sat, Jan 6, 2018, at 20:01, Patrick Mevzek wrote:

> - I can not really imagine multiple versions of your extension in the 
> wild at the same time (James/you speak about -01 vs -02), do you have a 
> specific idea in mind?

And even in that case the client would surely at login specify only one of the two versions
so the answer would reflect that.

Expect if -02 is not a superste of -01 and introduce a completely different datamodel...

-- 
  Patrick Mevzek

---

From: "John Levine" <[email-masked]>
Date: 7 Jan 2018 08:26:46 -0500

>DNAME, like NS, is special. It cannot coexist with other records, for

It can coexist with anything other than CNAME, NS/DS, or another DNAME,
and you need A, AAAA, and MX records at the DNAME to do what many
people wrongly believe that DNAME does.  See RFC 6672, sec 2.4.

Not to be oversnarky, but I'd want a field to upload a picture of the
user shooting himself in the foot to demonstrate that he understands
what DNAMEs will do.  I once did a spot check of the DNAMEs that used
to be in .cat and I don't recall finding any that were implemented
correctly, e.g., with a web server that responded to both www.<name>
and www.<dname> with a reasonable web page.

I assume I missed a discussion of what problem this solves -- is
it in the list archives?

R's,
John

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 8 Jan 2018 14:34:02 +0100

On Sun, Jan 07, 2018 at 08:26:46AM -0500,
 John Levine <[email-masked]> wrote 
 a message of 20 lines which said:

> It can coexist with anything other than CNAME, NS/DS, or another
> DNAME, and you need A, AAAA, and MX records at the DNAME to do what
> many people wrongly believe that DNAME does.  See RFC 6672, sec 2.4.

You're right, of course. Sorry for the mistake. It may be because I
thought of only one use case (see below).

> Not to be oversnarky, but I'd want a field to upload a picture of
> the user shooting himself in the foot to demonstrate that he
> understands what DNAMEs will do.

Right. Warnings added
<https://framagit.org/bortzmeyer/ietf-epp-dname/commit/bc4f697946848861ec62e14e710f10ef73f1241b>

> I assume I missed a discussion of what problem this solves -- is it
> in the list archives?

Yes. Added to the future version of the draft but, basically, it is
draft-bortzmeyer-dname-root. Some people remarked that we don't even
have an EPP mapping for DNAME. It is not the biggest obstacle to
draft-bortzmeyer-dname-root but this new draft
draft-bortzmeyer-regext-epp-dname is an attempt to lift it.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 8 Jan 2018 14:51:02 +0100

On Sat, Jan 06, 2018 at 08:01:02PM +0100,
 Patrick Mevzek <[email-masked]> wrote 
 a message of 77 lines which said:

> as soon as we add one RR through EPP, as James stated there is the
> question about all others.

Yes, and I clearly do not want to go into that: too complicated for
me.

> There is even already an extension for that.  It had URN
> http://www.verisign.com/epp/zoneMgt-1.0 and I have the code
> implementing it in my client, but I do not find it anymore on
> Verisign website.

It is not in the IANA EPP extensions registry either.

> zonefile. Should the change be forbidden (until the registrar
> removes the nameserver objects) or just the glues just be removed?
> Then should the nameserver object be deleted too automatically?

There is also the fact that not everybody uses RFC 5732. Added as #7
<https://framagit.org/bortzmeyer/ietf-epp-dname/issues/7>

> * Also what happens if the DNAME target is internal to the registry
> (same TLD)? Should the registry check the domain exists? What if
> the target has a DNAME record too?

Added as a MAY, like for the DNS tests
<https://framagit.org/bortzmeyer/ietf-epp-dname/commit/19875dbdfdc04c24ed26a0d5085147727f34673e>

> I fear this can very soon go into the same rabbit-hole as the case
> of DNSSEC enabled transfers, and then you have only answers like the
> keepDS solution in frnic extension, or something along the standard
> keyRelay extension.

Yes. I do not intend to develop a new mechanism. Either the registry
policy forces all the clients to handle a set of mandatory extensions,
or we reuse the DNSSEC hacks.

> * I have mixed feelings about section 10.

It is copy-and-paste for RFC 5910, which is on the standards track.

> * On issue #3 and the issue of feature discoverability per domain, I
> do not think the EPP check command is appropriate for that. The
> DNAME record is not an object per se in the registry data model and
> hence no operations would apply to it.

The idea was not to use the DNAME record as the object but the domain
name, with an extension. Something like:

<domain:check
       <domain:name>example.com</domain:name>
       <dnameDeleg:if>foo.bar.example.net</dnameDeleg:if>
</domain:check>

But I agree it is not necessary:

> I fear right now the best way is for a registrar to just try its
> create/update and mandate that the registry has a clear error essage
> in its answer

I agree.

> update+chg (not set) nodes.

Noted.

> * On issue #6 I feel it not necessary for the client to explicitely signal it wants the info back for the following reasons:

I agree also.

> If you really want to signal no data in all cases, you can also
> reply with an empty dNameTarget

Note that it is not permitted if we switch from EPP string to
eppcom:labelType.

---

From: "John Levine" <[email-masked]>
Date: 9 Jan 2018 10:24:16 +0800

>draft-bortzmeyer-regext-epp-dname is an attempt to lift it.

Now I'm confused.  I can see the point of a DNAME from .local to
empty.as112.arpa, and maybe a few poisoned 2LDs to empty.as112.arpa,
but DNAME'ing anything else in a TLD or 2LD is asking for misery since
the semantics of DNAME are a poor match for people who want two name
trees to be "the same."

I'm not sure how practical this is, but I'd be much more comfortable
with an EPP mapping that only mapped to empty.as112.arpa.

R's,
John

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 09 Jan 2018 03:35:22 +0100

> It is copy-and-paste for RFC 5910, which is on the standards track.

You are not the first one giving me that explanation when I do a review.

I think however this is a weak argument. Even perfect RFCs have errata
and are then later on obsoleted by other RFCs. So nothing is set in stone,
and if there was an error before or anyhing that is just copied from one RFC
to another this does not make it true and not questionable again.

This is why I was asking you, as author, if you are behind the sentence
you wrote, and if so if you can explain why it is mandatory.

Because I do not understand it.

-- 
  Patrick Mevzek

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 9 Jan 2018 16:32:21 +0100

On Tue, Jan 09, 2018 at 10:24:16AM +0800,
 John Levine <[email-masked]> wrote 
 a message of 28 lines which said:

> > it is draft-bortzmeyer-dname-root. Some people remarked that we
> > don't even have an EPP mapping for DNAME. It is not the biggest
> > obstacle to draft-bortzmeyer-dname-root but this new draft
> but DNAME'ing anything else in a TLD or 2LD is asking for misery

Well, TLD which agree with you will simply don't implement or deploy
this service, that's all (like all other EPP extensions). The draft
draft-bortzmeyer-regext-epp-dname describes a XML schema, not a TLD
policy.

And, anyway, my first use case was only for the root but I don't see
the point of hardwiring this specificity in the draft

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 12 Jan 2018 14:59:48 +0100

> Does that mean that provisions in RFC5734 (specifically section 8) are not enough to provide that?

I don't have a strong opinion here. Should the draft be adopted, I
would be happy to defer to the WG decision. In the mean time, I see no
harm in repeating this. Many RFC have security considerations sections
which are as surprising as "remember that water is wet and fire is
hot".

---

From: Patrick Mevzek <[email-masked]>
Date: Sun, 14 Jan 2018 00:50:13 +0100

> Yes, and I clearly do not want to go into that: too complicated for

Have you seen draft-ietf-dnsop-aname?

Seems to be closely related in the sense that it could be as useful to have
DNAME as to have ANAME (of course the difference is that one already exists
the other not yet or never)

> It is not in the IANA EPP extensions registry either.

There are many EPP extensions in the wild not in the extensions registry.
 
>        <dnameDeleg:if>foo.bar.example.net</dnameDeleg:if>

I am not sure you could easily extend the current core EPP to do that.
AFAIR I have never seen an extension like that.
  
> Note that it is not permitted if we switch from EPP string to

Except if you derive from it and/or you have a different type for update than for create.

-- 
  Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Sun, 14 Jan 2018 00:52:33 +0100

> the point of hardwiring this specificity in the draft

AFAIK there is no (not yet?) IANA EPP server to which TLD operators are clients,
so how would they use the extension to signal to the root to have one TLD being a DNAME
to another?

-- 
  Patrick Mevzek

---

From: "John Levine" <[email-masked]>
Date: 14 Jan 2018 14:31:37 -0500

>the other not yet or never)

There's little reason to put an ANAME into a TLD zone file.  Whatever
you wanted to do with one, you can do equally well with an ANAME at
the apex of a 2LD.  For that matter, if you really really want to
shoot yourself in the foot, you can get the same effect as a DNAME in
a TLD right now by delegating the name and putting the DNAME at the
apex of the 2LD, nothing new required.  You could even have an ANAME
and DNAME together, to sort of simulate the also non-existent BNAME.

I continue to believe that allowing DNAMEs in TLDs is a bad idea, and
so I see no reason to spend further effort on this extension.  

With respect to DNAMEs at the top level, someone else noted that the
root zone isn't managed the same way as TLDs, so there's no obvious
connection.  Since you can get the effect of a DNAME in the root zone
by putting a DNAME at the apex of a TLD as Taiwan has done, if people
want more root-ish DNAMEs it might be more productive to consider how
to invent a policy to allow a DNAME-only TLD if you're not a ccTLD.

R's,
John

---

From: Patrick Mevzek <[email-masked]>
Date: Sun, 14 Jan 2018 20:51:45 +0100

On Sun, Jan 14, 2018, at 20:31, John Levine wrote:
> There's little reason to put an ANAME into a TLD zone file. 

Stéphane's draft is not tied to any level of the DNS tree. My comment was in that sense
and based on previous discussions of various RRs in EPP extensions.

> root zone isn't managed the same way as TLDs,

I think that would be me.

> Since you can get the effect of a DNAME in the root zone

But this won't be ontopic in this WG.

-- 
  Patrick Mevzek

---

From: "John Levine" <[email-masked]>
Date: 14 Jan 2018 14:58:50 -0500

>I think that would be me.

Ah, right.

>But this won't be ontopic in this WG.

Well, OK, but the logic of we have to do something bad because we
would have to walk down the hall to do something better escapes me.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 14 Jan 2018 17:49:29 -0500

On Sun, Jan 14, 2018 at 02:31:37PM -0500, John Levine wrote:
> the apex of a 2LD.

Which "you" are we talking about here?  There are reasons to put ANAME
or DNAME, if you believe those things will work, that have to do with
parent-side policy.  That can't be done on the child side because then
the parent has to monitor all its children, which sucks.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 15 Jan 2018 01:19:09 -0500

>the parent has to monitor all its children, which sucks.

I don't understand the objection.  Anyone can put a DNAME at the apex
of a 2LD now, and if we invent ANAMEs, anyone will be able to put
ANAMEs there too.

As far as I'm aware, almost no gTLDs or ccTLDs police the contents of
2LDs now and when they do, it's for content rather than technical
reasons, e.g., to be sure that a sponsored or restricted domain has
the right kind of stuff.  Are you anticipating TLDs that will allow
only approved DNAMEs?  That seems implausible and unenforcable to me.

R's,
John

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 15 Jan 2018 12:08:47 +0100

On Sun, Jan 14, 2018 at 12:52:33AM +0100,
 Patrick Mevzek <[email-masked]> wrote 

> AFAIK there is no (not yet?) IANA EPP server to which TLD operators

Not between IANA and the TLD managers, but EPP is used between IANA
and Verisign
<https://mailarchive.ietf.org/arch/msg/dnsop/lGdwGFO58iJ_dYYM9UR87Er9F5c>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 15 Jan 2018 12:16:37 +0100

On Sun, Jan 14, 2018 at 02:31:37PM -0500,
 John Levine <[email-masked]> wrote 
 a message of 38 lines which said:

> I continue to believe that allowing DNAMEs in TLDs is a bad idea,
> and so I see no reason to spend further effort on this extension.

Really, I do not understand, and I would appreciate explanations. The
original use case is not for DNAME in TLDs. So, whatever you think of
DNAME in TLDs does not mean the extension is useless.

> connection.

Already replied but see

> Since you can get the effect of a DNAME in the root zone by putting
> a DNAME at the apex of a TLD as Taiwan has done,

No, the goal here is to have no NS delegation (for reasons explained
in RFC 7535). So, this cannot work.

> it might be more productive to consider how to invent a policy to
> allow a DNAME-only TLD if you're not a ccTLD.

I'm not in policy, draft-bortzmeyer-dname-root and
draft-bortzmeyer-regext-epp-dname are purely technical.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Jan 2018 07:41:43 -0500

> of a 2LD now, and if we invent ANAMEs, anyone will be able to put

Yes, obviously.

> only approved DNAMEs?  That seems implausible and unenforcable to me.

No, I am anticipating that people want a technical solution to
administrative controls that put names into some kind of
administrative relationship with one another, such that there are
rules about what one may do with one name on the basis of what is done
with another name.  The usual example of this is the CNNIC policy with
respect to IDNs that use simplified or traditional Han characters, but
there are other similar examples.

Now, I happen to believe that DNAME and ANAME and the
proposed-but-so-far-going-nowhere BNAME are all doomed for this
purpose, but others don't think that and they want to try (again) to
use them.  A natural thing to do in that case is to put the relevant
records on the parent side of the cut, in order to enforce the policy,
instead of monitoring them on the child side.

One might argue that what is needed in EPP for that purpose is just
the request for the policy feature (the bundling extensions previously
up for discussion here), but another way to achieve it is just to
provision the relevant RRTYPEs on the parent side.

I don't believe that this WG is the correct place to put a "don't do
that" filter on these sorts of things.  If there is something people
want to be able to express in registries, then it's reasonsble to
create a standard EPP way to do it.  If this WG decides to say,
"That's a dumb thing to want, so we won't publish the document," then
people will create their own extensions to do those things anyway
(since EPP is designed precisely to allow such extensions), and we'll
be back to the same problem that brought EPP work back to the IETF:
everyone conforms to the standard, and yet there are as many ways to
do a thing in EPP as there are registries.  That's not desirable.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 15 Jan 2018 13:09:38 -0500

> <https://mailarchive.ietf.org/arch/msg/dnsop/lGdwGFO58iJ_dYYM9UR87Er9F5c>

This answer just confirms my main point.  Whether to put DNAMEs in the 
root is primarily a policy question.  Even if you thought it was a good 
idea (which I still don't, see next message) there is no point to 
inventing an EPP extension unless and until there is a policy that lets 
them use it.

If merely having the EPP feature was all it took, we'd have sunrise and 
redemption periods in the root.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John R Levine" <[email-masked]>
Date: 15 Jan 2018 13:19:54 -0500

> in RFC 7535). So, this cannot work.

I don't understand this objection.  If there's a reason this wouldn't 
work, I'd appreciate knowing what it is:

in the root (add DNSSEC to taste):

...
evil. NS ns1.evilsrv.wtf.
evil. NS ns2.evilsrv.wtf.
ns1.evilsrv.wtf. glue ...
ns2.evilsrv.wtf. glue ...
...

in the evilsrv.wtf servers

evil. SOA whatever
evil. NS ns1.evilsrv.arpa.
evil. NS ns2.evilsrv.arpa.
evil. DNAME empty.as112.arpa.

There'd be an initial spike of traffic to the evilsrv.wtf servers but 
assuming the DNAME does what you anticipate, that should tail off pretty 
fast as caches start synthesizing the answers.

This has the advantage that it involves no new technology and lets us skip 
directly down the hall to the policy discussion.

Regards,

---

From: Matthew Pounsett <[email-masked]>
Date: Mon, 15 Jan 2018 14:10:02 -0500

On 15 January 2018 at 13:09, John R Levine <[email-masked]> wrote:

> idea (which I still don't, see next message) there is no point to inventing
> an EPP extension unless and until there is a policy that lets them use it.
>
> Perhaps I missed this upthread somewhere, but before we start talking
about EPP extensions for managing the root, shouldn't we talk about using
EPP to manage the root?  Last I heard (May 2017, Spain) there was work
underway for a custom API for TLD->IANA changes that does not involve EPP.
I imagine shifting gears to replace that with an EPP interface would be a
significant undertaking by this time.

---

From: Ulrich Wisser <[email-masked]>
Date: Mon, 15 Jan 2018 19:31:54 +0000

I might be mistaken, but I believe that IANA sends root updates to Verisign
via EPP.
In that light, we would need an EPP extension before IANA can adopt a
policy to allow DNAME in the root.

Matthew Pounsett <[email-masked]> schrieb am Mo., 15. Jan. 2018 um
20:10 Uhr:

>>> <https://mailarchive.ietf.org/arch/msg/dnsop/lGdwGFO58iJ_dYYM9UR87Er9F5c
>>> >
>>>
>>

-- 
Ulrich Wisser
[email-masked]

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 15 Jan 2018 14:46:12 -0500

On 2018-01-15 14:31 -0500, Ulrich Wisser wrote:
> I might be mistaken, but I believe that IANA sends root updates to
> Verisign via EPP.

Yes.

See page 5 of
https://archive.icann.org/en/meetings/seoul2009/bitcache/IANA%20Update%20-%20Kim%20Davies,%20IANA-vid=7506&disposition=attachment&op=download.pdf

and
https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_proposal-relatedtoiana_functionsste-final.pdf

The  current  automated  RZMS replaced the legacy root zone update,
validation, extraction, and distribution methods   with a
web based user interface (UI) that permits  Top-Level Domain (TLD)
managers to submit change requests , an Extensible Provisioning Protocol
(EPP) client and server system that communicates  incoming
root  zone  change requests between the IFO and the RZM,
[..]

(IFO=IANA, RZM=Verisign as DNS root operator)

-- 
Patrick Mevzek

---

From: "John R Levine" <[email-masked]>
Date: 15 Jan 2018 15:05:10 -0500

> policy to allow DNAME in the root.

I don't understand why you think it would have to be in that order.  It 
seems to me that even if DNAMEs in the root are a good idea (which they 
aren't, but whatever) we can't invent an appropriate EPP extension until 
we understand what it needs to do.

A lot of the discussion around this has been related to 2LD DNAMEs, also a 
bad idea, and for which I've seen no demand.

R's,
John

Regards,

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 16 Jan 2018 11:54:36 +0100

On Mon, Jan 15, 2018 at 07:31:54PM +0000,
 Ulrich Wisser <[email-masked]> wrote 
 a message of 99 lines which said:

> IANA sends root updates to Verisign via EPP.  In that light, we
> would need an EPP extension before IANA can adopt a policy to allow
> DNAME in the root.

Yes. That's the entire point. (And it was said several times on this
list but some people don't read threads before replying.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 16 Jan 2018 11:58:37 +0100

On Mon, Jan 15, 2018 at 03:05:10PM -0500,
 John R Levine <[email-masked]> wrote 
 a message of 64 lines which said:

> > In that light, we would need an EPP extension before IANA can
> > adopt a policy to allow DNAME in the root.
> 
> I don't understand why you think it would have to be in that order.

One of the annoying things at IETF is that there is no clear directive
on the order to do things which involve several stakeholders. At the
discussion in dnsop about draft-bortzmeyer-dname-root, Kim Davies
(IANA) suggested that it wasn't productive to discuss the policy part
of the project since there isn't even an EPP mapping for it. So, what
is the right order and who decides on it? (Personal advice: there is
no order, things are faster when done in parallel.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 16 Jan 2018 12:00:31 +0100

On Mon, Jan 15, 2018 at 01:19:54PM -0500,
 John R Levine <[email-masked]> wrote 

> evil. NS ns2.evilsrv.wtf.

Does not work for the use case of draft-bortzmeyer-dname-root since
you cannot delegate new names to the old AS 112 (see RFC 7535 for the
rationale).

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 16 Jan 2018 12:50:48 +0100

> list but some people don't read threads before replying.)

Get real. Just like various other registries IANA (now PTI) has
it's own extensions dealing with there specidfic policies. I don't
think they dependent their policy on whatever this group decides.

	jaap

---

From: "John R Levine" <[email-masked]>
Date: 16 Jan 2018 08:38:59 -0500

> you cannot delegate new names to the old AS 112 (see RFC 7535 for the

Hi, Stephane.  Not to belabor the obvious, but this does not delegate new 
names to the old AS112, it delegates them to real servers which use a 
DNAME to AS112, and it will work fine, so there is no need to put DNAMEs 
in the root zone.  I have read RFC7535, and I have also read RFCs 6672 amd 
1035 and written a few small DNS servers so I am reasonably sure that I 
understand how delegation and DNAMEs work.

To make it easier to understand, imagine that instead of 
ns[12].evilsrv.wtf I said [abc].iana-servers.net.

Once again, in the root (add DNSSEC to taste):

...
evil. NS a.iana-servers.net.
evil. NS b.iana-servers.net.
evil. NS c.iana-servers.net.
...

New tiny zone on [abc].iana-servers.net:

evil. SOA whatever
evil. NS a.iana-servers.net.
evil. NS b.iana-servers.net.
evil. NS c.iana-servers.net.
evil. DNAME empty.as112.arpa.

Regards,

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Jan 2018 11:18:19 +0100

On Tue, Jan 16, 2018 at 08:38:59AM -0500,
 John R Levine <[email-masked]> wrote 

> evil. DNAME empty.as112.arpa.

OK, I see your point. Documented in an appendix in
draft-bortzmeyer-dname-root-05.txt as a possible alternative.

---

From: "John R Levine" <[email-masked]>
Date: 17 Jan 2018 12:20:15 -0500

> draft-bortzmeyer-dname-root-05.txt as a possible alternative.

Thanks.

Now my question is that since we have a workable approach that does not 
require a new EPP extension, and since (in my opinion at least) DNAMEs as 
2LDs are an actively bad idea, what need is there for this extension?

Regards,

---

From: Kim Davies <[email-masked]>
Date: Wed, 17 Jan 2018 21:06:14 -0800

Hi Stephane,

> no order, things are faster when done in parallel.)

That is not quite what I said. I was responding to a thread on dnsop a
few months back where there was the suggestion that implementing support
for DNAME records in the root zone would be trivial. My view is that
it is not likely to be trivial, and as an illustrative example noted
"Just one of the many things that would need to be looked at is how to
transmit DNAME provisioning requests via EPP. I don't know if there is
even an EPP mapping for this."

My view on this work is that if there is a broader application for a
DNAME mapping, it is a good idea to standardize it. If it is really
only intended for the root zone, for a speculative future where we may
need to provision DNAME records, then I don't think it is necessary for
that reason alone. In such a scenario, there are alternatives such as
developing private extensions between the only two parties who would
ever be putting it to use.

kim