Como sei quando meus conjuntos de registros Route53 se tornam efetivos?

Question

Portanto, adicionei meu domínio ao Route53 e atualizei os servidores de nomes dos domínios para o do Route53.

Eu adicionei os conjuntos de registros (A, MX e TXT) de que preciso.

Como sei quando esses registros DNS são eficazes ou apenas espero e continuo verificando who.is para o domínio?

    

Answer 1

Joe está apontando que, se você ainda não tiver substituído os servidores NS de seu domínio pelo registrador de domínios, precisará fazer isso antes que qualquer coisa entre em vigor (os servidores da AWS devem ser seus servidores NS autorizados para o seu domínio).

Assim, um whois para o seu domínio deve mostrar os novos servidores de nomes, uma vez propagados. Eles devem ser algo parecido com isto perto do fundo de um 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

Uma vez definido, sempre que você criar novos registros em sua zona, eles devem se tornar visíveis dentro de um curto período após alguma propagação. Por exemplo, se você acabou de comprar um domínio no GoDaddy, criou uma zona de stub no Route53 para o seu domínio e assume os valores do servidor NS que atribui a você e os coloca de volta no registro de domínio com o GoDaddy, todos os novos registros adicionados devem estar visíveis 15-20 minutos normalmente, ou talvez até uma hora.

O processo de propagação, no entanto, está totalmente fora de suas mãos depois que você publica novos valores. Portanto, você deve sempre fazer uso inteligente do TTL.

Para garantir que seus valores se propagaram, você deve se familiarizar com a linha de comando e usar uma ferramenta como dig ou nslookup para verificar:

dig host.domain.com

Deve dar um resultado assim. Meu comando está na primeira linha:

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

E o nslookup ficaria assim. Meu comando está na primeira linha:

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

    

Answer 2

Depois de alterar a delegação do seu domínio por meio de seu registrador, há essencialmente dois atrasos separados.

1. A alteração que você fez através da interface de gerenciamento de seu registrador geralmente não é publicada no DNS imediatamente. O atraso pode depender tanto do registrador particular quanto das políticas do registro.

2. Após as alterações terem sido publicadas no DNS, pode levar algum tempo (até o TTL) antes que qualquer dado armazenado anteriormente em cache em qualquer servidor de resolução arbitrária tenha expirado no cache. Seus novos dados serão pesquisados somente se ainda não houver uma resposta antiga no cache.

Em relação a 1. você pode simplesmente consultar os servidores de nomes diretamente autoritários para ver se os registros publicados atualmente foram atualizados. Ao consultar os servidores autoritativos diretamente, não há armazenamento em cache, portanto, isso é bastante simples.

Um comando como dig +trace +add example.com NS pode ser conveniente, já que seguirá a cadeia de delegações desde a raiz até sua zona, eliminando a necessidade de descobrir os servidores oficiais ao longo do caminho.

Por exemplo,

$ 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

$ 

Isso também lhe dá a chance de confirmar que a delegação na zona pai corresponde aos registros oficiais ( NS e A / AAAA , se aplicável).

Em relação a 2. quando você pode ver que suas mudanças foram publicadas, você pode calcular o pior caso para quando os servidores de nomes bem comportados usarem os novos dados adicionando o TTL à hora atual.

    

Answer 3

Eu uso check-host.

Veja um exemplo:

link

Isto irá procurar o seu anfitrião a partir de vários locais em todo o mundo em paralelo.

Você obtém os resultados, o tempo gasto (latência) e os valores de TTL.