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-´a configurar quando da chamada do aplicativo servi-dor tantos nodos quantos se desejar, para que estes resolvam ou ajudem a resolver nomes de diferentes dominios. Haver´a tamb´em um cliente, respons´avel por realizar as requisi¸c˜oes aos servidores. Este cliente ser´a chamado sob demanda, quando se desejar resolver algum nome. Uma vez que o cliente ´e chamado, ele receber´a, quando da resposta do servidor, o endere¸co IP do dom´ınio enviado por parˆametro, caso este tenha sido encontrato, ou uma mensagem de dom´ınio n˜ao encontrado.
1
Objetivo
Ilustrar o funcionamento do sistema de resolu¸c˜ao de nomes de dom´ınio DNS.
2
Premissas
O funcionamento do sistema n˜ao depende de uma infra-estrutura de rede completa, bastando existir a implementa¸c˜ao de uma pilha TCP/IP no sistema operacional em uso no ambiente de testes.
´
E necess´ario que o usu´ario executando o sistema tenha permiss˜ao para ge-renciar a cria¸c˜ao de sockets.
• Na chamada do aplicativo servidor, todos os seus parˆametros devem ser obrigatoriamente informados.
• O aplicativo cliente deve retornar mensagem de erro caso n˜ao encontre um servidor.
• Ao se iniciar um servidor, deve-se consistir se os dom´ınios filhos que se est´a 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´a exista algum servidor respondendo pela porta, deve-se retornar erro.
• Ao se iniciar um cliente, deve-se consistir o envio de pelo menos um do-minio para que o mesmo seja resolvido.
3
Servidor
O processo servidor ´e respons´avel por armazenar o mapeamento entre nome de dom´ınio e endere¸co IP e fornecer um meio de acesso de rede para que clientes possam realizar consultas.
Como o sistema DNS ´e baseado em uma arquitetura distribu´ıda[1] e poder˜ao ser executados diversos processos servidores em um mesmo hospedeiro, conforme a especifica¸c˜ao do trabalho, as diferentes instˆancias de servidores dever˜ao ser ini-cializadas com configura¸c˜oes de rede diferentes, variando-se o n´umero da porta onde o servi¸co aguarda conex˜ao. A configura¸c˜ao de rede com a qual o servi-dor e seus “filhos”ir˜ao esperar clientes ´e especificada por argumento de linha de comando.
As instˆancias de servidores ra´ız poder˜ao ter um n´umero arbitr´ario de servido-res “filhos”, que ser˜ao inicializados e vinculados a uma porta exclusiva e dever˜ao respeitar o dom´ınio da ra´ız a qual pertencem. Os processos de servidores con-siderados ra´ız dever˜ao por sua vez referenciarem ao servidor ra´ız principal, que ser´a sempre inicializado na porta 53.
´
E preciso informar qual o servidor raiz para cada novo servidor a fim de se estabelecer a tabela de mapeamento. Atrav´es desta tabela que as consultas poder˜ao ser respondidas.
Tamb´em ´e 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¸c˜ao, faz-se necess´ario estabelcer um protocolo de comunica¸c˜ao entre servidores e clientes.
Ser´a implementado uma vers˜ao 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´odigos de mensagens que ser˜ao implementadas no sistema. A seguir veremos uma descri¸c˜ao de uso de cada.
C´odigo Descri¸c˜ao
REGISTER Registra nodos filhos informados no argumento WHOIS Pergunta qual o IP para o dom´ınio no argumento ANSWER A mensagem contˆem no argumento o IP procurado NOTFOUND Dom´ınio n˜ao encontrado
Tabela 1: Comandos do sistema
3.2.1 REGISTER
Usado quando uma nova instˆancia de servidor ´e inicializada. Informa `a ra´ız os dom´ınios(especificados por argumento em linha de comando) pelos quais ´e respons´avel. 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.
3.2.2 WHOIS
Pode ser usado pelo cliente ao consultar o servidor ra´ız ou para consulta entre servidores. O argumento passado ´e 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 ´ultimo cliente pode tamb´em ser um servidor que repassa a pergunta adiante, dessa forma estabelece-se o processo recursivo de consulta, onde a pergunta ´e enviada at´e o servidor que possui a resposta e retorna atrav´es de todos os demais servidores pelo qual passou.
Figura 3: Diagrama de estado do processo de consulta envolvendo o c´odigo de mensagem WHOIS e ANSWER.
3.2.3 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´a uma tabela mapeando as consultas que realizou e a origem, quando necess´ario.
A resposta ser´a composta por pares “dom´ınio = IP”separados por virgula caso mais de um dom´ınio tenha sido consultado.
3.2.4 NOTFOUND
Informa ao agente que efetuou a pergunta que o dom´ınio n˜ao foi encontrado em nenhum servidor dispon´ıvel. Os argumentos para mensagens deste tipo ser˜ao o endere¸co de rede do agente que realizou a consulta e o dom´ınio consultado, separados por v´ırgula.
A mensagem NOTFOUND ser´a gerada no ´ultimo servidor dispon´ıvel na hierarquia estabelecida caso n˜ao seja encontrada nenhuma resposta satisfat´oria.
3.3
Troca de Mensagens
A seguir ser´a especificado para cada processo definido no sistema o diagrama de tempo para a troca de mensagens.
3.3.1 Registro
O processo de registro de novos servidores compreende a inicializa¸c˜ao do mesmo com seus n´odos filhos e a comunica¸c˜ao ao servidor ra´ız da existˆencia de um novo n´odo na rede. O diagrama de tempo da figura 4 ilustra estre processo inicial.
Figura 4: Diagrama de tempo do processo de registro de novos servidores.
Os servidores filhos n˜ao ir˜ao enviar mensagens de rede `a sua ra´ız, visto que s˜ao inicializados no mesmo processo, e portanto suas associa¸c˜oes s˜ao geradas concomitantemente.
3.3.2 Consulta
A consulta `a tabela de dom´ınios de outro servidor ´e ass´ıncrona, e a fonte geradora n˜ao manter´a a mesma conex˜ao 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 ´e obtida de maneira recursiva, ou seja, ´e repassada ao ´ultimo servidor que efetuou a pergunta, e este por sua vez repassa `a origem. Ser´a mantido em cada servidor al´em da tabela de cache uma tabela com a origem e consulta que foram realizadas atrav´es do mesmo, a fim de estabelecer-se um v´ınculo para resposta.
O caso onde mais de um servidor ´e consultado e nenhuma resposta autori-tativa ´e encontrada ´e ilustrado na figura 7.
4
Interface
O sistema ´e implementado na arquitetura cliente-servidor, e ser´a executado em ambiente linha de comando.
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 ´e consultado por´em n˜ao ´e encontrada uma resposta autoritativa
4.1
Servidor
O aplicativo servidor ir´a oferecer as seguintes op¸c˜oes de configura¸c˜ao em linha de comando:
• domain: o dom´ınio pelo qual o nodo servidor ´e respons´avel; • parent: determina o endere¸camento do nodo pai;
• children: inicializa o nodo filho, identificando o dominio pelo qual ´e res-pons´avel e seu endere¸camento;
• authority: n´umero vari´avel de endere¸cos que s˜ao respondidos de forma autoritativa
• cachesize: tambem nao faz sentido
Poder˜ao ser informados diversos nodos filhos bem como rela¸c˜oes autoritati-vas.
4.2
Cliente
Ir´a realizar a consulta para os dom´ınios especificados em linha de comando com o argumento resolve no servidor especificado pelo argumento local. ´E espe-rada uma resposta do tipo “consulta realizada em XXms: dominio = IP”caso o dom´ınio tenha sido encontrado, ou “dom´ınio n˜ao encontrado”caso contr´ario.
Referˆ
encias
[1] STEVENS, W. Richard; TCP-Illustrated: the protocols Addisson-Wesley professional computing series, ISBN 0-201-63346-9
