Administração de Redes

Trabalho 4 - DNS

Teoria/Howto/Referências

Notas prévias

O comando rndc usa-se para controlar (local ou remotamente) o servidor de nomes (named), e.g., para carregar uma configuração actualizada (rndc reload) ou para limpar a cache (rndc flush).
Por uma questão de segurança, é aconselhável mudar a chave default para comunicação entre o rndc e o named. Pode gerar uma nova chave usando o seguinte comando:
```
rndc-confgen -a -b 384 -k rndc-key
```
Este comando cria (ou modifica) o ficheiro /etc/rndc.key, com a definição de uma chave com o seguinte aspecto:
```
key "rndc-key" {
        algorithm hmac-md5;
        secret "TqeiABSAEUqqREJhDDkHrcMK9o7mnNihXEbMAW/dBSU=";
};
```
Se o ficheiro /etc/rndc.conf existir, certifique-se de que não contém a definição dessa chave (se contiver, apague-a) mas inclui o /etc/rndc.key. Exemplo de configuração:
```
include "/etc/rndc.key";
options {
    default-server   localhost;
    default-key      rndc-key;
};
```
Faça o mesmo em relação ao ficheiro /etc/named.conf, certificando-se ainda de que a secção controls está configurada para usar a chave definida, e.g.:
```
include "/etc/rndc.key";
controls {
    inet 127.0.0.1 port 953
    allow { 127.0.0.1; } keys { rndc-key; };
};
```
Para verificar se o named.conf e os ficheiros de zona estão correctos pode utilizar, respectivamente, named-checkconf e named-checkzone {zone} {file}, onde file é o pathname do ficheiro de zona. Faça sempre estes testes antes de pôr o serviço a correr.
Sempre que alterar as configurações e fizer rndc reload para as activar, verifique nos logs que não ocorreram erros.
Para resolver nomes, usam-se os comandos host ou dig. Normalmente, o servidor a consultar é o indicado no ficheiro /etc/resolv.conf, que é actualizado ao obter endereços por DHCP. Se quisermos usar outro servidor (e.g., 172.16.0.2), podemos especificá-lo na linha de comando:
host www.dcc.fc.up.pt 172.16.0.2 dig @172.16.0.2 www.dcc.fc.up.pt
Depois de fazer as configurações iniciais e antes de iniciar a resolução das questões, e usando um dos comandos acima descritos, certifique-se de que consegue consultar qualquer um dos servidores DNS configurados a partir do terminal 1 e do outro servidor DNS. Se não conseguir, verifique no named.conf as opções listen-on e allow-query.
Por questões de segurança, o bind (processo named) não corre como root, mas sim como named. Para que possa ler os ficheiros de zona, certifique-se de que estes pertencem ao grupo named.

Objectivo

Implementar a seguinte rede:
Rede Trabalho 4

Montagem

Configuração da rede
- Para implementar a rede emulada, arranque o GNS3 no terminal, que deve ser o PC com 3 placas de rede. Pode usar esta topologia e esta configuração para o router R1. A configuração fornecida faz NAT (masquerading) das redes internas. O router também está configurado para servir aos servidores DNS e ao terminal, por DHCP, os endereços IP indicados. Altere os client identifiers nas diferentes pools de acordo com os endereços MAC das suas máquinas. Se necessário, altere também as interfaces do ficheiro .gns3 de acordo com as existentes na máquina onde corre o GNS3 (term1).
Configuração do DNS
- A máquina dns.lr-gX.pt é o servidor master do domínio lr-gX.pt.
- A máquina dns.dept.lr-gX.pt é o servidor master do sub-domínio dept do domínio lr-gX.pt.
- Deve configurar os servidores para resolução de nomes directa e inversa
- Além de masters, ambos os servidores devem funcionar também como caching nameservers, permitindo recursão apenas para a gama de endereços IP da respectiva rede local.
- Deverá configurar mail.lr-gX.pt (endereço IP 172.16.0.7) como servidor de email (entrada MX) em ambos os servidores DNS.
- Deve haver uma entrada para o router em ambos os domínios.
- Deve configurar um alias www.lr-gX.pt para o dns.lr-gX.pt.
- Por enquanto, nenhum dos servidores tem slaves.
- Para simplificar as capturas, no named.conf dos servidores DNS deve ter o DNSSEC desactivado:
```
     dnssec-enable no;
     dnssec-validation no;
     dnssec-lookaside no;
```

Entregáveis

dump da configuração iniciais das máquinas linux (DNSs e terminal) devidamente identificadas
- rotas (route -n)
- configuração IP (ifconfig)
- named.conf (apenas nos servidores DNS)
- ficheiros com as zonas em formato canónico, i.e., o resultado de named-checkzone -D <zona> <ficheiro> para cada zona (apenas nos servidores DNS)
- ficheiros ACL eventualmente usados no Bind (apenas nos servidores DNS)
- fragmentos de ficheiros de configuração pedidos nas questões indicadas como confRes
Um relatório em formato PDF contendo
- respostas às questões indicadas abaixo (a necessidade de resposta textual é indicada com texRes) Não são aceitáveis respostas iguais em diferentes grupos. Os trabalhos são para ser feitos exclusivamente pelos elementos do grupo.
- comandos ou fragmentos de ficheiros de configuração pedidos nas questões indicadas como confRes
- output de comandos como o ping ou o traceroute nas questões indicadas como outRes (em texto com fonte de tamanho fixo, para melhor visibilidade)
- screenshots com o resultado da captura de pacotes nas questões indicadas como capRes; salvo indicação explícita, as capturas são feitas com o wireshark
  - deverão ser claramente visíveis todos os campos relevantes dos pacotes
  - deve haver sempre uma indicação clara de que pacotes (entre os capturados) são relevantes para a questão, ou então usado um filtro para mostrar apenas esses.

Nota: em qualquer dump ou captura deve indicar sempre o comando; nas capturas deve indicar sempre os filtros que eventualmente tenha utilizado.

Questões/Traces/Análise

No dns.lr-gX.pt, descubra o servidor de email do domínio dept.lr-gX.pt usando host -t mx dept.lr-gX.pt. (outRes)
No dns.dept.lr-gX.pt, limpe a cache de DNS (rndc flush) e inicie uma captura wireshark. Em term1, tente descobrir o servidor de email do domínio lr-gX.pt. Explique o que se passou. (capRes + texRes)
No dns.dept.lr-gX.pt, limpe cache de DNS e inicie uma captura wireshark. Em term1 use o comando dig para resolver o nome www.jn.pt.

Recorrendo à captura feita, diga qual foi o caminho seguido pelo(s) pedido(s) do registo A e respectiva(s) resposta(s). Na imagem da captura deverá mostrar apenas os pacotes relevantes. (capRes + texRes)
Indique se a resposta dada ao terminal é autoritativa, identificando os campos da mensagem que o levam a essa conclusão. (capRes + texRes)
Diga se a resposta obtida pelo dns.dept.lr-gX.pt é autoritativa e justifique. (texRes)
Note que existe mais do que um endereço para este nome e que a ordem dos endereços é round-robin. Que vantagens se podem obter destes factos? (texRes)

Diga o que entende por glue record e qual a sua utilidade. Foi necessário usar um nesta montagem? Em caso afirmativo, em que máquina? (texRes)
Quando é usado NAT, a resolução de endereços tem que ser diferente consoante o pedido veio de uma máquina interna ou externa. Isto faz-se usando vistas.
Nesta pergunta vamos alterar o NAT no router R1 para NAT puro (sem tradução de portas), de modo a que as máquinas da rede 172.16.0.0/24 sejam vistas no exterior como pertencendo à rede 192.168.80.0/24, mantendo a parte de host. Para tal, corra em R1 (modo de configuração) os seguintes comandos:
```
no ip nat inside source list 2 interface FastEthernet2/0 overload
ip nat inside source static network 172.16.0.0 192.168.80.0 /24 no-alias no-payload
```
1. Configure vistas no dns.lr-gX.pt de modo a que, quando os pedidos são feitos de fora das redes 172.16.0.0/24 ou 10.0.0.0/24, os endereços retornados estejam na rede 192.168.80.0/24 (em vez de 172.16.0.0/24). Indique as alterações que teve de fazer nos ficheiros de configuração. (confRes)
2. Teste a configuração da vista interna descobrindo o endereço IP de router.lr-gX.pt a partir do próprio dns.lr-gX.pt. (outRes)
3. Para testar a configuração da vista externa, desligue o dns.dept.lr-gX.pt e ligue-o directamente na rede do laboratório. Pare o serviço named (pois vai funcionar apenas como terminal) e adicione uma rota para a rede 192.168.80.0/24 através do 192.168.56.a (o endereço IP obtido por DHCP pelo router Cisco na interface f2/0). Obtenha o endereço IP de router.lr-gX.pt usando o comando host router.lr-gX.pt. 192.168.80.2 (outRes)
Após concluir esta questão, volte a a ligar o ns.dept.lr-gX.pt na localização inicial e reactive nessa máquina o serviço named. Reponha a configuração original no router R1. Reponha também a configuração anterior a esta pergunta (sem vistas) no ns.lr-gX.pt.
Sendo o DNS um serviço fundamental na rede, praticamente todas as redes implementam, além do master, um ou mais servidores slave para obter tolerância a falhas e/ou distribuição de carga. Faça as alterações necessárias aos ficheiros de configuração para que dns.lr-gX.pt funcione também como slave de dns.dept.lr-gX.pt para o subdomínio dept.lr-gX.pt.
1. Indique as alterações que teve de fazer nos ficheiros de configuração. (confRes)
2. Faça uma captura de pacotes em dns.dept.lr-gX.pt e active as novas configurações. Identifique na captura a transferência do domínio dept.lr-gX.pt do master para o slave. (capRes) Se já tinha activado as novas configurações antes de fazer a captura, provavelmente não será feita nova transferência de domínio. Se isto acontecer, vá ao dns.lr-gX.pt, pare o serviço named, apague os ficheiros slave, volte a iniciar o serviço named e repita esta alínea.
3. Antes da transferência de domínio é feito um outro pedido para o registo SOA. Explique para que serve este registo e por que razão é pedido antes de fazer a transferência de domínio. (texRes)
4. Verifica alguma diferença entre o protocolo de transporte usado para a transferência de domínio e o normalmente usado para as outras perguntas DNS? Qual a razão para essa diferença? (texRes)
5. No dns.lr-gX.pt, faça uma captura de pacotes na pseudo-interface any. Teste a nova configuração descobrindo o servidor de email de dept.lr-gX.pt a partir de dns.lr-gX.pt. (capRes)
6. A resposta que obteve na alínea anterior é autoritativa? Justifique. (texRes)
A configuração da zona ".", do tipo hint, necessita dum ficheiro (normalmente chamado named.ca). Observe o conteúdo desse ficheiro e explique a sua função. (texRes)