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.
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
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.
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
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!
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.
Poderia informar em que arquivo você fez essa alteração?
Grato
/etc/bind/named.conf
[]s