OK, I seem to have missed identifying a finer point. Both registrars (old and new) also host the DNS records for the domain (actually several domains). My question is which registrar (both are fully configured) will ultimately win at the root server, and how is this determined? The mail and web servers are up and running, and their IP addresses are not going to change. I just want to guarantee that when the account on registrar ABC is fully removed that registrar XYZ will begin DNS announcements to the root servers. Thank you for the responses so far, as well as the pointers to additional info/faq/rfc/etc. -Jim P.

-----Original Message----- From: Jim Popovitch Sent: Saturday, 28 June, 2003 12:09 To: nanog@merit.edu Subject: DNS announcement question

I have a question about the way DNS records are announced/handled. Thank you in advance for any insight into this, and I hope this isn't too far off topic for discussion here.

Background: - I have a domain whose MX and DNS is handled by registrar ABC and I am moving that domain to registrar XYZ.

- I have verified (via dig) the proper config on the new registrar.

- This has nothing to do with donotcall.gov ;)

Questions: 1) How does one registrar 'win out' over a second registrar when updating root servers?

2) How can I verify that the domain will be properly 'announced' to the root servers by the new registrar?

-Jim P.

On Saturday 28 June 2003, at 12:08, Jim Popovitch wrote:

Questions: 1) How does one registrar 'win out' over a second registrar when updating root servers?

It's important not to confuse registry services (in which a central registry of names and metadata is maintained by various authorised parties) and name service. They are related, but different. This confuses people, because single companies frequently provide both registry services and nameserver services. Here's a registry answer to your question: In the ICANN-model registry/registrar/registrant structure (which is used for most gTLDs and also, to varying degrees of approximation, by various ccTLDs) a single domain is sponsored by a single registrar. Only the sponsoring registrar is able to influence the way that the delegation for the domain is published in the registry's zone. The process of changing the sponsoring registrar is called a transfer operation, and is performed by either the losing or winning registrar at the request of the registrant. Here's a nameserver answer to your question: The parent (superordinate) zone will contain a delegation to a set of nameservers which corresponds to your domain name. The nameservers specified therein will be used by recursive resolvers to locate nameservers which are authoritative for your zone, in order to resolve queries which fall within your domain. Other nameservers may purport to speak authoritatively for your zone, but unless the delegation in the parent zone includes them in the NS set, a recursive lookup will not find them.

2) How can I verify that the domain will be properly 'announced' to the root servers by the new registrar?

Here's a registry answer to this question: Find some way of querying the registry in question for your domain (for com/net domains, you might try using whois against whois.crsnic.net; in general, for registry zone $z you can take advantage of Centergate's very useful whois-servers.net domain and try a whois query against $z.whois-servers.net). You should see some indication of the sponsoring registrar, and other metadata which you can verify.

[jabley@buffoon]% whois -h org.whois-servers.net isc.org ... tedious legal rambling... Domain ID:D2338103-LROR Domain Name:ISC.ORG Created On:04-Apr-1994 04:00:00 UTC Last Updated On:05-Mar-2002 02:24:11 UTC Expiration Date:05-Apr-2004 04:00:00 UTC ... etc, etc

Here's a nameserver answer to your question: Check the parent zone for the delegation, and ensure that your domain has been delegated to the right nameservers. To do that, find a nameserver which is authoritative for the parent zone and send it a query for a name under your domain. For added credit, don't request recursion when you send the query.

[jabley@buffoon]% dig ns org.

; <<>> DiG 8.3 <<>> ns org. ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; org, type = NS, class = IN

;; ANSWER SECTION: org. 5d23h59m51s IN NS L7.NSTLD.COM. org. 5d23h59m51s IN NS M5.NSTLD.COM. org. 5d23h59m51s IN NS A7.NSTLD.COM. org. 5d23h59m51s IN NS C5.NSTLD.COM. org. 5d23h59m51s IN NS E5.NSTLD.COM. org. 5d23h59m51s IN NS F7.NSTLD.COM. org. 5d23h59m51s IN NS G7.NSTLD.COM. org. 5d23h59m51s IN NS I5.NSTLD.COM. org. 5d23h59m51s IN NS J5.NSTLD.COM.

;; Total query time: 2 msec ;; FROM: buffoon.automagic.org to SERVER: default -- 127.0.0.1 ;; WHEN: Sat Jun 28 13:13:53 2003 ;; MSG SIZE sent: 21 rcvd: 183

[jabley@buffoon]% dig @l7.nstld.com isc.org SOA +norecurse

; <<>> DiG 8.3 <<>> @l7.nstld.com isc.org SOA +norecurse ; (1 server found) ;; res options: init defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28750 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUERY SECTION: ;; isc.org, type = SOA, class = IN

;; AUTHORITY SECTION: isc.org. 2D IN NS NS-EXT.VIX.COM. isc.org. 2D IN NS NS1.GNAC.COM.

;; Total query time: 16 msec ;; FROM: buffoon.automagic.org to SERVER: l7.nstld.com 192.41.162.36 ;; WHEN: Sat Jun 28 13:14:05 2003 ;; MSG SIZE sent: 25 rcvd: 76

[jabley@buffoon]%

If the DNS speak in this message scares you, then either don't worry about it or buy and digest the Cricket book ("DNS and BIND", ISBN 0596001584). It's very readable and easy to follow, even with little or no prior knowledge of the DNS. Joe