MicroDNS. Armando Adami Zaro Pablo Augusto Lerina Rodrigues. 3 de outubro de 2007

Transcrição

1 MicroDNS Armando Adami Zaro Pablo Augusto Lerina Rodrigues 3 de outubro de 2007 Resumo O projeto do MicroDns visa simular localmente o funcionamento de um DNS. Poder-se-á configurar quando da chamada do aplicativo servidor tantos nodos quantos se desejar, para que estes resolvam ou ajudem a resolver nomes de diferentes dominios. Haverá também um cliente, responsável por realizar as requisições aos servidores. Este cliente será chamado sob demanda, quando se desejar resolver algum nome. Uma vez que o cliente é chamado, ele receberá, quando da resposta do servidor, o endereço IP do domínio enviado por parâmetro, caso este tenha sido encontrato, ou uma mensagem de domínio não encontrado. 1 Objetivo Ilustrar o funcionamento do sistema de resolução de nomes de domínio DNS. 2 Premissas O funcionamento do sistema não depende de uma infra-estrutura de rede completa, bastando existir a implementação de uma pilha TCP/IP no sistema operacional em uso no ambiente de testes. É necessário que o usuário executando o sistema tenha permissão para gerenciar a criação de sockets. Na chamada do aplicativo servidor, todos os seus parâmetros devem ser obrigatoriamente informados. O aplicativo cliente deve retornar mensagem de erro caso não encontre um servidor. Ao se iniciar um servidor, deve-se consistir se os domínios filhos que se está configurando pertencem ao domínio do servidor sendo inicializado. Verificar se existe algum outro servidor respondendo na mesma porta em que se pretende inicializar o novo servidor. Caso já exista algum servidor respondendo pela porta, deve-se retornar erro. 1

2 Ao se iniciar um cliente, deve-se consistir o envio de pelo menos um dominio para que o mesmo seja resolvido. 3 Servidor O processo servidor é responsável por armazenar o mapeamento entre nome de domínio e endereço IP e fornecer um meio de acesso de rede para que clientes possam realizar consultas. Como o sistema DNS é baseado em uma arquitetura distribuída[1] e poderão ser executados diversos processos servidores em um mesmo hospedeiro, conforme a especificação do trabalho, as diferentes instâncias de servidores deverão ser inicializadas com configurações de rede diferentes, variando-se o número da porta onde o serviço aguarda conexão. A configuração de rede com a qual o servidor e seus filhos irão esperar clientes é especificada por argumento de linha de comando. As instâncias de servidores raíz poderão ter um número arbitrário de servidores filhos, que serão inicializados e vinculados a uma porta exclusiva e deverão respeitar o domínio da raíz a qual pertencem. Os processos de servidores considerados raíz deverão por sua vez referenciarem ao servidor raíz principal, que será sempre inicializado na porta 53. É preciso informar qual o servidor raiz para cada novo servidor a fim de se estabelecer a tabela de mapeamento. Através desta tabela que as consultas poderão ser respondidas. Também é possível que um novo servidor tenha como sua raíz um servidor inicializado por outro como filho. 3.1 Protocolo Devida a natureza da aplicação, faz-se necessário estabelcer um protocolo de comunicação entre servidores e clientes. Será implementado uma versão simples de protocolo para troca de mensagens entre servidores bem como clientes, compreendendo basicamente em um campo para o comando e outro para argumentos, que pode ser vazio. A figura 1 mostra o formato de mensagem. Figura 1: Formato da mensagem 3.2 Mensagens A tabela 1 lista os códigos de mensagens que serão implementadas no sistema. A seguir veremos uma descrição de uso de cada. 2

3 Código REGISTER WHOIS ANSWER NOTFOUND Descrição Registra nodos filhos informados no argumento Pergunta qual o IP para o domínio no argumento A mensagem contêm no argumento o IP procurado Domínio não encontrado Tabela 1: Comandos do sistema REGISTER Usado quando uma nova instância de servidor é inicializada. Informa à raíz os domínios(especificados por argumento em linha de comando) pelos quais é responsável. O diagrama de estados da figura 2 ilustra o processo. Figura 2: Diagrama de estado do processo de registro de um nodo no servidor raíz WHOIS Pode ser usado pelo cliente ao consultar o servidor raíz ou para consulta entre servidores. O argumento passado é uma lista com os nomes de domínios a serem resolvidos. No diagrama de estados da figura 3 podemos acompanhar o processo de pergunta de domínio. O último cliente pode também ser um servidor que repassa a pergunta adiante, dessa forma estabelece-se o processo recursivo de consulta, onde a pergunta é enviada até o servidor que possui a resposta e retorna através de todos os demais servidores pelo qual passou. 3

4 Figura 3: Diagrama de estado do processo de consulta envolvendo o código de mensagem WHOIS e ANSWER ANSWER Retorna ao agente que efetuou a pergunta com o(s) IP(s) correspondentes na lista de argumentos. O agente que realizou a consulta terá uma tabela mapeando as consultas que realizou e a origem, quando necessário. A resposta será composta por pares domínio = IP separados por virgula caso mais de um domínio tenha sido consultado NOTFOUND Informa ao agente que efetuou a pergunta que o domínio não foi encontrado em nenhum servidor disponível. Os argumentos para mensagens deste tipo serão o endereço de rede do agente que realizou a consulta e o domínio consultado, separados por vírgula. A mensagem NOTFOUND será gerada no último servidor disponível na hierarquia estabelecida caso não seja encontrada nenhuma resposta satisfatória. 3.3 Troca de Mensagens A seguir será especificado para cada processo definido no sistema o diagrama de tempo para a troca de mensagens Registro O processo de registro de novos servidores compreende a inicialização do mesmo com seus nódos filhos e a comunicação ao servidor raíz da existência de um novo nódo na rede. O diagrama de tempo da figura 4 ilustra estre processo inicial. 4

5 Figura 4: Diagrama de tempo do processo de registro de novos servidores. Os servidores filhos não irão enviar mensagens de rede à sua raíz, visto que são inicializados no mesmo processo, e portanto suas associações são geradas concomitantemente Consulta A consulta à tabela de domínios de outro servidor é assíncrona, e a fonte geradora não manterá a mesma conexão para receber a resposta. Na figura 5 temos o caso feliz onde o primeiro servidor consultado possui uma resposta autoritativa. Figura 5: Diagrama de tempo do processo de consulta de domínios onde o primeiro servidor tem a resposta correta. A figura 6 ilustra o caso onde mais de um servidor precisa ser consultado e a resposta é obtida de maneira recursiva, ou seja, é repassada ao último servidor que efetuou a pergunta, e este por sua vez repassa à origem. Será mantido em cada servidor além da tabela de cache uma tabela com a origem e consulta que foram realizadas através do mesmo, a fim de estabelecer-se um vínculo para resposta. O caso onde mais de um servidor é consultado e nenhuma resposta autoritativa é encontrada é ilustrado na figura 7. 4 Interface O sistema é implementado na arquitetura cliente-servidor, e será executado em ambiente linha de comando. 5

6 Figura 6: Diagrama de tempo onde mais de um servidor precisa ser consultado, com resposta de maneira recursiva. Figura 7: Diagrama de tempo onde mais de um servidor é consultado porém não é encontrada uma resposta autoritativa 4.1 Servidor O aplicativo servidor irá oferecer as seguintes opções de configuração em linha de comando: domain: o domínio pelo qual o nodo servidor é responsável; parent: determina o endereçamento do nodo pai; children: inicializa o nodo filho, identificando o dominio pelo qual é responsável e seu endereçamento; authority: número variável de endereços que são respondidos de forma autoritativa cachetimeout: nao sei porque tem isso 6

7 cachesize: tambem nao faz sentido Poderão ser informados diversos nodos filhos bem como relações autoritativas. 4.2 Cliente Irá realizar a consulta para os domínios especificados em linha de comando com o argumento resolve no servidor especificado pelo argumento local. É esperada uma resposta do tipo consulta realizada em XXms: dominio = IP caso o domínio tenha sido encontrado, ou domínio não encontrado caso contrário. Referências [1] STEVENS, W. Richard; TCP-Illustrated: the protocols Addisson-Wesley professional computing series, ISBN