[dns-operations] Registrar for .net and .com fails to accept an NS in .edu

[John W.O'Brien]

On 2018/12/04 11:15, Tony Finch wrote:
> John W.O'Brien <obrienjw at upenn.edu> wrote:
>>
>> A thing that is still causing me some grinding of gears---and this feels
>> like I may be wandering into unknowing-n00b territory---is the use of
>> the term "glue records" in this context. This is a Verisign business
>> logic-based process step, not a DNS protocol-based one. Right?
> 
> There are two layers of protocol here: DNS and EPP.
> [...]
> One of the weirder features of EPP is that it has two mutually exclusive
> data models. https://tools.ietf.org/html/rfc5731#section-1.1
> [...]
>> What then is the purpose of the consistency checks among COM, NET, and
>> EDU from Verisign's perspective? Is there any possibility of relaxing or
>> removing them? What harm is prevented that names and name servers in
>> other TLDs remain susceptible to?
> 
> [...]
> There is a glue-related provisioning error that Verisign-style registries
> can avoid:
> [...]
> Verisign also lets (or used to let) you set up a situation like
> 
> 	example.com  NS  ns.example.net
> 	example.net  NS  ns.example.com
> 
> but I believe that no longer works.
> 
> Of course, if you don't have a shared registry then a situation like
> 
> 	example.co.uk  NS  ns.example.ac.uk
> 	example.ac.uk  NS  ns.example.co.uk
> 
> can't be dealt with as part of the registry data model. But errors like
> this can be detected by provisioning-time checks, both within and across
> registries, so the host objects in the shared registry don't provide much
> benefit.

Tony,

That was a great write-up and very enlightening. Thank you.

I will give a nod to Andrew Sullivan for being the first to clue me in
to the existence of EPP off-list.

For those on the list who have been waiting breathlessly to hear about
the next chapter in this little saga, wait no more! My .edu registrar
has informed me that they are unable to register server names with
greater than three labels. So... The saga continues?

-- 
John W. O'Brien
University of Pennsylvania
OpenPGP key ID:
    0xD97D135B02EC753B

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20181205/ab53604e/attachment.sig>