Início / server / Perguntas / 1165319
Accepted
hzahradnik
Asked: 2024-09-17 03:11:32 +0800 CST

A entrada SOA defeituosa é armazenada em cache nos servidores DNS do provedor de serviços após a suspensão do domínio

  • 772

Nossa empresa transferiu um domínio .com para um provedor de domínio diferente. Isso funcionou muito bem por 14 dias, mas hoje nosso domínio foi suspenso, porque tivemos um problema com nosso provedor de e-mail e não recebemos o e-mail para a verificação do endereço do proprietário.

Depois de algum tempo, conseguimos consertar os problemas de e-mail e verificar o domínio. Também conseguimos fazer nosso aplicativo rodar conforme o esperado, ao usar o DNS do Google/Cloudflare/.... No entanto, muitos de nossos clientes ainda têm problemas para acessar nosso aplicativo depois de quase 12 horas.

Enquanto isso, podemos rastrear uma possível causa. Nosso suspeito é o cache de DNS de alguns provedores de internet. Veja a saída de nslookuppara solicitar a entrada SOA do subdomínio para nossa aplicação.

Usando o DNS do Google (8.8.8.8), a entrada SOA para app.EXAMPLE.com é do nosso domínio EXAMPLE.com.

> server 8.8.8.8
Default Server:  dns.google
Address:  8.8.8.8

> set type=soa
> set d2
> app.EXAMPLE.com
Server:  dns.google
Address:  8.8.8.8

------------
SendRequest(), len 34
    HEADER:
        opcode = QUERY, id = 25, rcode = NOERROR
        header flags:  query, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        app.EXAMPLE.com, type = SOA, class = IN

------------
------------
Got answer (99 bytes):
    HEADER:
        opcode = QUERY, id = 25, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        app.EXAMPLE.com, type = SOA, class = IN
    AUTHORITY RECORDS:
    ->  EXAMPLE.com
        type = SOA, class = IN, dlen = 53
        ttl = 1800 (30 mins)
        primary name server = ns1.DOMAINPROVIDER.de
        responsible mail addr = postmaster.DOMAINPROVIDER.de
        serial  = 2024091603
        refresh = 86400 (1 day)
        retry   = 10800 (3 hours)
        expire  = 3600000 (41 days 16 hours)
        default TTL = 3600 (1 hour)

------------
EXAMPLE.com
        type = SOA, class = IN, dlen = 53
        ttl = 1800 (30 mins)
        primary name server = ns1.DOMAINPROVIDER.de
        responsible mail addr = postmaster.DOMAINPROVIDER.de
        serial  = 2024091603
        refresh = 86400 (1 day)
        retry   = 10800 (3 hours)
        expire  = 3600000 (41 days 16 hours)
        default TTL = 3600 (1 hour)
> set type=A
> app.EXAMPLE.com
Server:  dns.google
Address:  8.8.8.8
------------
[...]
------------
Non-authoritative answer:
Name:    app.EXAMPLE.com
Address:  <IP ADDRESS OF OUR SERVER>

Ao usar o servidor DNS do nosso provedor de internet, obtemos um resultado completamente diferente para o subdomínio.

> set type=soa
> set d2
> app.EXAMPLE.com
Server:  <DNS OF INTERNET PROVIDER>
Address:  <DNS OF INTERNET PROVIDER>

------------
SendRequest(), len 34
    HEADER:
        opcode = QUERY, id = 28, rcode = NOERROR
        header flags:  query, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        app.EXAMPLE.com, type = SOA, class = IN

------------
------------
Got answer (107 bytes):
    HEADER:
        opcode = QUERY, id = 28, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        app.EXAMPLE.com, type = SOA, class = IN
    ANSWERS:
    ->  app.EXAMPLE.com
        type = SOA, class = IN, dlen = 61
        ttl = 2335 (38 mins 55 secs)
        primary name server = ns1.emailverification.info
        responsible mail addr = hostmaster.emailverification.info
        serial  = 2024090700
        refresh = 7200 (2 hours)
        retry   = 3600 (1 hour)
        expire  = 604800 (7 days)
        default TTL = 3600 (1 hour)

------------
Non-authoritative answer:
app.EXAMPLE.com
        type = SOA, class = IN, dlen = 61
        ttl = 2335 (38 mins 55 secs)
        primary name server = ns1.emailverification.info
        responsible mail addr = hostmaster.emailverification.info
        serial  = 2024090700
        refresh = 7200 (2 hours)
        retry   = 3600 (1 hour)
        expire  = 604800 (7 days)
        default TTL = 3600 (1 hour)
> set type=A
> app.EXAMPLE.com
Server:  <DNS OF INTERNET PROVIDER>
Address:  <DNS OF INTERNET PROVIDER>
------------
[...]
------------
Non-authoritative answer:
Name:    app.EXAMPLE.com
Address:  <WRONG IP ADDRESS>

Minha pergunta: Isso se resolve automaticamente depois de algum tempo ou precisamos fazer algo? É possível acelerar o processo?

domain-name-system

1 respostas

  1. Best Answer

    Execute dnstracer -s . app.example.compara verificar se as informações de delegação (sem cache) estão corretas. Isso verificará se o registro de domínio tem registros NS corretos para seu domínio e se seu domínio tem registros NS corretos para seu subdomínio 'app'. (Como ele tem seu próprio SOA, isso implica que é uma zona separada delegada do domínio principal.)

    Como alternativa, use nslookup -d -q=NS example.com a.gtld-servers.net(esse é um dos servidores de nomes .com) e faça uma consulta semelhante para app.example.com nos servidores de nomes do seu domínio principal.

    É comum que TLDs tenham TTLs de cache um pouco mais longos para os registros de delegação NS, às vezes até 24 horas (de onde provavelmente vem a coisa da "propagação de 24 a 48 horas"), então é possível que o resolvedor do seu ISP tenha armazenado em cache não apenas os registros A e SOA ruins, mas também os registros de delegação NS ruins, e continuará consultando os servidores de nomes errados até que eles expirem.

    A única coisa que você pode fazer é verificar se os dados oficiais em todos os servidores de nomes estão corretos.

    • 0

relate perguntas