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

Tony Finch dot at dotat.at
Tue Dec 4 16:15:57 UTC 2018

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. EPP is the protocol
that enables the shared registry model, with many registras selling
domains in many registries.

Strictly speaking, glue records are a DNS notion. EPP has the concepts of
"domains" and "hosts"; when a registry is publising a zone, the glue
records in the zone are generated from the host objects.

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

The simpler (but sadly more rare) model is that domains have hosts as
attributes, and hosts only have addresses when they are needed for glue,
i.e. thet are subordinate to their domain.

The more complicated model (which seems to date back to the days of the
Network Solutions monopoly) is to have separate host objects, which need
to be created separately from the domains that use them. Host objects get
excitingly complicated and obscure in various edge cases wrt ownership
permissions and error handling, as you have discovered.

> 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?

Sadly it seems history makes it practically impossible for Verisign to
switch to the simpler EPP data model.

In the past, the ATLAS name server software used by Verisign would include
cross-zone name server IP addresses in its responses quite freely. (I seem
to remember a reletively recent announcement about it being changed to
keep com/net/edu more separate, though I can't find it now.) In principle,
including more glue can make lookups faster, since resolvers have to do
less work to chase down name server IP addresses. (The simpler registry
model is at a slight disadvantage here.) But cross-zone com/net glue
probably shouldn't work with modern resolvers that are more careful to
avoid poisoning risks.

There is a glue-related provisioning error that Verisign-style registries
can avoid: if you foolishly set up two domains that depend on each other
for name servers

	example1.com  NS  ns.example2.com
	example2.com  NS  ns.example1.com

it works with host+domain registries but not domain-only registries.

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

f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
South Utsire: Northwesterly 6 to gale 8, becoming variable 4. Rough or very
rough, becoming moderate or rough. Wintry showers. Good, occasionally poor.

More information about the dns-operations mailing list