larocca.net.br

Segue arquivos que eu uso de modelo para configuração de dns no Linux. A configuração está feita com as zonas dentro de views interna e externa, conforme comentado no post sobre consultas recursivas.

No exemplo em questão foi configurado o domínio “dominio.com.br” com a view interna permitindo consultas recursivas para a rede 192.168.50.0. Basta editar os arquivos para a rede e domínio desejados.

Abaixo os arquivos:

named.conf

Arquivos de configuração de zonas que ficam no /var/lib/named/master

dominio.com.br.interno

dominio.com.br.externo

Esses arquivos acima foram usados no bind-9.4.1.P1-12 do openSUSE 10.3

Um dos problemas mais comuns na entrega de e-mails é quando o servidor do remetente não tem reverso configurado no servidor.

No caso, geralmente o erro que retorna no postfix é:

host rejected: cannot find your hostname, [xxx.235.37.173]; from=<atendimento@xxxxxx.com>
to=<compras@yyyyyyy.com.br> proto=ESMTP helo=<visualnet.zzzzz.net>

O pior é que essa semana tive um caso onde o remetente não tinha reverso, e o destinatário precisava receber os e-mails com urgência.

Solução:

Teve que ser desabilitado check de reverso no servidor destinatário para poder receber.

No Zimbra, essa opção é desabilitada na tela abaixo:

Hoje atendi 2 clientes que entraram em contato porque receberam um aviso do cert.br reportando alerta sobre dns recursivo aberto.O cert.br é um grupo que cuida de incidentes de segurança na internet brasileira, mantido pelo nic.br (comite gestor de internet no brasil).

As empresas que hospedam servidor de dns na sua rede local, normalmente vao ter o dns respondendo de forma autoritativa e recursiva.

Autoritativas são aquelas consultas feitas no mundo todo, vindas da internet, com relação ao domínio pelo qual o dns responde, como o próprio nome já diz, autoritativamente.

E as recursivas, são aquelas consultas vindas da rede local, que podem ser tanto de nomes de hosts locais (dos quais o dns terá a resposta), quanto nomes de outros domínios externos (consultas que terão que ser repassadas a outros servidores dns).

Aí é que surge o problema. Quando um dns fica aberto a consultas recursivas, ele permite que não só a rede local faça esse tipo de consulta, mas também toda a rede internet (!!!). Isso abre uma falha de segurança, possibilitando ataques de negação de serviço, etc.

No caso esses dois clientes que eu atendi, tinham dns rodando em linux, com bind 9. A solução para isso é criar no arquivo de configuração do bind (named.conf) uma view externa, onde as consultas recursivas não são permitidas, e uma view interna, onde essas consultas podem ser feitas. E também criar um arquivo de zona para cada uma das views.

Segue link da própria cert.br com maiores informações sobre o assunto:

http://www.cert.br/docs/whitepapers/dns-recursivo-aberto/

Segue link onde pode ser testado o domínio, para saber se o dns está como open dns server.

http://www.dnsstuff.com

Segue telas do named.conf no local onde são declaradas as zonas com as 2 views:

-> interna

-> externa (veja parametro “recursion no” negando consultas recursivas)

Dos 2 clientes que eu atendi, esse primeiro deu tudo certo. O segundo deu alguns probleminhas, tive que recuperar backup dos arquivos com a configuração original, pois a alteração causou impacto no serviço de e-mail. Nas cenas do proximo capítulo eu posto aqui pra documentar.

hehehe

—————-
Vinícius -> ao som de Pink Floyd – Speak to Me
via FoxyTunes

Hj peguei uma paulerinha de dns legal, bom de documentar pra não esquecer. Foi adicionado uma semana atrás um registro de host “A” num dns de um cliente, que possui o servidor de dns primario na rede local, e o secundario na embratel.

O problema que estava ocorrendo é que o nome desse host, dependendo do local onde era consultado, em alguns momentos era resolvido pelo dns, em outros não. Consultando o dominio no dnsstuff.com retornava um erro relatando que havia diferença entre a serial number do dns primario e segundario (um indício de que as informações não estão replicando entre os 2). Fazendo uma query A direto aos servers, com nslookup a confirmação, o dns primário resolve o host, e o secundário não.

Por isso em alguns lugares funciona, em outros não. Quando a consulta cai no dns primario blz, quando cai no secundário ele nao conhece o nome….

Bom, agora a solução… Pedi pro cliente entrar em contato com a embratel e passar essa informação dos seriais, pra ver o que eles diziam… Eles informaram que o serial que estava colocado no dns primario, estava com um número menor do que o do secundario, e por isso não havia replicado.

Só que no momento em que foi adicionado o host novo, a atualização do serial foi feita no padrão correto, como manda a rfc (YYYYMMDDnn – ano, mes, dia, número da alteraçao), mas o pessoal da embratel, usa um padrão diferente (YYYYDDMMnn) …

Depois que foi alterada no arquivo de zona do dns, a serial para o padrão que está no servidor da embratel, e reiniciado o named, a replicação voltou a ocorrer.

Uma prova de que o pessoal da embratel tá no padrao errado, aqui tá um alerta exibido no dnsstuff:

WARNING: Your SOA serial number is: 2007231103. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where ‘nn’ is the revision. For example, if you are making the 3rd change on 02 May 2006, you would use 2006050203. This number must be incremented every time you make a DNS change.

Resumo: quando houver dns secundario hospedado fora, consultar no dnsstuff.com o dominio pra ver como está o número do serial, pois pode ser que o admin do dns secundário resolva inventar seu próprio padrão, ao invés de usar o da rfc.
—————-
Vinícius -> ao som de The Mamas and The Papas – California Dreaming
via FoxyTunes