Respostas NXDOMAIN intermitentes para determinados registros com TTLs baixos

1

Estamos com um problema peculiar em nossa instalação bind (versão 9.8.4).

Nesse cenário, bind está configurado como um servidor de nomes de armazenamento em cache para uma rede pequena. Para a grande maioria das consultas, tudo funciona bem.

No entanto, notamos que as consultas para alguns hosts que estão configurados com um TTL muito baixo, às vezes recebemos respostas NXDOMAIN, mesmo que o nome do host exista.

Como exemplo, veja www.cdn77.com - aqui está a saída de dig quando executada no próprio servidor de nomes:

$ dig www.cdn77.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.cdn77.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34440
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 12

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

;; ANSWER SECTION:
www.cdn77.com.      196 IN  CNAME   1669655317.rsc.cdn77.org.
1669655317.rsc.cdn77.org. 0 IN  A   185.59.220.12

;; AUTHORITY SECTION:
org.            170517  IN  NS  a2.org.afilias-nst.info.
org.            170517  IN  NS  c0.org.afilias-nst.info.
org.            170517  IN  NS  b0.org.afilias-nst.org.
org.            170517  IN  NS  d0.org.afilias-nst.org.
org.            170517  IN  NS  a0.org.afilias-nst.info.
org.            170517  IN  NS  b2.org.afilias-nst.org.

;; ADDITIONAL SECTION:
a0.org.afilias-nst.info. 170517 IN  A   199.19.56.1
a0.org.afilias-nst.info. 170517 IN  AAAA    2001:500:e::1
a2.org.afilias-nst.info. 170517 IN  A   199.249.112.1
a2.org.afilias-nst.info. 170517 IN  AAAA    2001:500:40::1
b0.org.afilias-nst.org. 170517  IN  A   199.19.54.1
b0.org.afilias-nst.org. 170517  IN  AAAA    2001:500:c::1
b2.org.afilias-nst.org. 170517  IN  A   199.249.120.1
b2.org.afilias-nst.org. 170517  IN  AAAA    2001:500:48::1
c0.org.afilias-nst.info. 170517 IN  A   199.19.53.1
c0.org.afilias-nst.info. 170517 IN  AAAA    2001:500:b::1
d0.org.afilias-nst.org. 170517  IN  A   199.19.57.1
d0.org.afilias-nst.org. 170517  IN  AAAA    2001:500:f::1

;; Query time: 42 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Dec  2 14:27:03 2015
;; MSG SIZE  rcvd: 487

E aqui está um exemplo de quando uma resposta NXDOMAIN é retornada:

$ dig www.cdn77.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.cdn77.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28771
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

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

;; ANSWER SECTION:
www.cdn77.com.      327 IN  CNAME   1669655317.rsc.cdn77.org.

;; AUTHORITY SECTION:
cdn77.org.      59  IN  SOA ns1.cdn77.org. admin.cdn77.com. 1449062655 10800 180 604800 60

;; Query time: 34 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Dec  2 14:24:52 2015
;; MSG SIZE  rcvd: 115

Usamos os servidores de nome público do Google como encaminhadores e eles nunca parecem responder com o NXDOMAIN:

$ dig www.cdn77.com @8.8.8.8

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.cdn77.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35091
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

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

;; ANSWER SECTION:
www.cdn77.com.      851 IN  CNAME   1669655317.rsc.cdn77.org.
1669655317.rsc.cdn77.org. 0 IN  A   185.59.220.11

;; Query time: 40 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Dec  2 14:29:16 2015
;; MSG SIZE  rcvd: 85

A resposta autoritária, a propósito, é assim:

$ dig 1669655317.rsc.cdn77.org @ns1.cdn77.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> 1669655317.rsc.cdn77.org @ns1.cdn77.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11529
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;1669655317.rsc.cdn77.org.  IN  A

;; ANSWER SECTION:
1669655317.rsc.cdn77.org. 1 IN  A   185.59.220.12

;; Query time: 20 msec
;; SERVER: 37.235.105.100#53(37.235.105.100)
;; WHEN: Wed Dec  2 14:32:57 2015
;; MSG SIZE  rcvd: 58

Curiosamente, embora o TTL autorizado para o registro seja um, o servidor público de nomes do Google sempre o reduz a zero (consulte este artigo para uma leitura interessante sobre este comportamento). Acho que isso não tem nada a ver com o problema, já que as respostas bem-sucedidas de nosso bind também mostram o TTL zero.

Eu aumentei o nível de criação de log de bind , mas acho muito difícil identificar quaisquer entradas que possam ter algo a ver com o problema. Mesmo com querylog ativado, tudo o que é visível é a própria consulta e resolver: debug 1: createfetch: 1669655317.rsc.cdn77.org A linhas.

Qualquer indicação sobre como diagnosticar melhor (ou mesmo resolver) este problema seria muito apreciada.

    
por dorian 02.12.2015 / 14:39

3 respostas

2

O problema é que os servidores de nomes oficiais do cdn77.org não conseguem lidar adequadamente com ECS ( Opções de sub-redes do cliente EDNS ) quando elas contêm uma sub-rede cliente IPv6, embora manipulem sub-redes do cliente IPv4 muito bem.

Se você criar contato com o suporte de sub-rede de cliente EDNS , pode verificar isso na linha de comando; ou você pode usar a ferramenta de pesquisa de DNS do KeyCDN on-line para verificar isso (marque a caixa de seleção de detalhes e desmarque a caixa de seleção recursiva e omitir o @ antes de ns1 quando você o der como DNS personalizado):

$ dig 1669655317.rsc.cdn77.org @ns1.cdn77.org +subnet=2001:db8::1
; <<>> DiG 9.10.1 <<>> +additional 1669655317.rsc.cdn77.org @ns1.cdn77.org +subnet=2001:db8::1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44989
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
; CLIENT-SUBNET: 2001:db8::1/128/0
;; QUESTION SECTION:
;1669655317.rsc.cdn77.org.  IN  A

;; AUTHORITY SECTION:
cdn77.org.      60  IN  SOA ns1.cdn77.org. admin.cdn77.com. 1449094813 10800 180 604800 60

;; Query time: 2 msec
;; SERVER: 37.235.105.100#53(37.235.105.100)
;; WHEN: Wed Dec 02 22:21:41 UTC 2015
;; MSG SIZE  rcvd: 132

A mesma consulta com um endereço de cliente IPv4 funciona bem:

$ dig 1669655317.rsc.cdn77.org @ns1.cdn77.org +subnet=192.0.2.1
; <<>> DiG 9.10.1 <<>> +additional 1669655317.rsc.cdn77.org @ns1.cdn77.org +subnet=192.0.2.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19104
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
; CLIENT-SUBNET: 192.0.2.1/32/32
;; QUESTION SECTION:
;1669655317.rsc.cdn77.org.  IN  A

;; ANSWER SECTION:
1669655317.rsc.cdn77.org. 1 IN  A   185.93.3.27

;; Query time: 2 msec
;; SERVER: 37.235.105.100#53(37.235.105.100)
;; WHEN: Wed Dec 02 22:42:13 UTC 2015
;; MSG SIZE  rcvd: 81

Quando você envia sua consulta para um endereço IPv6 para o DNS público do Google, sua sub-rede IP cliente é obviamente uma sub-rede IPv6 e, quando o servidor autoritativo responde a NXDOMAIN, a resposta (em cache?) para clientes IPv6 também é NXDOMAIN. Se você enviar sua consulta para um endereço IPv4 para o DNS público do Google, a sub-rede do cliente será uma sub-rede IPv4 e você receberá a resposta correta (possivelmente em cache).

    
por 02.12.2015 / 23:50
2

Os encaminhadores upstream parecem ter dados inconsistentes - embora a causa não esteja clara - um encaminhador em seu round-robin está retornando NXDOMAIN que está sendo armazenada em cache localmente:

O DNS público do Google IPv6 2001:4860:4860::8888 está retornando NXDOMAIN , apesar de 8.8.8.8 funcionar corretamente (ou seja, correspondendo à resposta autoritativa)

A solução de curto prazo é remover o encaminhamento incorreto e, em seguida, reiniciar o Bind ou limpar o cache negativo.

Veja a resposta de Alex Dupuy para uma explicação clara da causa raiz

    
por 02.12.2015 / 17:36
1

Desculpe pelo inconveniente, este bug tem causado problemas apenas a alguns de nossos clientes, Alex Dupuy forneceu uma ótima explicação do problema. Nós adicionamos o suporte ao IPv6 EDNS e habilitamos o IPv6 anycast em nossos servidores DNS e esse problema desapareceu.

    
por 09.12.2015 / 16:28