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

John W.O'Brien obrienjw at upenn.edu
Tue Dec 4 15:31:08 UTC 2018


Thank you for the time you took to explain glue records.

On 2018/12/04 09:27, Mariano Absatz - gmail wrote:
> --
> Mariano Absatz - El Baby
> www.clueless.com.ar <http://www.clueless.com.ar>
> On Tue, 4 Dec 2018 at 09:50, John W.O'Brien <obrienjw at upenn.edu
> <mailto:obrienjw at upenn.edu>> wrote:
>     Hi Duane,
>     Thank you for chiming in on this. This information is convergent with
>     what I've been learning via off-list responses and from tech support
>     contacts at various organizations.
>     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?
> Hi John,
> "glue record" /is/ a DNS protocol-based term (and an old one indeed).
> You need a glue record when you do in-zone delegations, for example, if
> you want to delegate the domain example.com <http://example.com> to
> ns1.example.com <http://ns1.example.com> and
> ns2.example.com <http://ns2.example.com> if it weren't for the glue
> records you get yourself into
> a chicken-and-egg problem.
> If you just put the delegation (NS) records in the .com authoritative
> servers, a resolver querying any of those about www.example.com
> <http://www.example.com> would
> get a response with AUTHORITY set to ns1.example.com
> <http://ns1.example.com> and ns2.example.com <http://ns2.example.com>.
> Then the resolver tries to resolve ns1.example.com
> <http://ns1.example.com> and, querying the
> .com name servers it gets a response with AUTHORITY set to
> ns1.example.com <http://ns1.example.com> and ns2.example.com
> <http://ns2.example.com>.
> To find out the IP address of ns1.example.com <http://ns1.example.com>
> you first need to know the
> IP address of ns1.example.com <http://ns1.example.com>. Not good.
> Glue records are "A" or "AAAA" records for a child (delegated) zone that
> you put in the parent zone regardles that the parent has no longer
> authority on the now delegated zone. Even when these records are not
> authoritative in the parent server, they allow you to break the circle.
> In this case, in the .com zone you'd put the "A" and "AAAA" records for
> ns1.example.com <http://ns1.example.com> and ns2.example.com
> <http://ns2.example.com>. For this to happen, you must inform
> your registrar about the IP addresses of your in-zone name servers. It's
> not a Verisign specific issue. Any registry or registrar should allow
> for glue records.
> Given your specific case, my guess is that Verisign may be overzealous
> requiring anyone to register any authoritative name server within their
> TLDs that serves any domain within their TLDs.
> If uphs{1,2,3}.uphs.upenn.edu <http://uphs.upenn.edu> are *not* used to
> serve anything under
> upenn.edu <http://upenn.edu> glue records are not needed.
> What's more, if uphs{1,2,3}.uphs.upenn.edu <http://uphs.upenn.edu> were
> to serve uphs.upenn.edu <http://uphs.upenn.edu>,
> you could place glue records for these servers in the upen.edu
> <http://upen.edu> name
> servers (assuming the name servers for upenn.edu <http://upenn.edu> are
> not within
> uphs.upenn.edu <http://uphs.upenn.edu>), but my guess is that Verisign
> is overzealous just to
> prevent you from shooting your own foot (that is you, me or any DNS
> administrator).
>     I have succeeded in delegating a .org name to a name server in each of
>     the .edu and .net domains, and a .net name to a .org NS, and a .com name
>     to a .us NS, and none of the receiving servers are registered. 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?
>     On 2018/12/03 16:55, Wessels, Duane wrote:
>     > John,
>     >
>     > .com, .net, and .edu share the same backend registry database. 
>     The message that you're getting when attempting to register the .net
>     and .com domains is saying that there should be glue records for
>     uphs{1,2,3}.uphs.upenn.edu <http://uphs.upenn.edu> in that shared
>     database.
>     >
>     > So you would have to go to your .edu registrar and add these hosts
>     under the upenn.edu <http://upenn.edu> account in order to make it work.
>     >
>     > DW
>     >
>     >
>     > On 12/3/18, 10:35 AM, "dns-operations on behalf of John
>     W.O'Brien" <dns-operations-bounces at dns-oarc.net
>     <mailto:dns-operations-bounces at dns-oarc.net> on behalf of
>     obrienjw at upenn.edu <mailto:obrienjw at upenn.edu>> wrote:
>     >
>     >     Good day DNS Operators,
>     >     
>     >     I am having some trouble making uphs{1,2,3}.uphs.upenn.edu
>     <http://uphs.upenn.edu> authoritative
>     >     for a number of domains in net and com. The registrar claims
>     that the
>     >     name servers have to be "registered" but doesn't appear to
>     provide a
>     >     mechanism for doing so. There is already appropriate glue in
>     edu for the
>     >     upenn.edu <http://upenn.edu> NS, and in upenn.edu
>     <http://upenn.edu> for the uphs.upenn.edu <http://uphs.upenn.edu>
>     NS, and they are
>     >     all happily answering queries for those domains. I'm struggling to
>     >     understand what it means to be registered and how to do it.
>     >     
>     >     Could someone wiser than I in the ways of registrars and TLD
>     operators
>     >     shed some light on my predicament?

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

-------------- 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/20181204/8fae041c/attachment.sig>

More information about the dns-operations mailing list