Oséias Ferreira wrote:
> Estou configurando um servidor DNS, mais para efeito de testes.
> Criei uma zona no afraid (barata.info.tm), e estou tentando colocar o
> meu servidor para resolver esta zona.
>
> A conexão com a internet se dá através de um roteador linksys, que
> direciona a porta 53(TCP/UDP), para meu servidor DNS (192.168.0.3).
>
> Internet ----[189.X.X.X<->roteador<->192.168.0.1]----[192.168.0.3 DNS]
Essa configuração é péssima para um DNS autoritativo público. Você tem
apenas um servidor para o domínio? Cadê o servidor secundário/escravo?
Especialmente fazer pacotes UDP cruzarem um roteador doméstico, não se
sabe quais perversões o roteador irá fazer com os pobres pacotes.
Dei uma olhada no seu domínio:
~% host -a barata.info.tm
Trying "barata.info.tm"
;; connection timed out; no servers could be reached
Problema 1: servidor inalcançável. Vamos olhar no domínio superior:
~% host -a barata.info.tm ns3.afraid.org.
Trying "barata.info.tm"
Using domain server:
Name: ns3.afraid.org.
Address: 72.20.25.134#53
Aliases:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5615
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;barata.info.tm. IN ANY
;; AUTHORITY SECTION:
barata.info.tm. 3600 IN NS barata.ath.cx.
Received 59 bytes from 72.20.25.134#53 in 232 ms
Problema 2: Não há "cola" do domínio pai (info.tm) para o seu domínio.
Pior ainda, o NS aponta para um hostname em outro domínio. O correto
seria o afraid.org ter o endereço IP do seu NS (ex: ns1.barata.info.tm)
e fornecê-lo junto com a resposta autoritativa do NS.
~% host -a barata.ath.cx
Trying "barata.ath.cx"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5845
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4
;; QUESTION SECTION:
;barata.ath.cx. IN ANY
;; ANSWER SECTION:
barata.ath.cx. 60 IN A 189.102.48.89
;; AUTHORITY SECTION:
ath.cx. 86335 IN NS ns4.dyndns.org.
ath.cx. 86335 IN NS ns2.dyndns.org.
ath.cx. 86335 IN NS ns3.dyndns.org.
ath.cx. 86335 IN NS ns1.dyndns.org.
ath.cx. 86335 IN NS ns5.dyndns.org.
;; ADDITIONAL SECTION:
ns2.dyndns.org. 86335 IN A 204.13.249.75
ns3.dyndns.org. 86335 IN A 208.78.69.75
ns4.dyndns.org. 86335 IN A 91.198.22.75
ns5.dyndns.org. 86335 IN A 203.62.195.75
Received 211 bytes from 127.0.0.1#53 in 206 ms
Problema 3: o TTL do seu nameserver (60 segundos) é baixo demais, o que
apesar é de se esperar uma vez que o endereço é dinâmico, e servido pelo
DynDNS.org.
Esses dois últimos problemas já tornam o seu servidor de nomes
extremamente ruim. Testando pelo primeiro problema, um sniffer de rede
mostra que seu servidor não está respondendo pelas requisições recebidas.
Então, prosseguindo:
> As regras do iptables no roteador:
>
> # iptables -t nat -L
> Chain PREROUTING (policy ACCEPT)
> target prot opt source destination
> DNAT udp -- anywhere 189.X.X.X udp dpt:domain
> to:192.168.0.3:53
> DNAT tcp -- anywhere 189.X.X.X tcp dpt:domain
> to:192.168.0.3:53
> ...
>
> Chain POSTROUTING (policy ACCEPT)
> target prot opt source destination
> SNAT udp -- 192.168.0.0/24 192.168.0.3 udp
> dpt:domain to:192.168.0.1
> SNAT tcp -- 192.168.0.0/24 192.168.0.3 tcp
> dpt:domain to:192.168.0.1
Opa. Seu roteador é um Linksys hackeado com Linux? Um DD-WRT da vida?
Bom, essas regras estão incompletas. Poste as regras originais
(argumentos passados para o iptables), ou a saída do iptables com -v. Eu
teria que ver quais interfaces as regras na tabela PREROUTING estão
sendo aplicadas (você pode estar dando um tiro no pé sem saber), e sem o
parâmetro -v o iptables não mostra essas colunas. Eu sugeriria não
fornecer porta alguma para o --to da regra DNAT, pois subentende-se que
a porta deverá ser reescrita, o que não é necessário no seu caso.
Já as regras na tabela POSTROUTING estão completamente erradas. Não sei
o que você tentou fazer, mas não faz sentido. O que você deveria ter é
algo parecido com:
iptables -t nat -A POSTROUTING -o ethX -s 192.168.0.0/24 \
-j SNAT --to 189.X.X.X
Onde ethX é sua interface de saída para a internet.
> Estou usando views para diferenciar as pesquisas feitas dentro da lan
> e fora (internet).
> (...)
> options {
> (...)
> listen-on-v6 { any; };
Está faltando fechar a cláusula "options" aqui.
> view "int" IN {
> (...)
> zone "barata.info.tm" {
> type master;
> file "barata.info.tm-INT";
> allow-update { none; };
> };
> (...)
> };
>
> view "ext" IN {
> (...)
> zone "barata.info.tm" {
> type master;
> file "barata.info.tm-EXT";
> allow-update { none; };
> };
> (...)
> };
Você está servindo zonas *diferentes* para os clientes de dentro e fora
da rede para o mesmo domínio? Alguma razão especial para isso?
> Dentro da rede interna a resolução funciona normal.
> Quando tento resolver num host na internet:
>
> dig barata.info.tm @189.X.X.X
Basicamente a mesma coisa que eu vi.
> Porém os logs indicam que:
>
> 23-Mar-2009 11:13:36.178 queries: client 201.X.X.X#1463: view ext:
> query: barata.info.tm IN A +
Suspeito que seja alguma regra de firewall do roteador ou do servidor
DNS. Como você só postou a tabela "nat", e só um pedaço dela, fica
difícil dizer.
Se eu estiver correto, essa regra deve resolver:
iptables -I FORWARD -j ACCEPT -m state --state ESTABLISHED,RELATED
Mas é claro, seria melhor ver como está o seu firewall antes, para saber
se essa regra é sequer relevante,
> tcpdump -i ethX -n proto UDP
> 11:41:52.783267 IP 201.X.X.X.1464 > 192.168.0.3.53: 45124+ A?
> barata.info.tm. (32)
> 11:41:52.785128 IP 192.168.0.3.53 > 201.X.X.X..1464: 45124*- 1/1/0 A
> 189.X.X.X (75)
Esse dump foi tirado no servidor DNS ou no roteador? Por ele tudo indica
que é problema de firewall em um ponto mais adiante na rede. Se o
roteador não tiver conntrack pode ocorrer esse problema também.
> dig barata.info.tm @::1
Isso só mostra que a interface "lo" não está filtrada, o que não é nada
espantoso.
> ;; AUTHORITY SECTION:
> barata.info.tm. 43200 IN NS meuhost.noip
Mas isso é ruim. Seu NS fornecido pelo domínio pai difere do NS
fornecido pelo seu servidor autoritativo. Tanto em TTL quanto,
aparentemente, nome também. Isso causa uma confusão imensa.
> Ou seja, não é problema com a view.
*HÁ* um problema com a view. Pelo menos você não deveria estar servindo
zonas diferentes para clientes internos e externos.
> Alguém já implementou um DNS com bind9 atrás de um NAT?
> É necessário outras portas além da TCP/UDP 53?
De entrada, só as portas 53/tcp e 53/udp mesmo. De saída, todas.
> Estou usando slackware 12.2 com bind 9.4.1-P1.
> Não existe nenhuma regra de firewall no DNS.
O problema está parecendo as regras de firewall do roteador.
Abraços,
Juliano.
--
Juliano F. Ravasi ·· http://juliano.info/
5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96
"A candle loses nothing by lighting another candle." -- Erin Majors
* NOTE: Don't try to reach me through this address, use "contact@" instead.
---------------------------------------------------------------------------
Esta lista é patrocinada pela Conectiva S.A. Visite http://www.conectiva.com.br
Arquivo: http://bazar2.conectiva.com.br/mailman/listinfo/linux-br
Regras de utilização da lista: http://linux-br.conectiva.com.br
FAQ: http://www.zago.eti.br/menu.html
