| Problema:
Configurar um "cache" externo em 1.2.3.4
para clientes na rede 1.2.3.*.
| Solução usando BIND:
- Criar um arquivo tipo zone localhost,
com um registro SOA , um registro NS , e um registro A.
- Criar um arquivo tipo zone 0.0.127.in-addr.arpa,
com um registro SOA, um registro NS, e um registro PTR.
- Criar um arquivo tipo zone root.hints
com o endereço IP dos servidores de nome roots.
- Criar um arquivo named.conf:
zone "localhost" in { type master; file "localhost"; };
zone "0.0.127.in-addr.arpa" in { type master; file "0.0.127.in-addr.arpa"; };
zone "." in { type hint; file "root.hints"; };
options { interface-interval 0; listen-on { 1.2.3.4; }; allow-query { 1.2.3/24; }; };
- Iniciar named.
- Confira se o seu boot scripts inicia named.
| Solução usando djbdns:
- Criar contas dnscache e dnslog.
- dnscache-conf dnscache dnslog /etc/dnscachex 1.2.3.4
- ln -s /etc/dnscachex /service
- cd /service/dnscachex
- touch root/ip/1.2.3
|
| Problema:
Permitir que os clientes da rede 1.5.* também possam fazer requisições de DNS.
| Solução usando BIND:
- Editar named.conf.
- Adicionar 1.5/16 na sessão allow-query.
- Enviar um sinal HUP para named.
- Procurar por erros no arquivo de log do seu sistema.
| Solução usando djbdns:
- cd /service/dnscachex
- touch root/ip/1.5
|
| Problema:
Rodar o cache com acesso não-root.
| Solução usando BIND:
- Criar uma conta bindin.
- mkdir /etc/bindin
- Copiar vários programas,
bibliotecas e devices em /etc/bindin.
- Matar o processo named.
- Iniciar named -u bindin -t /etc/bindin.
- Alterar as linhas named nos seus scripts de boot de acordo.
| Solução usando djbdns:
O cache já vem com acesso não-root.
|
| Problema:
Arrumar o cache para que ele seja reiniciado se alguém acidentalmente "matá-lo".
| Solução usando BIND:
Escreva um script que procura pelo processo
named, reinicia
named se ele não estiver rodando,
pausa por um tempo, e repete tudo de novo.
Inicie esse script.
| Solução usando djbdns:
O cache já é monitorado, e é reiniciado automaticamente.
|
| Problema:
Avisar o cache para consultar um servidor interno
no endereço 10.1.2.5
para informações sobre moon.x.mil.
| Solução usando BIND:
- Edite named.conf.
- Adicione um "forwarding zone":
zone "moon.x.mil" in { type forward; forward only; forwarders { 10.1.2.5; }; };
- Envie um sinal HUP para named.
- Procure por erros no log do seu sistema.
| Solução usando djbdns:
- cd /service/dnscachex
- echo 10.1.2.5 > root/servers/moon.x.mil
- svc -t .
|
| Problema:
Avisar o cache para seguir uma nova delegação a partir do servidor interno
para resolver 10.1.2.6 como d.moon.x.mil.
| Solução usando BIND:
- Editar named.conf.
- Adicione outra "forwarding zone":
zone "d.moon.x.mil" in { type forward; forward only; forwarders { 10.1.2.6; }; };
- Envie um sinal HUP para named.
- Procure por erros no log do seu sistema.
| Solução usando djbdns:
O cache segue delegações.
|
| Problema:
Configurar um servidor em 1.2.3.5
para publicar informações sobre x.mil e 1.2.3.*.
| Solução usando BIND:
- Criar um x.mil zone file,
with an SOA record and an NS record.
- Criar um 3.2.1.in-addr.arpa zone file,
with an SOA record and an NS record.
- Criar um named.conf file:
zone "x.mil" in { type master; file "x.mil"; };
zone "3.2.1.in-addr.arpa" in { type master; file "3.2.1.in-addr.arpa"; };
options { interface-interval 0; listen-on { 1.2.3.5; }; recursion no; fetch-glue no; allow-transfer { none; }; };
- Start named.
- Make sure that your boot scripts start named.
| Solução usando djbdns:
- Criar contas tinydns e dnslog.
- tinydns-conf tinydns dnslog /etc/tinydns 1.2.3.5
- ln -s /etc/tinydns /service
- cd /service/tinydns/root
- ./add-ns x.mil 1.2.3.5
- ./add-ns 3.2.1.in-addr.arpa 1.2.3.5
- make
|
| Problema:
Fazer o servidor rodar com acesso não-root.
| Solução usando BIND:
- Criar uma conta bindout.
- mkdir /etc/bindout
- Copiar vários programas,
bibliotecas e devices
em /etc/bindout.
- "Matar" named.
- Iniciar named -u bindout -t /etc/bindout.
- Mude a linha named em seus scripts de boot de acordo.
| Solução usando djbdns:
O servidor, como o cache, já funciona com acesso não-root.
|
| Problema:
Adicionar um novo host, lion.x.mil,
com endereço 1.2.3.4.
| Solução usando BIND:
- Editar a zona x.mil.
- Adicione lion A 1.2.3.4.
- Mudar o número serial no registro SOA.
- Editar a zona 3.2.1.in-addr.arpa.
- Adicione 4 PTR lion.x.mil.
- Mudar o número serial no registro SOA.
- Enviar um sinal HUP para named.
- Procure por erros no arquivo de log.
| Solução usando djbdns:
- cd /service/tinydns/root
- ./add-host lion.x.mil 1.2.3.4
- make
|
| Problema:
Evitar usar novamente um nome de host acidentalmente,
ou usar novamente um mesmo endereço IP.
| Solução usando BIND:
Busque manualmente o arquivo de zonas pelo novo nome de host
e pelo novo endereço IP.
Você não terá que procurar muito,
se você ordenou as zonas por ordem alfabética
e se você ordenou as zonas reversas pelos endereços.
| Solução usando djbdns:
add-host cuida disso automaticamente.
(Se você quer usar novamente um nome ou um endereço,
use add-alias.)
|
| Problema:
Evitar destruir uma zona se surgirem problemas na hora de salvar os dados novos:
por exemplo, sem espaço disponível em disco,
ou uma súbita falta de energia.
| Solução usando BIND:
- Copie o arquivo de zonas.
- Edite a cópia.
- Sincronize (sync) a cópia para o disco.
- Renomeie a copia.
| Solução usando djbdns:
add-host cuida disso automaticamente.
|
| Problema:
Confirmar que não há nenhum erro de sintaxe nos dados novos.
| Solução usando BIND:
Olhe o log do sistema para ver se há mensagens de erros.
Algumas mensagens significam que
named não está mais provendo informações sobre aquela zona,
e usuários vão começar a ver falhas em questão de segundos.
neste caso, entre em pânico.
| Solução usando djbdns:
Se há um erro de sintaxe,
make irá imprimir uma mensagem de erro imediatamente,
e tinydns vai continuar provendo informações com os dados antigos.
|
| Problema:
Enviar e-mails que chegam para x.mil
para um servidor de e-mail em 1.2.3.4.
| Solução usando BIND:
- Edite a zona x.mil.
- Adicione @ MX 0 lion.
- Altere o número serial no registro SOA.
- Envie um sinal HUP para named.
- Procure por erros no arquivo de log.
| Solução usando djbdns:
- cd /service/tinydns/root
- ./add-mx x.mil 1.2.3.4
- make
|
| Problema:
Delegar elysium.x.mil
para um servidor DNS em 1.2.3.144.
| Solução usando BIND:
- Edit the x.mil zone.
- Add elysium NS a.ns.elysium.
- Add a.ns.elysium A 1.2.3.144.
- Altere o número serial no registro SOA.
- Envie um sinal HUP para named.
- Procure por erros no arquivo de log.
| Solução usando djbdns:
- cd /service/tinydns/root
- ./add-childns elysium.x.mil 1.2.3.144
- make
|
| Problema:
Replicar o serviço DNS de 1.2.3.5 para 1.2.3.6.
| Solução usando BIND:
Em 1.2.3.5:
- Editar named.conf.
- Inserir 1.2.3.6; na seção allow-transfer.
- Editar o arquivo x.mil.
- Adicionar um registro NS apontando para 1.2.3.6.
- Editar o arquivo 3.2.1.in-addr.arpa.
- Adicionar um registro NS apontando para 1.2.3.6.
- Envie um sinal HUP para named.
- Procure por erros no arquivo de log.
Em 1.2.3.6:
- Criar um arquivonamed.conf:
zone "x.mil" in { type slave; file "x.mil"; masters { 1.2.3.5; }; };
zone "3.2.1.in-addr.arpa" in { type slave; file "3.2.1.in-addr.arpa"; masters { 1.2.3.5; }; };
options { interface-interval 0; listen-on { 1.2.3.5; }; recursion no; fetch-glue no; allow-transfer { none; }; };
- Iniciar named.
- Confirme que o seus scripts de boot iniciam named.
| Solução usando djbdns:
Em 1.2.3.6:
- Criar contas tinydns e dnslog.
- tinydns-conf tinydns dnslog /etc/tinydns 1.2.3.6
- ln -s /etc/tinydns /service
Em 1.2.3.5:
- cd /service/tinydns/root
- No inicio de Makefile,
adicione um target remote: data.cdb,
com o comando:
rsync -az -e ssh data.cdb 1.2.3.6:/ service/ tinydns/ root/ data.cdb.
- ./add-ns x.mil 1.2.3.6
- ./add-ns 3.2.1.in-addr.arpa 1.2.3.6
- make
|
| Problema:
Replicar uma zona recém criada.
| Solução usando BIND:
- Editar named.conf.
- Adicionar uma nova linha type slave.
- Envie um sinal HUP para named.
- Procure por erros no arquivo de log.
| Solução usando djbdns:
Novas zonas são automaticamente replicadas.
|