Subject: [regext] EPP and DNAME records?

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 12 Nov 2017 21:00:06 +0800

[This comes from a discussion in DNSOP about a possible future
.internal.]

Some TLD include DNAMEs (for instance .cat and .asia) but apparently
only as parts of an IDN bundle. Nevertheless, we could imagine a
registry accepting registrations implemented as a DNAME record, not NS
records.

There is apparently no way to do it in EPP.

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.

---

From: "Edmon Chung" <[email-masked]>
Date: Mon, 13 Nov 2017 00:20:25 +0800

We actually do not use DNAME for IDN Variants at DotAsia.  IDN Variants are
delegated to the same set of NS as the primary IDN for .Asia.  Nevertheless,
its prob good to revisit having a standard IDN Variant provisioning
extension (again) now with the progress in the LGR work...

Edmon

> -----Original Message-----
> From: regext [mailto:[email-masked]] On Behalf Of Stephane
Bortzmeyer
> Sent: Sunday, 12 November 2017 21:00 PM
> To: [email-masked]
> Subject: [regext] EPP and DNAME records?
> 
> [This comes from a discussion in DNSOP about a possible future .internal.]
> 
> Some TLD include DNAMEs (for instance .cat and .asia) but apparently only
as
> parts of an IDN bundle. Nevertheless, we could imagine a registry
accepting
> registrations implemented as a DNAME record, not NS records.
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: 'Stephane Bortzmeyer' <[email-masked]>
Date: Mon, 13 Nov 2017 10:02:14 +0800

On Mon, Nov 13, 2017 at 01:52:26AM +0000,
 Feher, Kal <[email-masked]> wrote 
 a message of 71 lines which said:

> Why wouldnt we have DNAME at the apex of the registered name? Ie
> controlled by the domain owner.

It would force the domain holder to have nameservers configured for
this name. It is always a hassle but, in the case of RFC 7535, it is
simply not possible.

> I may be missing something of the use case here.

My personal use case was RFC 7535 + draft-wkumari-dnsop-internal.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 13 Nov 2017 02:17:17 +0000

Stephane, I would definitely appreciate a summary during the meeting today if you wish to share.

Scott

> Sent: Sunday, November 12, 2017 8:00 AM
> To: [email-masked]
> Subject: [EXTERNAL] [regext] EPP and DNAME records?
>
> as parts of an IDN bundle. Nevertheless, we could imagine a registry
> accepting registrations implemented as a DNAME record, not NS records.
>

---

From: Francisco Arias <[email-masked]>
Date: Mon, 13 Nov 2017 02:38:08 +0000

I cannot speak for .cat, but looking at zone file archives for their TLD, I haven't seen DNAMES for a while. I believe they stopped using DNAMEs at some point in the past.

-- 
Francisco

On 11/13/17, 12:20 AM, "regext on behalf of Edmon Chung" <[email-masked] on behalf of [email-masked]> wrote:

    Edmon

    Bortzmeyer
    as
    accepting

---

From: Kim Davies <[email-masked]>
Date: Mon, 13 Nov 2017 02:49:21 +0000

The only TLD registry I am aware of that uses DNAME records is .gr, and in that instance, I believe they synthesize them from an LGR in a deterministic way and do not need to be provisioned by the customer.

kim

"regext on behalf of Francisco Arias" <[email-masked] on behalf of [email-masked]> wrote:

    -- 
    Francisco

        
        Edmon

        Bortzmeyer
        as
        accepting

---

From: 'Stephane Bortzmeyer' <[email-masked]>
Date: Mon, 13 Nov 2017 11:09:30 +0800

On Mon, Nov 13, 2017 at 02:26:00AM +0000,
 Feher, Kal <[email-masked]> wrote 
 a message of 34 lines which said:

> certainly in breach of current gTLD requirements for zone contents.

There are not only ICANN-regulated registries. Besides the root (my
personal use case), there are ccTLD and also all the registries at
lower levels (they typically don't use EPP today but it may change).

Also, this is a technical proposal, independent of the _current_
policy. ICANN may accept DNAME in the future (they should).

---

From: "Edmon Chung" <[email-masked]>
Date: Mon, 13 Nov 2017 11:21:39 +0800

TWNIC might be using it, not absolutely sure if they continue to:

https://www.icann.org/resources/idn-cctlds/1145486-2012-02-25-en

http://www.twnic.net/english/dn/dn_07a.htm

http://www.twnic.net/english/dn/pdf7a.pdf

Edmon

> From: regext [mailto:[email-masked]] On Behalf Of Kim Davies
> Sent: Monday, 13 November 2017 10:49 AM
> To: Francisco Arias <[email-masked]>; 'Stephane Bortzmeyer'
> <[email-masked]>; [email-masked]
> Subject: Re: [regext] [Ext] Re: EPP and DNAME records?
> 
> The only TLD registry I am aware of that uses DNAME records is .gr, and in
that
> instance, I believe they synthesize them from an LGR in a deterministic
way and
> do not need to be provisioned by the customer.
> 
> kim
> 
> "regext on behalf of Francisco Arias" <[email-masked] on behalf
of
> [email-masked]> wrote:
> 
>     I cannot speak for .cat, but looking at zone file archives for their
TLD, I haven't
> seen DNAMES for a while. I believe they stopped using DNAMEs at some point
in
> the past.
> 
>     --
>     Francisco
> 
>     On 11/13/17, 12:20 AM, "regext on behalf of Edmon Chung" <regext-
> [email-masked] on behalf of [email-masked]> wrote:
> 
.internal.]
> only

---

From: "Feher, Kal" <[email-masked]>
Date: Mon, 13 Nov 2017 01:52:26 +0000

Kal Feher

On 13/11/17, 00:20, "regext on behalf of Edmon Chung"
<[email-masked] on behalf of [email-masked]> wrote:

>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman
>>_listinfo_regext&d=DwICAg&c=MOptNlVtIETeDALC_lULrw&r=_-v0M-gLiqWrtaHtP66h
>>jSPyu3ePgw9YIihGxxybjqU&m=4SOhTmHO7Z4na_yAH_hBFJ9UpXDQgX2tBrQ-FuitdGM&s=V
>>ugCJ6Gqq7ompEyc8jDyD_2OAc5MB0jG3zwek3d1Iyc&e=
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>listinfo_regext&d=DwICAg&c=MOptNlVtIETeDALC_lULrw&r=_-v0M-gLiqWrtaHtP66hjS
>Pyu3ePgw9YIihGxxybjqU&m=4SOhTmHO7Z4na_yAH_hBFJ9UpXDQgX2tBrQ-FuitdGM&s=VugC
>J6Gqq7ompEyc8jDyD_2OAc5MB0jG3zwek3d1Iyc&e=

---

From: "Feher, Kal" <[email-masked]>
Date: Mon, 13 Nov 2017 02:26:00 +0000

Ok that's helped it clarify things in my mind.

So your desire is to have an epp mapping for dname so that the verisign
registry for the root zone can accept such records? I suppose that's up to
the root zone maintainers and there's no harm in creating the mapping or
an extension. But the use case for name registries would be very narrow
and potentially worse for the registrant and certainly in breach of
current gTLD requirements for zone contents.

Kal Feher

---

From: "Feher, Kal" <[email-masked]>
Date: Mon, 13 Nov 2017 03:56:44 +0000

The point I was making was that the use cases appear to be very small.
Even where a name registry might use it, there appear to be actual
solutions that don't use it. If you're bundling IDN domains, that's
typically a server side policy. No epp necessary. If you're allowing user
choice, then a dname within the zone of the registered name would
certainly work. <- this option is still available to registrants of
domains where bundling is handled by enforcing shared NS records.

As I said in my earlier email, I don't see harm in adding the mapping.

Kal Feher
Neustar Inc.
Melbourne, Australia

On 13/11/17, 11:09, "regext on behalf of 'Stephane Bortzmeyer'"
<[email-masked] on behalf of [email-masked]> wrote:

>Pyu3ePgw9YIihGxxybjqU&m=Dj_J_Do1FDcSWQXvXH_ohS0LMKQPdU6QE_Dqm1Tk71k&s=gIMG
>bpcW488Th1pBS9qwmPUBj9QYGCZKTwjOzcso-98&e=

---

From: [email-masked]
Date: Mon, 13 Nov 2017 09:10:34 +0100

> extension (again) now with the progress in the LGR work...

And, just for completeness, .cat does also no longer use DNAME records for the 
IDN variants. The inability to use the variant name itself (i.e. without a 
subdomain prefix like "www.") always caused confusions both for registrants and 
users, so the use of DNAME was abandoned when the registry was migrated to a new 
software platform (while this platform still supports DNAME records as an 
alternative to duplicated NS records vor variants). It is quite sad that still 
no record type exists that combines CNAME and DNAME functionality...

Regards,

Klaus

>> parts of an IDN bundle. 
 >> [...]