Pular para o conteúdo

Hoje estou me lembrando que, um certo dia, me deparei com um Bind 9 que não resolvia determinados sites, como o da faculdade onde dou aula e o Hotmail. O pior de tudo é que já vi alguns DNS assim na Internet.

Analisando com tcpdump, percebi, na saída para a Internet, que a porta cliente, após o NAT, ora era 7, ora era 11, ora era 1. E me veio à cabeça: um cliente normal de rede (DNS consultando outro) com porta privilegiada (abaixo de 1024)? Algo estava estranho. Fui analisar a saída do DNS com o tcpdump e a porta cliente dele, quando consultava outro, era a mesma de servidor: 53 udp. Muito estranho mesmo! A porta de consulta deveria ser de 1024 para cima. Analisei a configuração do Bind e batata! Olha o que eu encontrei lá dentro:

query-source port 53;

Removi esta linha e a porta cliente, tanto no DNS quanto no NAT, subiu para trinta e dois mil e pouco. E, magicamente, todos os sites que não resolviam passaram a resolver.

Com certeza, várias redes estão bloqueando conexões originadas de uma porta baixa, uma vez que não se espera que isto ocorra a partir de clientes. A versão do Bind 9 que encontrei, na época, trazia a opção mostrada como default. Mistério resolvido.

Marcações:

7 comentários em “DNS Bind não resolvia determinados sites”

  1. Caro professor Eriberto,
    Estou com uma dúvida e gostaria de contar com a ajuda do amigo.
    Estamos substituindo nosso servidor DNS (windows) por um servidor DNS Bind 9 (Debian) para resolver nomes em nossa INTRANET (INTRAER), contudo este servidor irá responder pelo domínio .INTRAER, e terá delegações de competência para outros domínios.
    No arquivo named.conf ou no named.conf.local, colocamos como type master o domínio .intraer e para os domínios com delegação de competência (ccabr.intraer, baan.intraer) como forward. Este procedimento está correto?
    Muito obrigado,
    Moraes

  2. Grande Moraes!

    O mais correto é, dentro do arquivo de configuração da zona .intraer, você criar uma entrada IN NS para cada subzona. Exemplo:

    ccabr.intraer IN NS ns.ccabr.intraer
    baan.intraer IN NS ns.baan.intraer

    ns.ccabr.intraer IN A 10.0.0.1
    ns.baan.intraer IN A 10.0.0.2

    No DNS de cada subzona é que você tem que fazer forward de zona para o domínio raiz, como você descreveu anteriormente (a zona alvo será a intraer). Ou seja: tudo que ns.ccabr.intraer não conseguir resolver, ele vai mandar para ns.intraer.

    Qualquer outra dúvida, é só falar.

  3. Caro professor Eriberto, Boa tarde.
    Seguindo a dúvida do amigo Humberto, estou com uma dúvida.

    Tenho a zona criada “intraer” e tenho o arquivo dessa zona “db.intraer”
    dentro do arquivo db, tenho vários registros NS apontando para outros servidores DNS. Como no exemplo:

    ccabr.intraer. IN NS ns.ccabr.intraer.
    ns.ccabr.intraer. IN A 10.0.0.1

    baan.intraer. IN NS ns.baan.intraer.
    ns.baan.intraer. IN A 10.0.0.2

    O problema que estou tendo é na hora de criar o reverso desses servidores NS.
    Criei a zona reversa “10.in-addr.arpa” o arquivo “rev_db.intraer” com conteúdo:

    1.0.0 IN PTR ns.ccabr.intraer.

    2.0.0 IN

  4. O problema é que o servidor nao está resolvendo os reversos de paginas com registros dentro dos serves NS.

    Tipo quando faço uma consulta: “dig http://www.ccabr.intraer” Ok 10.0.0.50
    Só que quando faço uma consulta do reverso: “dig -x 10.0.0.50” ele nao me retorna a resposta que deveria ser “www.ccabr.intraer” .

    A configuração do arquivo reverso está correta? Seria:

    1.0.0 IN PTR ns.ccabr.intraer.
    2.0.0 IN PTR ns.baan.intraer.

    Agradeço pela ajuda!

  5. Marcos Leite:

    Agora complicou. Só vendo todos os arquivos de configuração. Se quiser, manda pro meu e-mail. Também sugiro que reinicie o bind e, em seguida, olhe com cuidado o log /var/log/syslog. Se houver algum erro de configuração, ele será mostrado no log.

    Grande abraço.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

dezenove − oito =