Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

So I have added my domain to Route53 and updated the name servers of the domains to that of Route53.

I have added the record sets (A, MX and TXT) that I need.

How do I know when these DNS records are effective or do I just wait and keep on checking who.is for the domain?
enter image description here

share|improve this question
2  
Updating your name server information with the parent servers (the gTLD servers) is the responsibility of your registrar so you should ask them how often they send updates to the parent servers. –  joeqwerty Nov 30 '12 at 15:36

3 Answers 3

up vote 2 down vote accepted

Joe is pointing out that if you haven't already replaced your domain's NS servers with the domain registrar, you need to do that before anything will take effect (AWS's servers must be your authoritative NS servers for your domain).

So a whois for your domain should then show you the new name servers, once propagated. They should look something like this near the bottom of a whois:

  Name Server:NS-1315.AWSDNS-36.ORG
  Name Server:NS-99.AWSDNS-12.COM
  Name Server:NS-765.AWSDNS-31.NET
  Name Server:NS-1970.AWSDNS-54.CO.UK

Once that's set, whenever you create new records in your zone they should become visible within a short period after some propagation. For example, if you just bought a domain on GoDaddy, created a stub zone in Route53 for your domain and take the NS server values they assign you and drop them back into the domain record with GoDaddy, any new records you add should be visible within 15-20 mins normally, or perhaps up to an hour.

The process of propagation, however, is entirely out of your hands once you've published new values. So you should always make smart use of TTL.

To make sure your values have propagated, you should get comfortable with the command line and use a tool like dig or nslookup to check:

dig host.domain.com

Should give you a result like this. My command is on the first line:

myhostmachine ~ # dig www.acme.com

; <<>> DiG 9.7.3 <<>> www.acme.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9821
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.acme.com.          IN  A

;; ANSWER SECTION:
www.acme.com.       16390   IN  A   216.27.178.28

;; Query time: 30 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Dec 13 11:53:09 2012
;; MSG SIZE  rcvd: 46

And nslookup would look like this. My command is on the first line:

myhostmachine # nslookup www.acme.com
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   www.acme.com
Address: 216.27.178.28
share|improve this answer
    
Regarding the bit that was added regarding whois, I think it's important to note that whois is an entirely separate system which is updated independently. Whois is essentially a database where you can search and find informational text, if it's important to find what is actually published in DNS at this very moment it's more accurate to simply look this up in DNS. –  Håkan Lindqvist Jul 24 at 1:50
    
@HåkanLindqvist yes, in general I agree -- and of course you can confirm those current settings via a dig NS or such, but I suggested whois since that lets you know if the records have propagated well or not. It's probably best to say there are several checks available, and they each have their own advantages. –  Neal Jul 24 at 14:56
    
Whois will not actually tell you anything about the state in dns, though. There is no guarantee that whois data and the dns records at the authoritative servers update at the same time. (It's actually rather common that they do not.) –  Håkan Lindqvist Jul 24 at 15:20
    
I understand that. Of course. But it's a fairly good indicator as to whether it's propagated out. Just like I can check a particular DNS record at my SOA host, AND I can check a particular DNS record at 8.8.8.8 to see if things are generally matching. Yes, sometimes they don't match but that might be a good indicator that I should check deeper. I think you and I must be answering separate concerns. –  Neal Jul 24 at 15:30

I use check-host.

Here's an example:

http://check-host.net/check-dns?host=example.com

This will lookup your host from multiple locations around the world in parallel.

You get the results, the time it took (latency) as well as the TTL values.

share|improve this answer

After changing the delegation of your domain through your registrar there are essentially two separate delays.

  1. The change you have made through the management interface of your registrar is generally not published in DNS immediately. The delay may depend on both the particular registrar as well as the policies of the registry.

  2. After your changes have been published in DNS, it may take some time (up to TTL) before any previously cached data at any arbitrary resolver server has expired from the cache. Your new data will only be looked up if there is not already an old response in the cache.

Regarding 1. you can simply query the authoritative directly nameservers to see if the currently published records have been updated. When querying the authoritative servers directly there is no caching, so this is pretty straightforward.

A command like dig +trace +add example.com NS can be convenient as that will follow the chain of delegations all the way from the root to your zone, eliminating the need for you to figure out the authoritative servers along the path.

E.g.

$ dig +trace +add example.com NS

; <<>> DiG 9.8.3-P1 <<>> +trace +add example.com NS
;; global options: +cmd
.           213343  IN  NS  h.root-servers.net.
.           213343  IN  NS  i.root-servers.net.
.           213343  IN  NS  a.root-servers.net.
.           213343  IN  NS  b.root-servers.net.
.           213343  IN  NS  k.root-servers.net.
.           213343  IN  NS  f.root-servers.net.
.           213343  IN  NS  c.root-servers.net.
.           213343  IN  NS  e.root-servers.net.
.           213343  IN  NS  g.root-servers.net.
.           213343  IN  NS  d.root-servers.net.
.           213343  IN  NS  m.root-servers.net.
.           213343  IN  NS  j.root-servers.net.
.           213343  IN  NS  l.root-servers.net.
;; Received 228 bytes from 192.168.1.1#53(192.168.1.1) in 204 ms

com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
a.gtld-servers.net. 172800  IN  A   192.5.6.30
a.gtld-servers.net. 172800  IN  AAAA    2001:503:a83e::2:30
b.gtld-servers.net. 172800  IN  A   192.33.14.30
b.gtld-servers.net. 172800  IN  AAAA    2001:503:231d::2:30
c.gtld-servers.net. 172800  IN  A   192.26.92.30
d.gtld-servers.net. 172800  IN  A   192.31.80.30
e.gtld-servers.net. 172800  IN  A   192.12.94.30
f.gtld-servers.net. 172800  IN  A   192.35.51.30
g.gtld-servers.net. 172800  IN  A   192.42.93.30
h.gtld-servers.net. 172800  IN  A   192.54.112.30
i.gtld-servers.net. 172800  IN  A   192.43.172.30
j.gtld-servers.net. 172800  IN  A   192.48.79.30
k.gtld-servers.net. 172800  IN  A   192.52.178.30
l.gtld-servers.net. 172800  IN  A   192.41.162.30
;; Received 501 bytes from 192.36.148.17#53(192.36.148.17) in 179 ms

example.com.        172800  IN  NS  a.iana-servers.net.
example.com.        172800  IN  NS  b.iana-servers.net.
a.iana-servers.net. 172800  IN  A   199.43.132.53
a.iana-servers.net. 172800  IN  AAAA    2001:500:8c::53
b.iana-servers.net. 172800  IN  A   199.43.133.53
b.iana-servers.net. 172800  IN  AAAA    2001:500:8d::53
;; Received 165 bytes from 2001:503:231d::2:30#53(2001:503:231d::2:30) in 150 ms

example.com.        172800  IN  NS  b.iana-servers.net.
example.com.        172800  IN  NS  a.iana-servers.net.
a.iana-servers.net. 1800    IN  A   199.43.132.53
a.iana-servers.net. 1800    IN  AAAA    2001:500:8c::53
b.iana-servers.net. 1800    IN  A   199.43.133.53
b.iana-servers.net. 1800    IN  AAAA    2001:500:8d::53
;; Received 165 bytes from 2001:500:8d::53#53(2001:500:8d::53) in 211 ms

$ 

This also gives you a chance to confirm that the delegation in the parent zone matches your authoritative records (NS and A/AAAA if applicable).

Regarding 2. when you can see that your changes have been published you can calculate the worst-case for when well-behaved nameservers will use the new data by adding the TTL to the current time.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.