Re: [OT] Domain Name Registrars

Duane Whitty wrote:
Doug Barton wrote:
Troy Settle wrote:


Here's the thing for name servers (at least as far as I understand
it)...


With all due respect, the problem with postings like this is that it
actually slows down the process of people finding out the truth for
themselves by perpetuating misinformation. It's far better to either do
the research and post accurate information, or avoid posting.


the glue records must exist in the root servers for each registry.


A) The only "root servers" are those that serve the root zone. What
you're referring to are Top Level Domain (TLD) name servers.

To clarify for myself, the root name servers are not authoritative for
(most of) the TLDs.

All of the roots except for j are authoritative for ARPA. That's a legacy
issue, and the goal is for it to be moved to its own set of servers "some
day." In addition to 6 other servers; a, b, e, g, and h root are all
authoritative for MIL. This zone should be moved off the roots as well, but
who knows when/if that should happen. The root zone servers are not
authoritative for any other zones (other than the root zone itself, of
course.) This isn't particularly interesting for 99.9999% of the Internet
though, since Joe average Internet user is not going to be able to add a
domain to those zones.

The authoritative name servers for zones represented
by the TLDs are the ones to which the root name servers have delegated
authority to for those zones. So there are authoritative name servers
for the zones such as .ca, .gc.ca, .com etc.

Yes, basically.

B) Policies on whether name server IP records are necessary for domain
registration vary by registry. There is no hard and fast rule. C)
"Glue" is a DNS term of art that refers specifically to IP addresses
for servers whose hostnames are IN the zone they serve. For example, if
you have the following NS records:

example.org. NS ns1.example.org. example.org. NS
ns2.example.org.

Then glue records are _required_ in the ORG TLD name servers. Otherwise
there is no way for anyone to reach your servers.

So then what the registrars are doing (or supposed to be doing) is
providing A and NS records for the name servers in my parent zone which
point to my primary name servers and secondary name servers?

NS records yes, in all cases. The policies for A records vary from TLD
registry to TLD registry, and from registrar to registrar.

This then is the "glue" which makes recursive queries possible.

Not entirely accurate. As I said in a previous message, "glue" is a DNS term
of art that means precisely an A (or AAAA) record for a name server hostname
that is in the same zone (or a descendant of the same zone) that is being
delegated. So, in the following example:

example.org. NS ns1.example.org.

A glue record would be required.

So, and pardon my verbosity, when a resolver needs to resolve dwlabs.ca,
assuming it doesn't have the data cached, it queries one of
ca0[1,2,4,5,6].cira.ca or ns-ext.isc.org,

Good so far, as those are the name servers which are authoritative for the
CA zone.

which then responds with the
names and ip addresses of the authoritative name servers for dwlabs.ca.
Am I correct?

Well, let's see:

; <<>> DiG 9.3.2 <<>> @ca01.cira.ca dwlabs.ca A
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10584
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;dwlabs.ca. IN A

;; AUTHORITY SECTION:
dwlabs.ca. 86400 IN NS helsinki.cgc.gc.ca.
dwlabs.ca. 86400 IN NS dwpc.dwlabs.ca.

;; ADDITIONAL SECTION:
dwpc.dwlabs.ca. 86400 IN A 24.224.199.230

;; Query time: 116 msec
;; SERVER: 192.228.27.11#53(192.228.27.11)
;; WHEN: Mon May 22 13:05:26 2006
;; MSG SIZE rcvd: 92

A couple of things to notice here. First, I did a query for an A record,
since that is what most resolvers would do. The CA name server responded
with a delegation record for dwlabs.ca, and a glue record for dwpc.dwlabs.ca
since that hostname is in the zone that is being delegated.

So no glue, but an NS record as in example.com. IN NS ns1.dwlabs.ca.
?

Voila!

In this case the response to the resolver query from the .com
authoritative name server will be that the unauthoritative answer is
ns1.dwlabs.ca. Authoritative answers can be found at
ca0[1,2,4,5,6].cira.ca or ns-ext.isc.org. ? Because of this they don't
need A records for my domain, if I am correct.

Well, kind of. You can easily get confused here because "authority" is one
of those terms of art that actually can mean different things depending on
where and how it's applied. Better to refer to what comes from the parent as
a delegation record, and avoid issues of authority in this situation.

hope this helps,

Doug

--

This .signature sanitized for your protection

_______________________________________________
freebsd-isp@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isp
To unsubscribe, send any mail to "freebsd-isp-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: need help,not your average dns problem
    ... thanks for the reply but no I do not have a root zone and it should not be a ... resolve names via root servers. ... AD zones on these Servers and all dns requests they cannot resolve ... When moved to Windows Active Directory 7 years ago, ...
    (microsoft.public.windows.server.dns)
  • Re: Problems with named default configuration in 6-STABLE
    ... transfer the zone, the hints mechanism is still in the comments. ... with overall root traffic for the root zone, ... I should add for the sake of completeness that not every DNS ... have 5 servers to choose from (and we only need one good transfer to ...
    (freebsd-stable)
  • Re: Problems with named default configuration in 6-STABLE
    ... transfer the zone, the hints mechanism is still in the comments. ... with overall root traffic for the root zone, ... slaving the root zone will make you still being able to resolve DNS ... servers worldwide being unreachable. ...
    (freebsd-stable)
  • Re: Server 2003 DNS ADI import or sync? WHat are my options
    ... ROOT zone populate to CORP_A, and not the other way around? ... that all of the sudden, in the replication, the CORP_A sources tells all the ... explained because the Replication Scope used on the Root servers is only ...
    (microsoft.public.windows.server.dns)
  • Re: [OT] Domain Name Registrars
    ... the root name servers are not authoritative for the TLDs. ... name servers have delegated authority to for those zones. ... that for the .mil zone four of the root servers are authoritative, ... then the .com registry must have the glue ...
    (freebsd-isp)