unesp UNIVERSIDADE ESTADUAL PAULISTA

(1)

unesp

UNIVERSIDADE ESTADUAL PAULISTA

T

ó

p

i

c

o

s

e

m

S

i

s

t

e

m

a

s

d

e

C

o

m

p

u

t

a

ç

ã

o

A

d

m

i

n

i

s

t

r

a

ç

ã

o

d

e

R

e

d

e

s

T

C

P

/

I

P

D

N

S

-

D

o

m

a

i

n

N

a

m

e

S

e

r

v

i

c

e

(

P

a

r

t

e

1

1 -

-

C

a

r

a

c

t

e

r

í

s

t

i

c

a

s

e

C

o

n

c

e

i

t

o

s

)

Prof. Dr. Adriano Mauro Cansian UNESP - IBILCE - São José do Rio Preto

(2)

Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 1 - 1

DNS - Domain Name Service

(Parte 1 - Características e Conceitos)

Prof. Dr. Adriano Mauro Cansian

adriano@ieee.org

UNESP - IBILCE - São José do Rio Preto

Orientação para estudo:

O tratamento utilizado nesta seção, conforme mencionado na nota de rodapé, é o mesmo do livro texto adotado neste curso (Craig Hunt - TCP/IP Network Administration). Este tratamento é excelente e suficiente para o administrador de redes e UNIX. Entretanto, por algumas vezes, este texto é pouco formal, ou seja, ignora alguns conceitos, considerando-se o ponto de vista acadêmico e mais aprimorado. Para alunos que desejam ir mais a fundo na questão, e aprimorar sua formação e seus conhecimentos em gerenciamento, recomendo uma leitura atenta do capítulo 14 (DNS: The Domain Name System) de TCP/IP Illustrated - Volume 1 - The Protocols, de Richard Stevens2 . Trata-se de um texto muito bom, de fácil compreensão e com excelentes ilustrações que auxiliam no entendimento.

1. Introdução: conceitos de Name Service 1.1. Nomes e Endereços

Toda interface de rede ligada a uma rede TCP/IP é identificada por um endereço IP formado por 32 bits.

Este endereço é representado na forma numérica como

Æ xxx . yyy . zzz . kkk

Entretanto, os projetistas consideraram que lembrar de endereços de um computador pelo número (ou seja, pelo seu endereço IP) era muito desconfortável e pouco prático.

Além disso, o endereço de um computador poderia ter de ser alterado, devido a, por exemplo, uma mudança de rede física ou de roteamento. Neste caso, todos os usuários daquele computador precisariam ser avisados de que o endereço foi mudado.

1

Créditos - este material foi produzido a partir do livro texto adotado no curso: Hunt, Craig - TCP/IP Network Administration - O’Reilly & Associates, Inc. - 1.a Edição - Capítulo 3, pag. 51 e Capítulo 8, pag 167.

2

(3)

Em virtude principalmente destes fatos, foi considerado que um nome poderia ser atribuído e associado a qualquer dispositivo que possua um endereço

IP.

A atribuição de nomes aos endereços se deve ao fato de que é muito mais

fácil uma pessoa se lembrar de nomes do que de números, além do fato do nome poder ser mantido numa eventual mudança de endereço IP.

Entretanto Æ O software de rede e a pilha TCP/IP trabalham apenas

com os endereços numéricos. Na maior parte dos casos, os nomes

e números podem ser usados indistintamente, mas os nomes são sempre lembrados com mais facilidade.

Por exemplo:

% ssh METAL.dcce.ibilce.unesp.br ou

% ssh 200.145.202.125

Æ conduzem ao mesmo computador.

Existe um processo de “conversão” Æ Quando se utilizam nomes é necessário que exista um serviço que efetue a conversão deste nome em um

número IP para que se estabeleça a conexão. Também chamado de processo

de TRADUÇÃO.

Tradução de Nome em Número

A tradução entre nomes e números passou por diversos estágios durante o desenvolvimento da Internet e das redes que a precederam.

Inicialmente existia uma tabela, chamada hosts.txt, mantida pelo DDN-NIC, e que era distribuída para todos os computadores da Internet Æ usada no /etc/hosts.txt (análoga à atual tabela /etc/hosts ou ao mapa NIS hosts.byname)

Com o crescimento da Internet este esquema se tornou inviável, exigindo a criação de um serviço mais eficiente para a resolução de nomes.

(4)

Name Service, conhecido simplesmente como DNS, que foi concebido por Paul

Mockapetris, em 1983.

Em 1994, 4 estudantes da Universidade de Berkeley - Douglas Terry, Mark Painter, David Riggle and Songnian Zhou — escreveram a primeira implementação do DNS para o UNIX, que era mantida por Ralph Campbell e denominada

Berkeley Internet Name Daemon.

Em 1985, Kevin Dunlap da DEC Digital Equipament Co. (comprada pela HP) significativamente re-escreveu a implementação do eo mudou seu nome para BIND - Berkeley

Internet Name Domain.

Mike Karels, Phil Almquist and Paul Vixie mantém o BIND desde então (www.ISOC.org).

O BIND foi portado para Windows NT em 1990.

As especificações do DNS encontram-se descritas na RFC-1034 e RFC-1035

O DNS Æ foi desenvolvido para oferecer uma alternativa à resolução de

nomes através do arquivo hosts.txt, e que pudesse garantir seu funcionamento eficiente mesmo em face do crescimento explosivo por que

vem passando a Internet, permitindo ao mesmo tempo que informações sobre computadores novos sejam rapidamente disseminadas conforme a necessidade.

O DNS resolve dois problemas com relação ao /etc/hosts:

• DNS é facilmente escalonável Æ a base é distribuída e não reside numa única tabela.

• DNS dissemina facilmente Æ isso garante que novas informações sobre novos hosts, sejam disseminados para o resto da rede. Além disso a informação só é disseminada para aqueles que precisam dela. Isso será discutido em seguida.

(5)

2. Como o DNS funciona

• Um cliente faz uma requisição a UM SERVIDOR DE DNS LOCAL, previamente configurado.

• Servidor de DNS local recebe um request de informações sobre um host para o qual ele (servidor) não possui informação.

• O servidor passa a requisição para um authoritative server Æ server

responsável por manter informação correta e atualizada sobre o domínio que está sendo consultado.

• Veremos como esta passagem é feira mais adiante.

• Quando o authoritative server responde Æ o server local armazena (faz um cache) a resposta para uso futuro.

• Na próxima vez que o server local receber um request sobre aquele domínio, ele responde por si próprio.

Cliente de DNS Servidor de DNS Request host.algum.lugar.br Autoritativo ? S N Servidor de DNS 1 2 2.1 2.2 3

Figura - Esquema básico de funcionamento de uma requisição de resolução de DNS

Atenção: O serviço de DNS é associado à porta 53 UDP, e é chamado de “domain”. Não

confundir com um antigo serviço de nomes associado à porta 42, chamado “nameservice”. Consulte /etc/services , e a documentação do seu sistema.

(6)

2.1. A hierarquia do domínio

• O DNS NÃO possui uma base de dados central com todos os IPs da Internet.

• Informação é distribuída ao longo de milhares de nameservers organizados numa hierarquia similar à estrutura de diretórios de um filesystem UNIX.

Figura 3 – Hierarquia de domínios comparada com um filesystem Unix

• O DNS tem um root domain (domínio raiz) no topo da hierarquia de domínio. Este

(7)

Figura – Hierarquia geral de domínios

root domain

top level domains

“.”

.br

.unesp.br

(8)

Diretamente sob o root domain Æ estão os top level domains = TLD

Existem dois tipos básicos de top level domains Æ geográfico e

organizacional.

Nomes de domínios genéricos de primeiro nível com códigos genéricos

(gTLD – Generic TLD)

Organizacional Æ .com .org .net .mil .edu .gov

Nomes de domínios de primeiro nível com códigos de países (ccTLD – Country Code TLD)

Geográfico Æ .br .jp .ar .uk .nz .au Geográfico-organizacional Æ .com.br .org.br .gov.br

Os root servers Æ somente possuem informações completas sobre os

domínios de top level (TLDs). São os root servers que

possuem os apontadores para os top level.

Nenhum servidor (nem mesmo os root servers) possui informações completas sobre todos os domínios, mas os root servers possuem ponteiros para os servers dos domínios de segundo nível.

Assim Æ ainda que os root servers não possuam a resposta para um request, eles sabem para quem perguntar.

(9)

Root servers – 18.08.2009

http://www.icann.org/maps/root-servers.htm

Root servers são operados por 13 organizações conhecidas

como "root server operators". Esta localização e seus respectivos endereços raramente são alterados. Ao total são 190 root servers, incluindo os espelhos.

Os nomes são formados da seguinte forma: “letter”.root-servers.net, onde “letter” é a letra do root nameserver, variando de A até M.

Relação dos endereços:

http://www.root-servers.org/

(10)

3. Governança de DNS

Os TLDs são delegados pelo ICANN aos “registry” ou “registrador”.

O que é a ICANN?

A ICANN - Internet Corporation for Assigned Names and Numbers (órgão mundial responsável por estabelecer regras do uso da Internet ) é uma entidade sem fins lucrativos e de âmbito internacional, responsável pela distribuição de números de “Protocolo de Internet” (IP), pela designação de identificações de protocolo, pelo controle do sistema de

nomes de domínios de primeiro nível com códigos genéricos (gTLD) e de países (ccTLD) e com funções de administração central da rede de

servidores.

Esses serviços eram originalmente prestados mediante contrato com o governo dos EUA, pela Internet Assigned Numbers Authority (IANA) e outras entidades. A ICANN hoje cumpre a função da IANA.

Qual é a função da ICANN?

A ICANN é responsável por coordenar o controle dos elementos técnicos do DNS que garantem a “resolução universal”, que ajuda os usuários da Internet a encontrar qualquer endereço válido. Isso é realizado através da supervisão da distribuição das identificações exclusivas usadas nas operações da Internet e a distribuição de nomes de domínio de primeiro nível (como .com, .info, etc.).

(11)

REGISTRY (registrador):

• É a entidade delegada pela ICANN para armazenar e administrar os registros de um determinado TLD.

• Ele mantém disponível em seus servidores, para acesso de todos os usuários da internet, as informações dos endereços IP dos nomes de domínio de segundo nível relativos ao TLD que administra.

• Um REGISTRY também é chamado de NIC - Network

Information Centre.

http://en.wikipedia.org/wiki/Network_Information_Cen tre

• Gerencia o registro de domínios de um TLD; • Controla as políticas de alocação de nomes; • Tecnicamente opera seu TLD;

• É diferente de um REGISTRAR

REGISTRAR (agente de registro)

• Registrar, ou agente de registro, é a entidade

credenciada por um registrador para proceder o

registro de nomes de domínio requerido por qualquer pessoa ou entidade.

• Brasil: 6 • EUA: 579 • Canada: 147

http://en.wikipedia.org/wiki/Domain_name_registrar ICANN-Accredited Registrars: http://www.icann.org/registrars/accredited-list.html

ICANN currently accredits domain-name registrars for the following Top Level Domains: * .aero (reserved for the global aviation community) sponsored by Societe

Internationale de Telecommunications Aeronautiques SC (SITA)

* .asia (reserved for the Pan-Asia and Asia Pacific region) sponsored by DotAsia Organisation

(12)

Fundació puntCat.

* .com operated by Verisign Global Registry Services

* .coop (reserved for cooperatives) sponsored by Dot Cooperation LLC * .info operated by Afilias Limited

* .jobs (reserved for the human resource management community) sponsored by EmployMedia LLC operated by Afilias Limited

* .mobi (reserved for consumers and providers of mobile products and services) sponsored by mTLD Top Level Domain Ltd.

* .museum (restricted to museums and related persons) sponsored by the Museum Domain Management Association (MuseDoma)

* .name (restricted to individuals) operated by Global Name Registry * .net operated by Verisign Global Registry Services

* .org operated by Public Interest Registry

* .pro (restricted to licensed professionals) operated by RegistryPro

* .travel (reserved for entities whose primary area of activity is in the travel industry) sponsored by Tralliance Corporation.

REGISTRO DE UM DOMÍNIO:

Consiste em ter um domínio nos sistemas de um Registry para que, quando o Registry for questionado sobre "- Qual o servbidor de DNS do domínio taldominio.com?" ele responda (por exemplo):

dns_server.taldominio.com.

Ter um domínio registrado significa "existir" na internet, ou seja, um Registry (e somente um Registry) é capaz de responder:

"sim, eu sei quem é o domínio taldominio.com, e o servidor DNS que contém informações detalhadas sobre esse domínio é o abc.com".

Exemplificando, a registro.br, que é o registry de domínios terminados em .br sabe que os servidores de DNS do domínio adr.pro.br são:

adr.pro.br nameserver = ns7.zoneedit.com. adr.pro.br nameserver = ns14.zoneedit.com.

Authoritative answers can be found from:

(13)

Registry no Brasil:

No Brasil o REGISTRO.BR é o REGISTRY do domínio .br3 . No Brasil, o REGISTRY também atua como REGISTRAR

O registro.br é coordenado pelo NIC.BR - Núcleo de Informação e Coordenação do Ponto br . - http://www.nic.br/

É uma entidade civil, sem fins lucrativos, que desde dezembro de 2005 implementa as decisões e projetos do Comitê Gestor da Internet no Brasil.

Dentre suas atribuições estão:

• o registro e manutenção dos nomes de domínios que usam o <.br>, e a distribuição de endereços IPs, através do Registro.br;

• o tratamento e resposta a incidentes de segurança em computadores envolvendo redes conectadas à Internet brasileira, através do CERT.br;

• a promoção da infra-estrutura para a interconexão direta entre as redes que compõem a Internet

Brasileira, através do PTT.br;

• divulgação de indicadores e estatísticas e informações estratégicas sobre o desenvolvimento da Internet

brasileira, através do CETIC.br;

• o suporte técnico e operacional ao LACNIC – Latin America and Caribeean Internet Address Registry -

3

(14)

Internet para a América Latina e Caribe.

O NIC.BR é definido pelo CGI.br – Comitê Gestor da Internet no Brasil

Entre as diversas atribuições do CGI.br destacam-se:

• a coordenação da atribuição de endereços internet (IPs) e do registro de nomes de domínios usando <.br>;

• o estabelecimento de diretrizes estratégicas

relacionadas ao uso e desenvolvimento da internet no Brasil;

• a coleta, organização e disseminação de informações sobre os serviços internet, incluindo indicadores e estatísticas.

(15)

4. Resolução de DNS

Por exemplo: O root server de .br nada sabe sobre o domínio unesp.br Æ mas sabe que deve perguntar, ou transferir, as requisições que recebe para o servidor de domínio de segundo nível, que cuida do domínio .unesp.br Æ o qual fica localizado em ns.unesp.br Em resumo Æ O servidor de “.br” conhece quem toma conta de “.unesp.br”

Como ocorre a resolução de nomes

(16)

5. Bind, resolver e named

Algumas definições:

• BIND (Berkeley Internet Name Domain)

No Unix Æ o serviço DNS é implementado através do software BIND. O BIND é um sistema cliente servidor.

O lado cliente do BIND Æ resolver

resolver Æ envia perguntas relativas a informações contidas no DNS a servidores de nomes (nameservers). O servidor DNS responde à estas perguntas.

O lado servidor do DNS Æ named. • Zonas

O termo “zona” (zone) refere-se a informações contidas em um

arquivo do banco de dados do DNS.

As configurações de zona estão associadas às definições do domínio. Alguns dos arquivos de configuração de nomes são chamados de

“arquivos de zona” (zone files).

• Domínio

Parte da hierarquia de domínios identificada por um nome de domínio. Os nomes de domínio são escritos a partir do nome mais específico (ou seja, o nome do host) até o menos específico (o top-level domain), com cada uma das partes do domínio separada por um ponto “ . ”

(17)

FQDN Æ Fully Qualified Domain Name

Começa com um nome de host específico, e termina com um

top-level domain

Por exemplo cindy.corp.berkeley.edu é o FQDN de uma estação

cindy dentro do sub-domínio corp, do domínio berkeley.edu .

Figura – Relação entre domínios, sub-domínios e zonas

_____________________________________________

(18)

5.1. Relação de nomes, domínios e números IP

Nó www.acme.org.br 152 . 192 . 16 . 15 Nó mail.corp.acme.org.br 152 . 192 . 17 . 10 "." .br .org .acme .corp mail Domínio

corp.acme.org.br Domínio acme.org.br

www . acme. org . br 152 . 192 . 16 . 15 mail . corp . acme . org . br

152 . 192 . 17 . 10

www !! Observe que os níveis

hierárquicos dos nomes de domínios NÃO têm relação com os octetos IP

(19)

6. Características do sistema

O software BIND pode ser configurado de diversas maneiras. As configurações mais comuns são apresentadas a seguir. É muito importante estar familiarizado com a nomenclatura e os termos utilizados.

• Servidores Primários (primary servers)

O servidor primário ou servidor MASTER Æ é a fonte oficial de todas as informações a respeito de um domínio específico. É o que (supostamente) mantém todas as informações atualizadas sobre o domínio.

Ele carrega as informações a respeito do domínio a partir de arquivos

locais (arquivos de zona e outros) mantidos pelo administrador do domínio.

O servidor primário é o servidor mestre (também conhecido como master) devido ao fato de que pode responder a qualquer pergunta sobre seu

domínio com total autoridade Æ por isso é chamado de authoritative server.

Importante Æ Deve existir um único servidor primário (master) para cada

(20)

• Servidores Secundários (slave servers)

Servidores secundários (ou escravos – “slave”) Æ são aqueles que transferem (copiam) um conjunto completo de informações a partir do servidor

primário. Servidores secundários não possuem arquivos de zona próprios.

Os arquivos descrevendo as zonas Æ são transferidos do servidor primário, e armazenados no servidor secundário como arquivos locais. Esta transferência chama-se zone transfer.

Os servidores secundários também são freqüentemente conhecidos como backup servers Æ pois mantém uma cópia backup dos arquivos do servidor primário.

O servidor secundário mantém uma cópia completa de todas as

informações a respeito do domínio, e responde a perguntas com autoridade. Consequentemente, um servidor secundário também é

considerado um servidor mestre.

Server secundário Æ deve responder sempre. É usado para manter o sistema de resolução de nomes de um domínio em funcionamento no caso de uma

falha ou sobrecarga do servidor primário.

Os RFCs recomendam que, para cada domínio, exista pelo menos um servidor secundário fora da rede física onde reside o servidor primário do domínio Æ por redundância, visando evitar a paralisação total de um domínio

inteiro, no caso de uma falha no segmento de rede onde reside o servidor primário.

(21)

Outros tipos de servidores menos utilizados: • Caching-only

Caching-only Æ são servidores que rodam o programa named, mas não são

fontes oficiais de informação a respeito de domínios.

Estes servidores obtém a resposta a todas as perguntas que lhe são direcionadas a partir de algum servidor remoto, primário ou secundário. • Client-only

Client only Æ são apenas clientes de DNS, e não mantém processos servidores. É o caso da maioria das máquinas de um domínio. Ou seja, a maioria das máquinas utiliza a resolução de nomes dos servidores. Obviamente, estas máquinas não rodam o bind (processo named).

_____________________________________________

(22)

Root servers são operados por 13 organizações conhecidas

como "root server operators". São elas

A VeriSign Global Registry Services Dulles VA

B Information Sciences Institute Marina Del Rey CA

C Cogent Communications Herndon VA; Los Angeles; New York City; Chicago D University of Maryland College Park MD E NASA Ames Research Center Mountain View CA F Internet Systems Consortium, Inc. 40 sites:

Ottawa; Palo Alto; San Jose CA; New York City; San Francisco; Madrid; Hong Kong; Los Angeles; Rome; Auckland; Sao Paulo; Beijing; Seoul; Moscow; Taipei; Dubai; Paris; Singapore; Brisbane; Toronto; Monterrey; Lisbon; Johannesburg; Tel Aviv; Jakarta; Munich; Osaka; Prague;

Amsterdam; Barcelona; Nairobi; Chennai; London; Santiago de Chile; Dhaka;Karachi;Torino;Chicago; Buenos Aires;Caracas;Oslo G U.S. DOD Network Information

Center

Columbus OH H U.S. Army Research Lab Aberdeen MD I Autonomica/NORDUnet 30 sites:

Stockholm; Helsinki; Milan; London; Geneva; Amsterdam; Oslo; Bangkok; Hong Kong; Brussels; Frankfurt;

Ankara; Bucharest; Chicago; Washington DC; Tokyo; Kuala Lumpur; Palo Alto; Jakarta;

Wellington; Johannesburg; Perth; San Francisco; New York; Singapore; Miami; Ashburn (US); Mumbai; Beijing; Manila J VeriSign Global Registry Services 30 sites:

Dulles (2 locations), Miami, Atlanta, Seattle, Chicago, New York, Los Angeles, Mountain View, San Francisco (US);

Amsterdam (NL); London (UK); Stockholm (SE); Tokyo (JP); Seoul (KR); Bejing (CN);

Singapore (SG); Dublin (IE); Kaunas (LT); Nairobi (KE); Montreal, Quebec (CA); Sydney (AU); Cairo (EG); Warsaw (PL);

(23)

Brasilia, Sao Paulo (BR); Sofia (BG); Prague (CZ); Johannesburg (ZA) K RIPE NCC London (UK); Amsterdam (NL);

Frankfurt (DE); Athens (GR); Doha (QA); Milan (IT); Reykjavik (IS); Helsinki (FI); Geneva (CH); Poznan (PL); Budapest (HU); Abu Dhabi (AE); Tokyo (JP); Brisbane (AU); Miami (US); Delhi (IN); Novosibirsk (RU) L ICANN Los Angeles

M WIDE Project Tokyo; Seoul (KR); Paris (FR); San Francisco, CA