Início / user-269784

Nick Williams's questions

Martin Hope
Nick Williams
Asked: 2024-12-29 09:46:44 +0800 CST
  • 5

Tenho um servidor PowerDNS Recursor 4.0.4 existente em execução no Debian Jessie 8 (eu sei, eu sei, desatualizado... Estou chegando lá). Ele lida com todas as solicitações de DNS para minha rede de laboratório doméstico. Ele tem uma configuração bastante simples e tem funcionado sem interrupção por literalmente anos seguidos. Ele também é configurado para validar e valida com sucesso todos os DNSSEC.

Ontem à noite, pouco depois da meia-noite, ele parou de resolver cerca de metade de todos os domínios no mundo, retornando SERVFAILpara eles. Às vezes, ele resolve o domínio primário (como athenahealth.com), mas não um subdomínio (como 20785-1.portal.athenahealth.com). Às vezes, ele não resolve o domínio primário (como serverfault.comou askubuntu.com). Não consegui encontrar nenhum padrão e, não importa o quanto eu tenha mexido na minha configuração (incluindo desligar completamente o DNSSEC), isso não resolve o problema.

Meu próximo pensamento foi que eu precisava atualizar o PowerDNS Recursor, mas não consegui por causa da idade do meu servidor DNS. Então, criei um servidor totalmente novo executando o PowerDNS Recursor 5.1.3 no Ubuntu 24.04.1. Novamente, a configuração é simples. Aqui está o arquivo primário:

$ cat /etc/powerdns/recursor.conf 
dnssec:
  # validation: process # default
  trustanchorfile: /usr/share/dns/root.key
recursor:
  hint_file: /usr/share/dns/root.hints
  include_dir: /etc/powerdns/recursor.d
#incoming:
 # listen:
 # - 127.0.0.1 # default
#outgoing:
 # source_address:
 # - 0.0.0.0 # default

E aqui está um arquivo em recursor.d:

$ cat /etc/powerdns/recursor.d/me.yml 
dnssec:
  validation: off # validate
#  log_bogus: true
incoming:
  listen:
    - 10.20.30.76:53
logging:
  common_errors: true
  facility: 1
  loglevel: 6
  quiet: true
  trace: fail
recursor:
  auth_zones:
    - zone: my-domain-1.com
      file: /etc/powerdns/my-domain-1.com.zone
  forward_zones:
    - zone: my-domain-2.com
      forwarders:
        - 10.20.31.2
  setgid: pdns
  setuid: pdns
  socket_dir: /var/run
  write_pid: true
webservice:
  address: 10.20.30.76
  allow_from:
    - 10.20.30.0/24
    - 172.24.52.0/24
  api_key: loremipsum
  password: foobarbazqux
  port: 8080

Esta configuração é idêntica à minha antiga configuração do PowerDNS Recursor, exceto que o DNSSEC está desabilitado para tentar fazê-lo funcionar. Se eu manualmente dig(eu amo dig) askubuntu.comda raiz para cima, eu encontro facilmente uma resposta:

# Using i.root-servers.net is 192.36.148.17
$ dig @192.36.148.17 com NS

; <<>> DiG 9.10.6 <<>> @192.36.148.17 com NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2217
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 21

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;com.               IN  NS

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

;; ADDITIONAL SECTION:
b.gtld-servers.net. 43604   IN  A   192.33.14.30
b.gtld-servers.net. 71837   IN  AAAA    2001:503:231d::2:30
l.gtld-servers.net. 44115   IN  A   192.41.162.30
l.gtld-servers.net. 74612   IN  AAAA    2001:500:d937::30
a.gtld-servers.net. 59944   IN  A   192.5.6.30
a.gtld-servers.net. 52029   IN  AAAA    2001:503:a83e::2:30
e.gtld-servers.net. 11582   IN  A   192.12.94.30
e.gtld-servers.net. 63219   IN  AAAA    2001:502:1ca1::30
m.gtld-servers.net. 27782   IN  A   192.55.83.30
m.gtld-servers.net. 50020   IN  AAAA    2001:501:b1f9::30
j.gtld-servers.net. 39663   IN  A   192.48.79.30
h.gtld-servers.net. 79936   IN  A   192.54.112.30
g.gtld-servers.net. 57527   IN  A   192.42.93.30
g.gtld-servers.net. 63219   IN  AAAA    2001:503:eea3::30
d.gtld-servers.net. 44435   IN  A   192.31.80.30
d.gtld-servers.net. 10633   IN  AAAA    2001:500:856e::30
c.gtld-servers.net. 50185   IN  A   192.26.92.30
k.gtld-servers.net. 32146   IN  A   192.52.178.30
i.gtld-servers.net. 48002   IN  A   192.43.172.30
i.gtld-servers.net. 27967   IN  AAAA    2001:503:39c1::30

$ dig @192.33.14.30 askubuntu.com NS

; <<>> DiG 9.10.6 <<>> @192.33.14.30 askubuntu.com NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46168
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 13

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;askubuntu.com.         IN  NS

;; ANSWER SECTION:
askubuntu.com.      86400   IN  NS  sureena.ns.cloudflare.com.
askubuntu.com.      86400   IN  NS  damian.ns.cloudflare.com.

;; ADDITIONAL SECTION:
damian.ns.cloudflare.com. 48087 IN  A   172.64.35.50
damian.ns.cloudflare.com. 48087 IN  A   162.159.44.50
damian.ns.cloudflare.com. 48087 IN  A   108.162.195.50
damian.ns.cloudflare.com. 13178 IN  AAAA    2803:f800:50::6ca2:c332
damian.ns.cloudflare.com. 13178 IN  AAAA    2606:4700:58::a29f:2c32
damian.ns.cloudflare.com. 13178 IN  AAAA    2a06:98c1:50::ac40:2332
sureena.ns.cloudflare.com. 38809 IN A   108.162.194.126
sureena.ns.cloudflare.com. 38809 IN A   172.64.34.126
sureena.ns.cloudflare.com. 38809 IN A   162.159.38.126
sureena.ns.cloudflare.com. 32427 IN AAAA    2a06:98c1:50::ac40:227e
sureena.ns.cloudflare.com. 32427 IN AAAA    2803:f800:50::6ca2:c27e
sureena.ns.cloudflare.com. 32427 IN AAAA    2606:4700:50::a29f:267e

$ dig @172.64.35.50 askubuntu.com A

; <<>> DiG 9.10.6 <<>> @172.64.35.50 askubuntu.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35705
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;askubuntu.com.         IN  A

;; ANSWER SECTION:
askubuntu.com.      300 IN  A   172.64.150.156
askubuntu.com.      300 IN  A   104.18.37.100

Perfeito. Mas se eu perguntar ao meu servidor PowerDNS Recursor 4.0.4 existente ou ao meu novo servidor PowerDNS Recursor 5.1.3, eu recebo SERVFAIL:

$ dig @10.20.30.76 askubuntu.com A

; <<>> DiG 9.10.6 <<>> @10.20.30.76 askubuntu.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58213
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; OPT=15: 00 16 64 65 6c 65 67 61 74 69 6f 6e 20 63 6f 6d ("..delegation com")
;; QUESTION SECTION:
;askubuntu.com.         IN  A

A OPT=15linha com algum tipo de assinatura plus delegation comé interessante. Não está acontecendo em todos os domínios que estão falhando em resolver, então pode ser uma pista falsa (e muda... como executar a mesma consulta novamente resultou em OPT=15: 00 16 64 65 6c 65 67 61 74 69 6f 6e 20 61 73 6b 75 62 75 6e 74 75 2e 63 6f 6d ("..delegation askubuntu.com")).

Aqui está o rastreamento de falha do PowerDNS Recursor 5.1.3 para uma pesquisa com falha de askubuntu.com: https://gist.github.com/beamerblvd/d8fa24bdf1037e2a670f8e331b7e4905

Para sua informação, estou na Classe Executiva da Comcast com uma delegação de IP estático de 5 endereços.

O que estou fazendo errado?

powerdns
Martin Hope
Nick Williams
Asked: 2018-01-11 10:53:03 +0800 CST
  • 1

Eu tenho um roteador VyOS. VyOS é um fork OSS do Vyatta pré-Brocade/pré-Ubiquiti EdgeRouter. Possui uma DMZ de frente para vários servidores voltados para o público e uma zona privada de frente para nossas redes WiFi e ethernet privadas.

Anteriormente, trabalhamos com DSL com um endereço IP estático. O modem DSL estava simplesmente no modo bridge, e o endereço IP estático foi atribuído à interface WAN do roteador VyOS. DSL (e um único endereço IP) tornou-se insustentável.

Estamos configurando o Comcast Business Class Internet (5 endereços IP estáticos). Com ele, você deve usar o Comcast Business IP Gateway (um modem DOCSIS 3.0 sofisticado, neste caso um modelo Cisco tipo BWG-DPC3939B) se quiser ter endereços IP estáticos (seu próprio equipamento só é permitido com um endereço IP dinâmico ). Além disso, se você deseja ter endereços IP estáticos, não pode colocar o Gateway IP no modo bridge. Ele reverterá para endereçamento dinâmico se você fizer isso. O endereçamento estático está disponível apenas no modo roteador, embora a Comcast enfatize que você pode desativar todos os recursos do roteador (DHCP, NAT, WiFi, firewall, etc.) e usar seu próprio equipamento (nosso roteador VyOS) atrás do modem. E é aqui que as coisas ficam estranhas.

Os 5 endereços IP estáticos vêm de um /29: No nosso caso, este é *.168 a *.175, com *.168 e *.175 reservados/inutilizáveis, e *.174 atribuído ao Gateway IP, deixando-nos com *.169, *.170, *.171, *.172 e *.173 para usar em nosso equipamento. *.174 é o "gateway padrão", o endereço pelo qual passa todo o tráfego de saída.

Eu sou capaz de configurar uma configuração simples em que o VyOS tem um endereço IP estático (*.169) em sua WAN e todo o tráfego entra e sai dele através do Gateway IP. Funciona bem. Mas não tenho certeza de como / a melhor maneira de usar todos os cinco. Supus que posso atribuir todos os cinco endereços à WAN e usar 1:1 NAT (DNAT + SNAT) para lidar com o mapeamento do tráfego de entrada para esses endereços IP públicos para endereços IP privados na DMZ e reverter, mas eu queria evite esta configuração. (Sei que tenho que usar SNAT para minhas redes privadas DHCP/WiFi/ethernet; não preciso de ajuda com isso.)

Eu esperava poder atribuir apenas um IP público (*.169) à WAN do VyOS e, em seguida, atribuir *.170 a *.173 diretamente aos hosts em minha DMZ, configurar o VyOS para rotear o tráfego para esses IPs públicos em a DMZ e configure o Gateway IP para enviar todo o tráfego *.169 - *.173 para *.169 para roteamento adicional. Isso é possível? Ou a abordagem NAT acima é a melhor / única solução?

routing