Introdução às Redes e Protocolos TCP/IP Sessão nº7 Jorge Gomes [email protected] DNS (Domain Name System) Resolução de Nomes • Os humanos são melhores com nomes do que com números – Memorizar e usar nomes de maquinas em vez de endereços IP é mais fácil – www.lip.pt 193.136.91.234 • Resolução de nomes: – Através de ficheiros locais /etc/hosts – Através de bases de dados locais (NIS / YP, NIS+) – Através do DNS /etc/hosts • Simples de usar: – Cada linha corresponde a um host – Formato: # Endereço-IP nome-canonico aliases 193.136.91.234 127.0.0.1 www.lip.pt localhost.localdomain www localhost • Não possui escalabilidade: – Não podemos introduzir todos os sistemas da Internet manualmente – Não é eficiente copiar manualmente o ficheiro para todos os sistemas após cada actualização NIS • O NIS é uma forma de distribuir informação de configuração como o /etc/hosts – É usado em redes locais • Permite o acesso a um ficheiro de hosts centralizado – Mas não podemos introduzir todos os sistemas da Internet manualmente – O NIS é relativamente complexo por servir diversos tipos de informação e objectivos Escolha • Existindo diversas fontes para a informação: – NIS, NIS+, /etc/hosts, DNS • Como é que um host (cliente) escolhe a origem da informação ? – – – – – Depende do sistema operativo e sua configuração Por exemplo nem todos os sistemas suportam NIS Alguns procuram sempre primeiro no hosts e depois no DNS Outros só usam DNS Em Linux existe o /etc/nsswitch.conf /etc/nsswitch.conf passwd: shadow: group: files nisplus nis files files nisplus nis #hosts: hosts: db files nisplus nis dns files dns #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files # rpcbootparamd or local file bootparams: nisplus [NOTFOUND=return] files ethers: netmasks: networks: protocols: rpc: services: netgroup: publickey: automount: aliases: files files files files files files nisplus nisplus files nisplus files nisplus DNS • O DNS é uma base de dados distribuída que é usada pelas aplicações TCP/IP para efectuar: – O mapeamento de nomes em endereços IP. – O mapeamento inverso de endereços IP em nomes. – Encaminhamento de Email, etc • O DNS é distribuído porque não existe nenhum sistema na Internet que possua toda a informação. – Os servidores de DNS são responsáveis por fornecer a informação. • Os servidores de DNS são mantidos por: – organizações que possuam um domínio na Internet – fornecedores de serviço IP • Os servidores e clientes DNS não são implementados no kernel dos sistema operativo. – De facto a pilha de protocolo TCP/IP não sabe da existência do DNS. DNS • Os servidores de DNS são implementados como processos (bind / named). • Os clientes de DNS são implementados como funções de biblioteca (resolver): – Com as quais a aplicação é compilada • As duas funções do DNS mais usadas são: – gethostbyname() : obtém o endereço IP a partir do nome. – gethostbyaddr() : obtém o nome a partir de um endereço. • Os dois RFCs relevantes para o DNS são: – RFC 1034 define o conceito e funcionalidade. – RFC 1035 especifica os detalhes de implementação. • O esquema de nomes do DNS é hierárquico – Similar à arvore de directórios de um sistema de ficheiros. DNS root arpa com in-addr sun 193 www edu gov mil int ripe www www www Domínios genéricos 7 org fnal 139 44 net linux pt uk ... tw uc co com dei ibm asus ftp www www Domínios nacionais Country codes ISO 3166 Domínios De topo Domínios de segundo nível DNS • Cada nó da arvore possui uma etiqueta com até 63 caracteres. – O nó de topo não possui nome. – Não existe distinção entre nomes em maiúsculas e minúsculas. • Cada nome completo lê-se de baixo para cima separando cada nível por um ponto e terminando em ponto. – Os nomes que não terminam em ponto têem de ser completados, o modo como são completados dependo do software usado. – Um nome que termina em ponto designa-se por “Fully Qualified Domain Name (FQDN)” • Os domínios de topo mil e gov são para uso dos militares e governo dos Estados Unidos. • A informação de topo da arvore de DNS é mantida num conjunto de servidores conhecido por root name servers. – Estes servidores mantêm informação sobre as delegações dos domínios de topo • A responsabilidade por outras zonas da arvore é delegada. – Uma zona é uma sub-arvore da arvore de DNS que é administrada separadamente. DNS • O DNS de topo é gerido pelo ICANN: – Existem 13 servidores da root zone do DNS de A a M – Mantém uma copia de http://www.internic.net/zones/root.zone IPv4 address IPv6 address Location Soft A 198.41.0.4 B 192.228.79.201 C 192.33.4.12 2001:503:BA3E::2:30 VeriSign 2001:478:65::53 (not in USC-ISI root zone yet) Cogent Communications distributed using anycast BIND Marina Del Rey, California, U.S. BIND distributed using anycast BIND D 128.8.10.90 University of Maryland College Park, Maryland, U.S. BIND E 192.203.230.10 NASA Mountain View, California, U.S. BIND F 192.5.5.241 distributed using anycast BIND G 192.112.36.4 distributed using anycast BIND H 128.63.2.53 U.S. Army Research Lab Aberdeen Proving Ground, Maryland, U.S. NSD I 192.36.148.17 J K 192.58.128.30 193.0.14.129 2001:7fe::53 (testing, not in root zone yet) 2001:503:C27::2:30 2001:7fd::1 Autonomica distributed using anycast BIND VeriSign RIPE NCC distributed using anycast distributed using anycast BIND NSD L 199.7.83.4 2001:500:3::42 ICANN distributed using anycast NSD M 202.12.27.33 2001:dc3::35 WIDE Project distributed using anycast BIND 2001:500:2f::f 2001:500:1::803f:235 Operator Internet Systems Consortium Defense Information Systems Agency DNS • Os servidores de topo: – Existe mais de um servidor por detrás de cada endereço IP associado às letras A a M – Algumas letras usam anycast • Anycast e DNS: – Permite replicação geográfica dos servidores – Funciona anunciando o mesmo endereço IP via BGP a partir de múltiplas localizações – Na prática permite que em cada local seja escolhido o servidor mais próximo – Permite redundância – Quando um servidor falha a sua rota é automaticamente removida – Outra rota mais distante passa a ser escolhida DNS • O ICANN controla também diversos domínios TLD genéricos: – O registo nestes domínios é delegado em registrars • O registo em “.com” e “.net”: – É operado pela Verisign sobre contrato com o ICANN • O registo em “.edu”: – É operado pelo net.educase.edu – Organização sem fins lucrativos criada pela Internet Society • Domínios nacionais são controlados por entidades nacionais: – O domínio (.pt) é controlado pela FCCN (www.dns.pt) • Podem efectuar-se registos através: – Agentes de registo (Registrars) (http://www.internic.net/alpha.html) – Companhias de web hosting – Pagam-se fees anuais DNS • Muitos domínios de segundo nível subdividem o seu domínio em mais sub-domínios de acordo: – com a sua estrutura administrativa – ou distribuição geográfica. • Uma vez que a delegação de uma zona (domínio) tenha sido efectuada é da responsabilidade da organização à qual a delegação foi efectuada: – Disponibilizar a informação sobre essa zona através da implementação de servidores de DNS. – Cada vez que um novo sistema é adicionado a uma zona o administrador da rede deve introduzir no servidor DNS correspondente o nome e endereço IP do novo sistema. • Cada zona tem de possuir um servidor de DNS primário e um ou mais servidores de DNS secundários: – Servidor de DNS primário: obtém a sua informação a partir de ficheiros em disco. – Servidor de DNS secundário: obtém a sua informação a partir de informação copiada do servidor de DNS primário. DNS • Os servidores secundários existem para garantir a disponibilidade da informação sobre uma zona em caso de falha do servidor primário. – A transferência de informação sobre uma zona entre um servidor primário e um servidor secundário chama-se transferência de zona. • As transferências de zona são sempre efectuadas pelos servidores secundários e ocorrem quando: – Um servidor de DNS primário lê os ficheiros de configuração em disco e detecta com base no numero de série da zona que ocorreu uma actualização. Neste caso o primário envia uma notificação aos servidores secundários. – Quando os servidores secundários determinam que houve uma actualização do primário através de uma verificação periódica do numero de série da zona. – A informação mantida nos servidores secundários é valida durante um período limitado de tempo, após o qual uma nova transferência de zona tem de ser obrigatoriamente efectuada. DNS • Quando um servidor que suporta recursão recebe um pedido de informação para uma zona sobre a qual não possui informação – É desencadeado um processo iterativo de tradução. • Cada servidor conhece os endereços IP de um ou vários servidores de DNS responsáveis pela root: – Informação sobre os root servers não muda frequentemente – Desta forma é possível obter informação sobre os endereços IP dos servidores responsáveis pelos domínios de topo. – Contactando o servidor de topo pode-se obter informação sobre os servidores responsáveis pelos domínios de segundo nível – O processo continua iterativamente até encontrar o servidor responsável pela zona que contém a informação que se pretende obter, que é então questionado directamente. • Para melhorar o desempenho do DNS cada servidor mantém uma cache com a informação que obteve durante o seu funcionamento. – Cada informação em cache possui um tempo de vida ao fim do qual expira Formato de Mensagem DNS Identificação (16) Flags (16) Número de questões (16) Número de RRs de resposta (16) Número de RRs autoritários (16) Número de RRs adicionais (16) Questões RRs com respostas (Número variável de RRs) RRs autoritários (Número variável) RRs com informação adicional (Número variável) O Campo Flags • O campo de flags divide-se em: QR (1) – – – – opcode (4) AA (1) TC (1) RD (1) RA (1) zero (3) rcode (4) QR: 0 a mensagem é uma questão, 1 a mensagem é uma resposta. AA: 1 o servidor que está a responder é autoritária para a zona. TC: 1 mensagem truncada a 512 bytes (só usado com UDP). RD: 1 quando usado numa query indica que se pretende que o servidor use recursividade para responder à query. 0 numa query indica que se o servidor não for autoritário para a zona deve apenas retornar uma lista de servidores que o sejam. • Um servidor root nunca aceita queries recursivas • Cada vez mais servidores também possuem esta politica. • Devem ser os servidores locais a efectuar a recursividade – RA: É usado nas respostas para indicar que o servidor suporta recursividade. – RCODE: 0 OK, 3 erro. O Campo Questões • O campo de questões divide-se em: Nome a traduzir Tipo de questão (16) Classe da questão ( 1 = IP) (16) – Nome a traduzir: sequência de etiquetas que são precedidas por um byte com o numero de caracteres de cada etiqueta e terminando com um byte com valor zero. ns.dns.pt. 2 n s 3 d n s 2 p t – Tipo de questão: o tipo de questão indica o tipo informação (RR) que se pretende obter: Nome A NS CNAME PTR HINFO MX AXFR ANY Valor 1 2 5 12 13 15 252 255 Descrição da informação a obter Endereço IP Name server responsável por um domínio Nome canónico, um nome virtual que aponta para o nome real Nome a partir de endereço (Pointer) Informação sobre o host, duas strings com CPU e sist. operativo Nome e prioridade do servidor de email para um host / domínio Pedido de transferência de zona Obtenção de todos os registos 0 Formato das respostas DNS Nome do domínio Tipo de RR (16) Classe (16) Tempo de vida (32) Tamanho dos dados (16) Dados – Nome do domínio: nome ao qual os dados (RR) corresponde. – Tipo: especifica um dos tipos de RR tal como nas questões. – Tempo de vida: número de segundos que um cliente DNS pode manter esta informação em cache (2 dias é um valor usual). – Tamanho dos dados: Número de bytes do campo de dados. – Dados: resposta depende do tipo de RR. Para um endereço IP são quatro bytes. Para nomes é usado o formato mencionado anteriormente. Exemplo com um Cliente • Pretende-se fazer ssh para uma maquina usando o seu nome: – É usada a função gethostbyname para obter o endereço IP do sistema. – O cliente de DNS determina o endereço IP do servidor de DNS a usar com base em informação de configuração existente em armazenamento local. • Podem existir vários servidores configurados para redundância. – Envia uma query para o servidor de DNS usando UDP. – A query usa: • • • • O bit RD a 1 (deseja-se recursividade) O bit QR a 0 (é uma questão) Classe 1 (questão sobre IP) Tipo 1 (pretende-se obter um RR do tipo A endereço IP) – O servidor verifica se possui informação sobre a zona correspondente ao nome que se pretende traduzir: • • • • Pode existir em cache ou numa zona localmente suportada Caso afirmativo responde imediatamente ao cliente usando UDP. Se for primário para a zona a resposta terá o bit de autoritário a 1. Caso contrario contactará outros servidores para obter a informação. Mapeamento Reverso • É possível obter o nome correspondente a um endereço IP através da função gethostbyaddr() • Para este efeito existe o domínio in-addr.arpa. • As varias “classes” de endereços IP atribuídas podem ser registadas como sub-domínios debaixo deste domínio. • Para efectuar o mapeamento inverso da rede 193.139.77.0 / 24 é necessária a delegação do domínio 77.139.193.in-addr.arpa a um servidor de DNS. • O servidor deve usar registos PTR para efectuar o mapeamento entre os endereços IP e o nome correspondente. • O mapeamento reverso é frequentemente usado pelos servidores (por ex. o SSH) para verificar que os clientes têm origem em domínios de confiança • Um cliente que não tenha um mapeamento reverso é frequentemente considerado suspeito Exemplo com um Servidor • Um servidor de DNS local recebe uma questão: – pedido com recursividade – obtenção de um endereço IP referente a uma zona que não é local(www.cern.ch). • Resolução: – O servidor local usa a sua lista de root name servers para seleccionar um servidor que será interrogado para determinar os endereços IP dos servidores de DNS responsáveis por “ch”. – O servidor root responde com registos autoritários para os nomes dos servidores de DNS de “ch” e informação adicional com os endereços IP destes servidores. – O servidor local questiona um dos servidores de DNS de “ch” para obter os endereços IP dos servidores responsáveis pelo domínio “cern.ch”. – O servidor “ch” responde com registos autoritários para os nomes dos servidores de DNS de “cern.ch” e informação adicional com os seus endereços IP. – Finalmente um servidor de DNS de “cern.ch” é interrogado para obter o endereço IP de “www.cern.ch”. – O servidor de “cern.ch” responde com o endereço IP ou com a indicação de que o RR não existe. DNS • Em sistemas “*NIX” a configuração do cliente de DNS é efectuada no ficheiro /etc/resolv.conf search lip.pt nameserver 10.226.1.1 nameserver 10.226.1.2 • Atenção alguns utilitários de configuração podem reescrever o /etc/resolv.conf • Em RH se o NetworkManager estiver activo a configuração do DNS poderá ser reescrita • A configuração faz-se também através dos scripts /etc/sysconfig/network-scripts/ifcfg-ethX DOMAIN=lip.pt DNS1=10.226.1.1 DNS2=10.226.1.2 DNS • Em sistemas “*NIX” o ficheiro de configuração do servidor de DNS chama-se /etc/named.conf • Um servidor de DNS responde a queries na porta 53 • Um servidor de DNS efectua queries: – Inicialmente a porta 53 era usada – A partir de uma qualquer porta pré-definida pelo sysadm – Usando portas alocadas dinamicamente (mais difícil de passar nas firewalls) acl ns { 192.178.4.3; }; acl my-net { 192.137.86.0/24; }; options { directory “/etc/namedb”; query-source address * port 5678; recursion yes; allow-transfer { ns; my-net; }; allow-recursion { my-net; }; }; zone “.” { type hint; file “named.root”; }; zone “blabla.net” { type master; file “master/blabla.net”; }; zone “86.137.192.in-addr.arpa” { type master; file “master/192.137.86”; }; ; ; Ficheiro de configuração para a zona blabla.net ; $TTL 86400 @ IN SOA 2010030901 28800 7200 604800 86400 ) dns1.blabla.net. sysadm.blabla.net. ( ; Serial number yymmddss, xx zone change ; Refresh 4 hours ; Retry 2 hours ; Expire 7 days ; minimum time-to-live 1 day IN IN NS NS dns1.blabla.net. dns2.blabla.net. IN IN MX MX 10 20 frog frog dns1.frog dns2.frog IN IN IN IN NS NS A A dns1.frog.blabla.net. dns2.frog.blabla.net. 192.178.231.2 192.178.234.7 alfa beta delta mail1 mail2 dns1 dns2 IN IN IN IN IN IN IN A A A A CNAME A A 192.137.86.56 192.137.86.92 193.116.2.82 192.137.86.12 alfa.blabla.net. 192.137.86.14 123.81.11.5 mail1.blabla.net. mail2.blabla.net. ; ; Ficheiro de configuração para a zona 86.137.192.in-addr.arpa ; $TTL 86400 @ IN SOA 2010030901 28800 7200 604800 86400 ) dns1.blabla.net. sysadm.blabla.net. ( ; Serial number yymmddss, xx zone change ; Refresh 4 hours ; Retry 2 hours ; Expire 7 days ; minimum time-to-live 1 day IN IN NS NS dns1.blabla.net. dns2.blabla.net. 12 14 IN IN PTR PTR mail1.blabla.net. dns1.blabla.net. 56 92 IN IN PTR PTR alfa.blabla.net. beta.blabla.net. UDP e TCP • O DNS suporta UDP e TCP: – Ambos os protocolos usam o mesmo numero de porta (53). • Por norma é usado UDP: – Quando uma resposta é recebida com o bit TC a 1 indicando que a mensagem foi truncada a 512 bytes, então o TCP é usado para efectuar a transferência. • As transferências de zona entre servidores primários e secundários são sempre efectuadas usando TCP: – Para garantir maior fiabilidade. – Por existir probabilidade elevada da transferência precisar mais de 512 bytes. Exemplos • Traduzir via DNS o nome de um host $ host lnlip01.lip.pt lnlip01.lip.pt has address 10.1.1.101 $ host www.cern.ch www.cern.ch is an alias for webr4.cern.ch. webr4.cern.ch has address 137.138.137.177 • Traduzir via DNS o endereço de um host $ host 10.1.1.101 101.1.1.10.in-addr.arpa domain name pointer lnlip01.lip.pt. $ host 137.138.137.177 177.137.138.137.in-addr.arpa domain name pointer webr4.cern.ch. Exemplos • Obter via DNS o nome dos servidores de mail para um domínio: $ host -t MX cern.ch cern.ch mail is handled by 10 cernmxgwlb.cern.ch. $ host -t MX fct.mctes.pt fct.mctes.pt mail is handled by 5 anubis.fct.mctes.pt. $ host -t MX lip.pt lip.pt mail is handled by 10 smtp.lip.pt. • Obter os servidores de DNS para um domínio: $ host -t NS lip.pt lip.pt name server ns02.lip.pt. lip.pt name server ns01.lip.pt. Exemplos $ host –vT www.cern.ch Trying "www.cern.ch" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5145 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 6 ;; QUESTION SECTION: ;www.cern.ch. IN A ;; ANSWER SECTION: www.cern.ch. 9235 IN webr4.cern.ch. 9235 IN ;; AUTHORITY SECTION: cern.ch. 555 IN cern.ch. 555 IN cern.ch. 555 IN NS NS NS CNAME webr4.cern.ch. A 137.138.137.177 scsnms.switch.ch. ext-dns-1.cern.ch. ext-dns-2.cern.ch. ;; ADDITIONAL SECTION: scsnms.switch.ch. 53873 IN A 130.59.1.30 scsnms.switch.ch. 53873 IN A 130.59.10.30 scsnms.switch.ch. 53873 IN AAAA 2001:620::1 ext-dns-1.cern.ch. 3146 IN A 192.65.187.5 ext-dns-2.cern.ch. 10101 IN A 192.91.245.85 ext-dns-2.cern.ch. 10101 IN AAAA 2001:1458:e008:1::2 Received 261 bytes from 10.226.1.1#53 in 0 ms Exemplos $ dig +trace +tcp www.lip.pt ; <<>> DiG 9.2.4 <<>> +trace +tcp www.lip.pt ;; global options: printcmd . 234746 IN NS C.ROOT-SERVERS.NET. . 234746 IN NS D.ROOT-SERVERS.NET. . 234746 IN NS E.ROOT-SERVERS.NET. . 234746 IN NS F.ROOT-SERVERS.NET. . 234746 IN NS G.ROOT-SERVERS.NET. . 234746 IN NS H.ROOT-SERVERS.NET. . 234746 IN NS I.ROOT-SERVERS.NET. . 234746 IN NS J.ROOT-SERVERS.NET. . 234746 IN NS K.ROOT-SERVERS.NET. . 234746 IN NS L.ROOT-SERVERS.NET. . 234746 IN NS M.ROOT-SERVERS.NET. . 234746 IN NS A.ROOT-SERVERS.NET. . 234746 IN NS B.ROOT-SERVERS.NET. ;; Received 508 bytes from 10.226.1.1#53(10.226.1.1) in 1 ms pt. 172800 IN NS NS.DNS.BR. pt. 172800 IN NS NS.DNS.pt. pt. 172800 IN NS AUTH200.NS.UU.NET. pt. 172800 IN NS NS2.NIC.FR. pt. 172800 IN NS NS-EXT.ISC.ORG. pt. 172800 IN NS AUTH210.NS.UU.NET. pt. 172800 IN NS NS2.DNS.pt. ;; Received 363 bytes from 192.33.4.12#53(C.ROOTSERVERS.NET) in 24 ms lip.pt. 28800 IN NS ns02.fccn.pt. lip.pt. 28800 IN NS lnnet02.lip.pt. lip.pt. 28800 IN NS afnet01.lip.pt. ;; Received 215 bytes from 200.160.0.5#53(NS.DNS.BR) in 235 ms www.lip.pt. 86400 IN CNAME lnnet08.lip.pt. lnnet08.lip.pt. 86400 IN A 193.136.91.234 lip.pt. 86400 IN NS afnet01.lip.pt. lip.pt. 86400 IN NS ns02.fccn.pt. lip.pt. 86400 IN NS lnnet02.lip.pt. ;; Received 210 bytes from 193.136.2.228#53(ns02.fccn.pt) in 5 ms