Registros e mensagens DNS
Os servidores de nomes que juntos implementam o banco de dados distribuído do DNS armazenam registros de recursos (RR) que fornecem mapeamentos de nomes de hospedeiros para endereços IP. Cada mensagem de resposta DNS carrega um ou mais registros de recursos. Nesta seção e na subsequente, apresentaremos uma breve visão geral dos registros de recursos e mensagens DNS. Para mais detalhes, consulte [Abitz, 1993] ou [RFC 1034; RFC 1035].
Um registro de recurso é uma tupla de quatro elementos que contém os seguintes campos: (Name, Value, Type, TTL)
TTL é o tempo de vida útil do registro de recurso; determina quando um recurso deve ser removido de um cache. Nos exemplos de registros dados a seguir, ignoramos o campo TTL. Os significados de Name e Value dependem de Type:
- Se Type=A, então Name é um nome de hospedeiro e Value é o endereço IP para o nome de hospedeiro. Assim, um registro Type A fornece o mapeamento padrão de nomes hospedeiros para endereços IP. Como exemplo, (relay1.bar.foo.com, 145.37.93.126, A) é um registro com Type igual a A.
- Se Type=NS, então Name é um domínio (como foo.com) e Value é o nome de um servidor de nomes com autoridade que sabe como obter os endereços IP para hospedeiros do domínio. Esse registro é usado para encaminhar consultas DNS ao longo da cadeia de consultas. Como exemplo, (foo.com, dns.foo.com, NS) é um registro com Type igual a NS.
- Se Type=CNAME, então Value é um nome canônico de hospedeiro para o apelido de hospedeiro contido em Name. Esse registro pode fornecer aos hospedeiros consultantes o nome canônico correspondente a um apelido de hospedeiro. Como exemplo, (foo.com, relay1.bar.foo.com, CNAME) é um registro CNAME.
- Se Type=MX, então Value é o nome canônico de um servidor de correio cujo apelido de hospedeiro está contido em Name. Como exemplo, (foo.com. mail.bar.foo.com, MX) é um registro MX. Registros MX permitem que os nomes de hospedeiros de servidores de correio tenham apelidos simples. Note que usando o registro MX, uma empresa pode ter o mesmo apelido para seu servidor de arquivo e para um de seus outros servidores (tal como seu servidor Web). Para obter o nome canônico do servidor de correio, um cliente DNS consultaria um registro MX; para obter o nome canônico do outro servidor, o cliente DNS consultaria o registro CNAME.
Se um servidor de nomes tiver autoridade para um determinado nome de hospedeiro, então conterá um registro Type A para o nome de hospedeiro. (Mesmo que não tenha autoridade, o servidor de nomes pode conter um registro Type A em seu cache.) Se um servidor não tiver autoridade para um nome de hospedeiro, conterá um registro Type NS para o domínio que inclui o nome e um registro Type A que fornece o endereço IP do servidor de nomes no campo Value do registro NS. Como exemplo, suponha que um servidor TLD edu não tenha autoridade para o hospedeiro gaia.cs.umass.edu. Nesse caso, esse servidor conterá um registro para um domínio que inclui o hospedeiro gaia.cs.umass.edu, por exemplo (umass.edu, dns.umass.edu, NS). O servidor TLD edu conterá também um registro Type A, que mapeia o servidor de nome dns.umass.edu para um endereço IP, por exemplo (dns.umass.edu, 128.119.40.111, A).
Mensagens DNS
Abordamos anteriormente nesta seção mensagens de consulta e de resposta DNS, que são as duas únicas espécies de mensagem DNS. Além disso, tanto as mensagens de consulta como as de resposta têm o mesmo formato, como mostra a Figura 2.23. A semântica dos vários campos de uma mensagem DNS é a seguinte:
- Os primeiros 12 bytes formam a seção de cabeçalho, que tem vários campos. O primeiro campo é um número de 16 bits que identifica a consulta. Esse identificador é copiado para a mensagem de resposta a uma consulta, permitindo que o cliente combine respostas recebidas com consultas enviadas. Há várias flags no campo de flag. Uma flag de consulta/resposta de 1 bit indica se a mensagem é uma consulta (0) ou uma resposta (1). Uma flag de autoridade de 1 bit é marcada em uma mensagem de resposta quando o servidor de nomes é um servidor com autoridade para um nome consultado. Uma flag de recursão desejada de 1 bit é estabelecida quando um cliente (hospedeiro ou servidor de nomes) quer que um servidor de nomes proceda recursivamente sempre que não tem o registro. Um campo de recursão disponível de 1 bit é marcado em uma resposta se o servidor de nomes suporta buscas recursivas. No cabeçalho, há também quatro campos de ‘número de’. Esses campos indicam o número de ocorrências dos quatro tipos de seção de dados que se seguem ao cabeçalho.
- A seção de pergunta contém informações sobre a consulta que está sendo feita. Essa seção inclui (1) um campo de nome que contém o nome que está sendo consultado e (2) um campo de tipo que indica o tipo de pergunta que está sendo feito sobre o nome — por exemplo, um endereço de hospedeiro associado a um nome (Type A) ou o servidor de correio para um nome (Type MX).
- Em uma resposta de um servidor de nomes, a seção de resposta contém os registros de recursos para o nome que foi consultado originalmente. Lembre-se de que em cada registro de recurso há o Type (por exemplo, A, NS, CSNAME e MX), o Value e o TTL. Uma resposta pode retornar vários RRs, já que um nome de hospedeiro pode ter diversos endereços IP (por exemplo, para servidores Web replicados, como já discutimos anteriormente nesta seção).
- A seção de autoridade contém registros de outros servidores com autoridade.
- A seção adicional contém outros registros úteis. Por exemplo, o campo resposta em uma resposta a uma consulta MX conterá um registro de recurso que informa o nome canônico de um servidor de correio. A seção adicional conterá um registro Type A que fornece o endereço IP para o nome canônico do servidor de correio.
(networkutopia.com, dns1.networkutopia.com, NS)(dns1.networkutopia.com, 212.212.212.1, A)
Não esqueça de providenciar também a inserção em seus servidores de nomes com autoridade do registro de recurso Type A para seu servidor Web www.networkutopia.com e o registro de recurso Type MX para seu servidor de correio mail.networkutopia.com. (Até há pouco tempo, o conteúdo de cada servidor DNS era configurado estaticamente, por exemplo, a partir de um arquivo de configuração criado por um gerenciador de sistema. Mais recentemente, foi acrescentada ao protocolo DNS uma opção UPDATE que permite que dados sejam dinamicamente acrescentados no banco de dados ou apagados deles por meio de mensagens DNS. O [RFC 2136] e o [RFC 3007] especificam atualizações dinâmicas do DNS.)
Quando todas essas etapas estiverem concluídas, o público em geral poderá visitar seu site Web e enviar e-mails aos empregados de sua empresa. Vamos concluir nossa discussão do DNS verificando que essa afirmação é verdadeira, o que também ajudará a solidificar aquilo que aprendemos sobre o DNS. Suponha que Alice, que está na Austrália, queira consultar a página Web www.networkutopia.com. Como discutimos anteriormente, seu hospedeiro primeiramente enviará uma consulta DNS a seu servidor de nomes local, que então contatará um servidor TLD do domínio com. (O servidor de nomes local também terá de contatar um servidor de nomes raiz caso não tenha em seu cache o endereço de um servidor TLD com.) Esse servidor TLD contém os registros de recursos Type NS e Type A citados anteriormente, porque a entidade registradora já os tinha inserido em todos os servidores TLD com. O servidor TLD com envia uma resposta ao servidor de nomes local de Alice, contendo os dois registros de recursos. Então, o servidor de nomes local envia uma consulta DNS a 212.212.212.1, solicitando o registro Type A correspondente a www.networkutopia.com. Este registro provê o endereço IP do servidor Web desejado, digamos, 212.212.71.4, que o servidor local de nomes transmite para o hospedeiro de Alice. Agora, o browser de Alice pode iniciar uma conexão TCP com o hospedeiro 212.212.71.4 e enviar uma requisição HTTP pela conexão. Ufa! Acontecem muito mais coisas do que percebemos quando navegamos na Web!
Comentários
Postar um comentário