Problemas com a propagação do DNS 10 dias após a alteração

A equipe de engenharia com a qual trabalho trabalhava no processo de mover equipamentos de um datacenter para outro. Dez dias atrás, movemos um de nossos servidores de nomes com autoridade para os domínios de nossos clientes (ns1.faithhiway.com) e atualizamos seu endereço IP com seu respectivo provedor DNS (register.com) para apontar para o novo datacenter. Todos os testes realizados mostram que esse servidor de nomes está sendo executado corretamente em seu novo local e, quando consultado, retornando a resposta correta para todos os domínios pelos quais é responsável.

O problema é que, depois de 72 horas, ainda estávamos vendo mais atividade DNS em seu antigo endereço IP do que no novo. A boa notícia é que mantivemos um servidor de nomes respondendo no antigo endereço IP por enquanto, para que não ocorram problemas com os domínios pelos quais o servidor de nomes é responsável, mas o objetivo é retirá-lo o mais rápido possível. Como você pode ver no WhatsMyDNS.net , uma quantidade razoável de propagação ocorreu nos últimos 10 dias desde que fizemos essa alteração, mas ainda existem alguns locais que relatam nosso IP original.

insira a descrição da imagem aqui

Considerando que o TTL é de apenas 3600 com os servidores de nomes responsáveis por esse domínio, não faz sentido para mim ou para os outros engenheiros que trabalham comigo que estamos com esse problema.

Agora, se eu executar uma verificação de DNS usando um dos servidores DNS do Register.com (servidores de nomes diretos para faithhiway.com), obtenho o seguinte resultado (correto):

# dig @dns01.gpn.register.com ns1.faithhiway.com A

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @dns01.gpn.register.com. ns1.faithhiway.com A
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43232
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5

;; QUESTION SECTION:
;ns1.faithhiway.com.  IN A

;; ANSWER SECTION:
ns1.faithhiway.com. 3601 IN A 206.127.2.71

;; AUTHORITY SECTION:
faithhiway.com.  3600 IN NS dns01.gpn.register.com.
faithhiway.com.  3600 IN NS dns02.gpn.register.com.
faithhiway.com.  3600 IN NS dns03.gpn.register.com.
faithhiway.com.  3600 IN NS dns04.gpn.register.com.
faithhiway.com.  3600 IN NS dns05.gpn.register.com.

;; ADDITIONAL SECTION:
dns01.gpn.register.com. 3600 IN A 98.124.192.1
dns02.gpn.register.com. 3600 IN A 98.124.197.1
dns03.gpn.register.com. 3600 IN A 98.124.193.1
dns04.gpn.register.com. 3600 IN A 69.64.145.225
dns05.gpn.register.com. 3600 IN A 98.124.196.1

;; Query time: 50 msec
;; SERVER: 98.124.192.1#53(98.124.192.1)
;; WHEN: Thu Jan 27 15:16:57 2011
;; MSG SIZE  rcvd: 269

Apenas como referência, eis os resultados quando a mesma consulta é verificada em uma variedade de servidores DNS públicos:

Google:

# dig @8.8.8.8 ns1.faithhiway.com A

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @8.8.8.8. ns1.faithhiway.com A
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12773
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.faithhiway.com.  IN A

;; ANSWER SECTION:
ns1.faithhiway.com. 997 IN A 206.127.2.71

;; Query time: 29 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Jan 27 15:17:31 2011
;; MSG SIZE  rcvd: 52

Nível 3:

# dig @4.2.2.1 ns1.faithhiway.com A

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @4.2.2.1. ns1.faithhiway.com A
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46505
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.faithhiway.com.  IN A

;; ANSWER SECTION:
ns1.faithhiway.com. 2623 IN A 206.127.2.71

;; Query time: 7 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Thu Jan 27 15:18:35 2011
;; MSG SIZE  rcvd: 52

Verizon:

# dig @151.197.0.38 ns1.faithhiway.com A

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @151.197.0.38. ns1.faithhiway.com A
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32658
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.faithhiway.com.  IN A

;; ANSWER SECTION:
ns1.faithhiway.com. 3601 IN A 206.127.2.71

;; Query time: 81 msec
;; SERVER: 151.197.0.38#53(151.197.0.38)
;; WHEN: Thu Jan 27 15:19:15 2011
;; MSG SIZE  rcvd: 52

Cisco:

# dig @64.102.255.44 ns1.faithhiway.com A

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @64.102.255.44. ns1.faithhiway.com A
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39689
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.faithhiway.com.  IN A

;; ANSWER SECTION:
ns1.faithhiway.com. 3601 IN A 206.127.2.71

;; AUTHORITY SECTION:
faithhiway.com.  3600 IN NS dns01.gpn.register.com.
faithhiway.com.  3600 IN NS dns04.gpn.register.com.
faithhiway.com.  3600 IN NS dns05.gpn.register.com.
faithhiway.com.  3600 IN NS dns02.gpn.register.com.
faithhiway.com.  3600 IN NS dns03.gpn.register.com.

;; Query time: 105 msec
;; SERVER: 64.102.255.44#53(64.102.255.44)
;; WHEN: Thu Jan 27 15:20:05 2011
;; MSG SIZE  rcvd: 165

OpenDNS:

# dig @208.67.222.222 ns1.faithhiway.com A

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @208.67.222.222. ns1.faithhiway.com A
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12328
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.faithhiway.com.  IN A

;; ANSWER SECTION:
ns1.faithhiway.com. 169507 IN A 207.200.19.162

;; Query time: 6 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Thu Jan 27 15:19:29 2011
;; MSG SIZE  rcvd: 52

SpeakEasy:

# dig @66.93.87.2 ns1.faithhiway.com A

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @66.93.87.2. ns1.faithhiway.com A
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9342
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.faithhiway.com.  IN A

;; ANSWER SECTION:
ns1.faithhiway.com. 169323 IN A 207.200.19.162

;; Query time: 69 msec
;; SERVER: 66.93.87.2#53(66.93.87.2)
;; WHEN: Thu Jan 27 15:19:51 2011
;; MSG SIZE  rcvd: 52

Como você pode ver acima, a maioria das consultas está retornando o resultado correto. Mas alguns (OpenDNS e SpeakEasy nos exemplos acima) ainda estão mostrando o endereço IP antigo. Considerando o tempo que passou, parece-me óbvio que cometemos um erro e não lidamos completamente com as alterações de DNS do nosso lado (provavelmente) ou há um problema com o provedor de DNS desse domínio (Registrar ) ou com alguns dos servidores DNS em estado selvagem (bastante improvável).

Algum conselho sobre como posso proceder com isso?

ATUALIZAÇÃO (31 de janeiro de 2011):

Primeiro, peço desculpas pelo tamanho da pergunta original e desta atualização. Eu pensei em remover parte do excesso do post original, mas, caso esse problema e sua solução sejam úteis para outra pessoa, no futuro, deixarei tudo como está.

Enfim, estive pesquisando um pouco mais sobre esse problema e descobri a seguinte ocorrência interessante. Ao executar uma verificação nos registros de cola do faithhiway.com, sempre resolvo corretamente, se eu for verificar um domínio do cliente (onde o ns1.faithhiway.com é autoritário), recebo uma resposta estranha. Parece que os servidores raiz estão retornando o nsX.faithhiway.com como seus endereços IP antigos ainda (em Seção Adicional). Como ainda temos um servidor respondendo às consultas DNS, o rastreamento termina e retorna os endereços IP corretos como a etapa final (novamente, em Seção Adicional). O exemplo abaixo usa um dos domínios que usamos que usa ns1.faithhiway.com como seu servidor DNS autoritativo.

# dig +trace +nosearch +all +norecurse ignitemail.com

; <<>> DiG 9.2.4 <<>> +trace +nosearch +all +norecurse ignitemail.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46856
;; flags: qr ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;.    IN NS

;; ANSWER SECTION:
.   7986 IN NS a.root-servers.net.
.   7986 IN NS b.root-servers.net.
.   7986 IN NS c.root-servers.net.
.   7986 IN NS d.root-servers.net.
.   7986 IN NS e.root-servers.net.
.   7986 IN NS f.root-servers.net.
.   7986 IN NS g.root-servers.net.
.   7986 IN NS h.root-servers.net.
.   7986 IN NS i.root-servers.net.
.   7986 IN NS j.root-servers.net.
.   7986 IN NS k.root-servers.net.
.   7986 IN NS l.root-servers.net.
.   7986 IN NS m.root-servers.net.

;; Query time: 39 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jan 31 09:22:17 2011
;; MSG SIZE  rcvd: 228

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16325
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14

;; QUESTION SECTION:
;ignitemail.com.   IN A

;; AUTHORITY SECTION:
com.   172800 IN NS h.gtld-servers.net.
com.   172800 IN NS m.gtld-servers.net.
com.   172800 IN NS i.gtld-servers.net.
com.   172800 IN NS l.gtld-servers.net.
com.   172800 IN NS c.gtld-servers.net.
com.   172800 IN NS k.gtld-servers.net.
com.   172800 IN NS d.gtld-servers.net.
com.   172800 IN NS f.gtld-servers.net.
com.   172800 IN NS b.gtld-servers.net.
com.   172800 IN NS a.gtld-servers.net.
com.   172800 IN NS e.gtld-servers.net.
com.   172800 IN NS g.gtld-servers.net.
com.   172800 IN NS j.gtld-servers.net.

;; ADDITIONAL SECTION:
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

;; Query time: 64 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net)
;; WHEN: Mon Jan 31 09:22:17 2011
;; MSG SIZE  rcvd: 504

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12860
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ignitemail.com.   IN A

;; AUTHORITY SECTION:
ignitemail.com.  172800 IN NS ns1.faithhiway.com.
ignitemail.com.  172800 IN NS ns2.faithhiway.com.

;; ADDITIONAL SECTION:
ns1.faithhiway.com. 172800 IN A 207.200.19.162
ns2.faithhiway.com. 172800 IN A 207.200.50.142

;; Query time: 152 msec
;; SERVER: 192.54.112.30#53(h.gtld-servers.net)
;; WHEN: Mon Jan 31 09:22:17 2011
;; MSG SIZE  rcvd: 111

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43016
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ignitemail.com.   IN A

;; ANSWER SECTION:
ignitemail.com.  3600 IN A 206.127.2.64

;; AUTHORITY SECTION:
ignitemail.com.  3600 IN NS ns1.faithhiway.com.
ignitemail.com.  3600 IN NS ns2.faithhiway.com.

;; ADDITIONAL SECTION:
ns1.faithhiway.com. 3600 IN A 206.127.2.71
ns2.faithhiway.com. 3600 IN A 206.127.2.72

;; Query time: 25 msec
;; SERVER: 206.127.2.71#53(ns1.faithhiway.com)
;; WHEN: Mon Jan 31 09:22:18 2011
;; MSG SIZE  rcvd: 127

Realmente acho que esse é um problema que temos em algum lugar de nossa configuração, mas, se é ignorância de algo com o DNS do meu lado ou do meu colega engenheiro ou apenas um erro estúpido que cometemos, ainda não o encontrei.

opendns domain-name-system glue-record

— runlevelsix
fonte

Desejo mais perguntas foram feitas esta bem, você tem o meu upvote para a qualidade

— Jeff Atwood

Respostas:

Problema resolvido. Finalmente. Aparentemente, o Register.com não atualizou os registros de cola para o ns1 e o ns2.faithhiway.com, apesar do nosso pedido inicial de fazê-lo (e da confirmação de que isso havia sido feito).

Os testes que publiquei acima na minha atualização mostraram que, apesar da confirmação da atualização, os registros de cola não estavam se propagando corretamente. Fui em frente e forcei outra atualização em nossos registros de cola e parece que desta vez estamos vendo propagação:

# dig +trace +nosearch +all +norecurse ignitemail.com

; <<>> DiG 9.2.4 <<>> +trace +nosearch +all +norecurse ignitemail.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12706
;; flags: qr ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;.              IN  NS

;; ANSWER SECTION:
.           79883   IN  NS  a.root-servers.net.
.           79883   IN  NS  b.root-servers.net.
.           79883   IN  NS  c.root-servers.net.
.           79883   IN  NS  d.root-servers.net.
.           79883   IN  NS  e.root-servers.net.
.           79883   IN  NS  f.root-servers.net.
.           79883   IN  NS  g.root-servers.net.
.           79883   IN  NS  h.root-servers.net.
.           79883   IN  NS  i.root-servers.net.
.           79883   IN  NS  j.root-servers.net.
.           79883   IN  NS  k.root-servers.net.
.           79883   IN  NS  l.root-servers.net.
.           79883   IN  NS  m.root-servers.net.

;; Query time: 293 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jan 31 13:24:02 2011
;; MSG SIZE  rcvd: 228

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43910
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14

;; QUESTION SECTION:
;ignitemail.com.            IN  A

;; AUTHORITY SECTION:
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.

;; ADDITIONAL SECTION:
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

;; Query time: 336 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net)
;; WHEN: Mon Jan 31 13:24:03 2011
;; MSG SIZE  rcvd: 504

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44133
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ignitemail.com.            IN  A

;; AUTHORITY SECTION:
ignitemail.com.     172800  IN  NS  ns1.faithhiway.com.
ignitemail.com.     172800  IN  NS  ns2.faithhiway.com.

;; ADDITIONAL SECTION:
ns1.faithhiway.com. 172800  IN  A   206.127.2.71
ns2.faithhiway.com. 172800  IN  A   206.127.2.72

;; Query time: 2411 msec
;; SERVER: 192.43.172.30#53(i.gtld-servers.net)
;; WHEN: Mon Jan 31 13:24:06 2011
;; MSG SIZE  rcvd: 111

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50833
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ignitemail.com.            IN  A

;; ANSWER SECTION:
ignitemail.com.     3600    IN  A   206.127.2.64

;; AUTHORITY SECTION:
ignitemail.com.     3600    IN  NS  ns1.faithhiway.com.
ignitemail.com.     3600    IN  NS  ns2.faithhiway.com.

;; ADDITIONAL SECTION:
ns1.faithhiway.com. 3600    IN  A   206.127.2.71
ns2.faithhiway.com. 3600    IN  A   206.127.2.72

;; Query time: 1495 msec
;; SERVER: 206.127.2.71#53(ns1.faithhiway.com)
;; WHEN: Mon Jan 31 13:24:09 2011
;; MSG SIZE  rcvd: 127

— runlevelsix
fonte

Você tem 2 problemas:

As consultas para ns1.faithhiway.com estão retornando resultados incorretos.
Os servidores de nomes listados para o seu domínio estão incorretos.

Você está realmente testando um pouco para trás. Você está testando o endereço IP que está sendo retornado ao consultar ns1.faithhiway.com, mas o que você deve testar primeiro é quais servidores de nome estão realmente sendo retornados para faithhiway.com. Uma pesquisa Whois e uma nslookup retornam os seguintes servidores como sendo os servidores de nome para faithhiway.com:

dns01.gpn.register.com

dns02.gpn.register.com

dns03.gpn.register.com

dns04.gpn.register.com

dns05.gpn.register.com

Então você precisa consertar isso primeiro.

— joeqwerty
fonte

first - ns1 e ns2 são servidores de nomes, não têm autoridade para si mesmos. O registro hospeda o DNS do servidor NS, enquanto todos os outros apontam seus registros DNS para uma resposta autorizada. Pesquisei os registros NS do faithhiway.com em todos os servidores acima e eles também resolvem o registro como os servidores de nomes com autoridade do domínio.

— precisa saber é o seguinte

Entendi mal o problema então. Os servidores de nomes para faithhiway.com não são nsX.faithhiway.com. nsX.faithhiway.com são os servidores de nome para as zonas DNS que você hospeda para seus clientes. Isso esta certo? Nesse caso, minhas desculpas pelo mal-entendido.

— precisa saber é o seguinte

Isso está correto - o Register.com é autoritário para faithhiway.com e nsX.faithhiway.com são os servidores de nomes responsáveis por nossos clientes.

— precisa

(para meu próprio entendimento) Não seria uma idéia relativamente ruim ter o servidor de nomes de domínio por si só, uma vez que, por algum motivo (esquecido por Deus), você perde o acesso aos IPs nos quais esses domínios apontam, você não tem mais quaisquer servidores de nomes autorizados que digam aos seus domínios para onde ir e para onde obter atualizações, como o novo local para si ns # .seudominio.com. na mesma linha, se eu comprar o awesomedomain.com e apontar para ns1 & ns2.awesomedomain.com, no entanto, nunca foi dito a nenhum servidor de raiz onde esses dois subdomínios apontam. Nada deveria acontecer?

— grufftech

Não sei o quão ruim é uma ideia, mas conheço muitas empresas que hospedam seus próprios servidores de nome para seu espaço de nome público. Se estou entendendo o que você está perguntando, é para isso que servem os registros de cola nos servidores-pai.

— precisa saber é o seguinte

Muitos servidores ignoram seu TTL e armazenam em cache as informações por muito mais tempo do que deveriam. A maneira mais fácil de resolver isso é entrar em contato com as operadoras da rede afetada e informá-las. Eles geralmente são muito bons em corrigi-lo rapidamente.

— Chris S
fonte