Não é possível resolver 1.2.3.4.list.dsbl.org

2

Histórico : Tudo começa com essa entrada de log

postfix/smtpd[10001]: warning: x.x.x.x.list.dsbl.org: RBL lookup error: Host or domain name not found. Name service error for name=x.x.x.x.list.dsbl.org type=A: Host not found, try again

Eu tentei resolvê-lo manualmente e, na verdade, recebi um tempo limite. Tentar usar os servidores DNS públicos do Google funciona bem e aqui começa o drama:

Eu configurei a ligação para permitir a recursão do host local e, em seguida, o servidor DNS comutado é /etc/resolv.conf para usar 127.0.0.1 como um servidor de nomes. Além disso, tentei especificar os servidores DNS públicos do Google como encaminhadores e sem eles (perguntando aos servidores raiz). Os resultados são idênticos:

dig a 1.2.3.4.list.dsbl.org

; <<>> DiG 9.9.5-9+deb8u7-Debian <<>> a 1.2.3.4.list.dsbl.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12810 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;1.2.3.4.list.dsbl.org. IN A

;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jan 04 12:55:36 UTC 2017 ;; MSG SIZE rcvd: 50

Após 3-4 segundos, falha. Tentando o DNS público do Google:

dig a 1.2.3.4.list.dsbl.org @8.8.8.8

; <<>> DiG 9.9.5-9+deb8u7-Debian <<>> a 1.2.3.4.list.dsbl.org @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62982 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;1.2.3.4.list.dsbl.org. IN A

;; Query time: 28 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Jan 04 12:57:28 UTC 2017 ;; MSG SIZE rcvd: 50

enquanto este funciona

dig a somedomain.com

; <<>> DiG 9.9.5-9+deb8u7-Debian <<>> a somedomain.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5

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

;; ANSWER SECTION: somedomain.com. 300 IN A 69.172.201.153

;; AUTHORITY SECTION: somedomain.com. 172800 IN NS sell.internettraffic.com. somedomain.com. 172800 IN NS buy.internettraffic.com.

;; ADDITIONAL SECTION: buy.internettraffic.com. 172800 IN A 64.96.240.54 buy.internettraffic.com. 172800 IN A 64.96.241.73 sell.internettraffic.com. 172800 IN A 176.74.176.176 sell.internettraffic.com. 172800 IN A 176.74.176.175

;; Query time: 49 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jan 04 12:56:30 UTC 2017 ;; MSG SIZE rcvd: 176

Nota de rodapé : Usando apenas o DNS do google em /etc/resolv.conf funciona bem localmente, quando eu reinicio o postfix, o arquivo está sendo copiado em /var/spool/postfix/etc/resolv.conf , mas o mesmo log do host não pôde ser resolvido.

O que estou perdendo?

    
por Stanimir Stoyanov 04.01.2017 / 14:01

2 respostas

3

O DSBL foi descontinuado no final de 2008; e por um bom tempo (um ano?) seu DNS ainda resolveu as consultas.

Embora algumas instruções antigas possam se referir a sua lista negra / domínio, não é aconselhável ter essa lista configurada, como já faz muito tempo, e as solicitações de DNS não são mais resolvidas.

O DNS do Google tem atalhos / otimizações para resolver problemas conhecidos e esse domínio provavelmente está em uma lista negra ou em algum tipo de configuração RPZ; em sua operação em larga escala, eu também faria o mesmo com endereços que ainda estão configurados em geral, já que tentar resolver domínios inexistentes consome recursos valiosos.

Algumas configurações semelhantes também fazem parte de ser um "bom" internauta, como a criação de solicitações de filtro de listas negras semelhantes e o resultado líquido é economizar recursos nos principais servidores de nomes de raiz (TLDs).

Reforçando a ideia de personalizações do Google, é de conhecimento geral que eles têm código personalizado e são bastante conhecidos por terem algumas funcionalidades "incomuns", como, por exemplo, ignorar TTLs muito baixos em RR em nome do desempenho . (desde então, o BIND criou uma opção global para definir os TTLs mais baixos que você aceita para um RR, se não me engano)

Eu não tenho idéia, já que você tem um servidor que sobreviveu por tanto tempo com uma lista negra dsbl.org configurada, pois quando este endereço foi descontinuado nós temos que retirá-lo das configurações da lista negra devido a atrasos nos servidores de e-mail.

Conforme solicitado, para colocar um domínio na lista negra no BIND:

arquivo de zona em /etc/bind/rpz.db

*.list.dsbl.org CNAME   *.

adicione o arquivo de zona a named.conf ou a uma visualização interna definida:

zone "rpz" {
  type master;
  file "/etc/bind/rpz.db";
  allow-query { your_internal_network; };
};

Adicione a named.conf.options :

options {
   ...
   response-policy { zone "rpz"; };
}

Por favor, veja também:

Arquivo de zona grande para bind9: bloqueio de anúncios

Configure o BIND como Encaminhador apenas (sem sugestões de raiz), encriptado + lista negra de RPZ / lista branca em conjunto

Associe a configuração do RPZ a domínios de vários níveis

    
por 04.01.2017 / 14:11
1

DSBL is GONE DSBL is GONE and highly unlikely to return. Please remove it from your mail server configuration.

por 04.01.2017 / 14:07