Udem SRV 2 DNS

Título do Curso:
A d m i n i s t ra ç ã o d e S e r v i d o r e s
e Ser viços de Rede
Conteúdo do curso
ADMINISTRAÇÃO DE SERVIDORES E SERVIÇOS DE REDE
• Tópico 1: Introdução aos Serviços de Rede.

• Tópico 2: DNS.
• Tópico 3: Servidor WEB.
• Tópico 4: Correio Eletrônico (SMTP, POP3 e IMAP).
• Tópico 5: DHCP.
• Tópico 6: FTP.
• Tópico 7: Proxy, Firewall e Novas soluções (UTM e NGFW).
Administração de Servidores e Serviços de Rede 2

Proposta Pedagógica
ADMINISTRAÇÃO DE SERVIDORES E SERVIÇOS DE REDE
Propósito do curso Papel do aluno

• Descrever os conceitos e detalhes do • Além de assistir as aulas, recomenda-se
funcionamento de cada protocolo. realizar os exercícios disponibilizados,
• Ao compreender os conceitos o aluno estará em ambientes simulados (VM).
apto a implementar em qualquer plataforma,
bem como resolver problemas complexos.
• Apenas a prática possibilita a consolidação
do conhecimento.
• Demonstrar a implementação dos • “O conhecimento não é "dado" ou
protocolos em servidores Windows e Linux. transferido de uma pessoa para outra e sim
• As principais configurações serão exibidas, construído por cada um de nós, ou seja, não
incluindo o diagnóstico e resolução de dependemos de ninguém, apenas da nossa
problemas. própria dedicação.” (Autor desconhecido)

Tópico 2
DNS (Domain Name System)
DNS
Por que e para que utilizar nomes?
• Com o crescimento da internet, memorizar

endereços IP seria inviável. 192.0.2.17
192.0.2.237 192.0.2.143
• Para tornar a usabilidade das redes IP algo mais

“amigável”, foi definido o uso de nomes (hostname). 192.0.2.197
• Exemplo: 107.154.172.49 = www.dgpti.com.br

• Logo: ping www.dgpti.com.br = ping 107.154.172.49

História e evolução do
processo de resolução de nomes
• O propósito inicial da utilização de nomes foi suportar o envio de e-mails entre os
membros da ARPANET. Neste período, cada entidade deveria publicar um arquivo
(hosts.txt) contendo a listagem dos seus hosts e endereços IP.
• Em 1973, houve um consenso de que centralizar a gestão minimizaria erros e

facilitaria a expansão em larga escala (vide RFC 606, RFC 608, RFC 623).
• Antes do surgimento do DNS (vide RFC 625 publicada em Mar/1974), a resolução de

nomes era feita através de um único arquivo (hosts.txt), atualizado semanalmente e
publicado no Instituto de pesquisa de Stanford (NIC – Network Information Center).

• Consequentemente, a medida que a ARPANET (e o número de hosts inseridos no
arquivo) foi crescendo, houve um aumento de latência (pois a consulta era linear) e
dificuldades na consistência do ambiente (não realização de downloads nas demais
localidades).
• Motivações (justificativas) para evolução na resolução de nomes:

• Sistema de nomes hierarquicamente distribuído, possibilitando escalabilidade, administração
descentralizada e confiabilidade (disponibilidade).
• Maior viabilidade de uso para os usuários (utilizar nomes ao invés de IP).
• Ex.: http://www.google.com ao invés de http://172.217.9.228
• Volume de tráfego ao possuir um único local para resolução de nomes (RFC 625).

• O DNS foi inventado pelo Paul Mockapetris (fundador da Nominum), no Instituto de
Ciências da Informação (USA – Califórnia), em 1983.
• Originalmente documentado nas RFC 882 e 883 (Nov/1983), porém, posteriormente revisadas
nas RFC 1034 e 1035 (Nov/1987).
• Listagem das RFC relacionadas ao DNS: https://www.isc.org/community/rfcs/dns/
• Inclusive, temos atualmente a RFC 7686 (Oct/2015), referente aos domínios “.onion” de “uso
especial” (Jacob Appelbaum – Tor Project, Inc).
• Como qualquer serviço de rede, o DNS possui CLIENTE e SERVIDOR.
• Atualmente, o processo de resolução de nomes (na maior parte dos sistemas) é

realizada na sequência a seguir:
• Arquivo “hosts” (presente no computador cliente);
• Cliente DNS (realizando a consulta no servidor DNS – Configurações de Rede);
• NetBIOS (by Microsoft).
Arquivo hosts
• Conforme citado anteriormente, antes do surgimento do DNS, a resolução de
nomes era possível através do arquivo texto HOSTS:
• Atualmente temos o arquivo HOSTS em sistemas GNU/Linux: /etc/hosts
Fonte: Elaborado pelo autor

Arquivo hosts
• Continuação...:
• ... bem como no Windows: C:\Windows\System32\drivers\etc\hosts

Tipos de consulta DNS?
• Basicamente, um cliente DNS pode realizar dois tipos de consulta:
• Consulta/Pesquisa direta: Perguntar o endereço IP de um determinado Hostname.
• Ex.:
• Consulta/Pesquisa reversa: Perguntar o Hostname de um determinado endereço IP.

• Ex.:

Configuração básica do
Cliente DNS – Windows

Configuração básica do
Cliente DNS – Linux

Configuração básica do Cliente DNS
• Por que 2 ou mais servidores DNS?
• Redundância?
• Desempenho?
• Balanceamento de carga?
• É apenas a ordem de pesquisa!!
• O cliente realiza a consulta no servidor

DNS primário, porém, se não houver
resposta, o cliente realiza novamente a
consulta enviando a solicitação para o
secundário.

Resolução de nomes e o Cache DNS
• Ao obter a resposta da consulta DNS, o cliente armazena os dados desta resposta
por um período de tempo (Cache DNS).
• Este período de tempo (TTL - Time to Live) é definido pelo administrador do servidor
que possui a resposta (do IP ou hostname) solicitado pelo cliente.
• Portanto, durante este período, o cliente não precisa consultar o servidor

novamente para acessar o mesmo endereço.

Resolução de nomes e o Cache DNS
• Qual(is) servidor(es) DNS está(ão) configurado(s) no cliente?
• ipconfig /all
• Visualizando o Cache DNS:

• ipconfig /displaydns
• Limpando o Cache DNS:

• ipconfig /flushdns

Como testar uma resolução
DNS de um Hostname ou Domínio
• Através do próprio comando PING:
• Ex.: ping www.google.com
• Observe que antes da resposta do comando “PING”, a resolução de nomes é realizada.

Como testar uma resolução
DNS de um Hostname ou Domínio
• Através do comando NSLOOKUP:
• Ex.: nslookup www.google.com

Diferença entre HOSTNAME e
DOMÍNIO
• Hostname = nome de um computador (ou dispositivo) em uma rede que pode
pertencer a um domínio ou não.
• Domínio = nome único utilizado para identificar um “grupo” de computadores na

internet ou na rede interna (intranet), feito por dois ou mais “nomes” separados por
ponto ( . ).
• Ex.1: “google.com”;
• Ex.2: “google.com.br”;
• Ex.3: “pbh.gov.br”;
• Ex.4: “contoso.local”;

Sufixo DNS e FQDN
• Na figura abaixo, podemos visualizar dois domínios.
• Cada domínio possui HOSTNAMES específicos, que podem ser distintos ou não.
• Ex.: “a.ninja.local”;
• Ex.: “a.peba.int”;
• Temos o mesmo HOSTNAME (a), porém, o FQDN não é o mesmo.

Sufixo DNS e FQDN
• Dentro de cada domínio, os hosts podem se comunicar de duas formas:
• Digitando o FQDN (Fully Qualified Domain Name) do Host.
• OBS.: FQDN = Hostname + Sufixo DNS do domínio.
• Ex.: Para o host B se comunicar com o host A:
• ping a.ninja.local
• Utilizando o “Sufixo DNS” para resolver nomes “não qualificados” (não FQDN).
• Ex.: Ao adicionar o sufixo DNS do seu domínio nas configurações da placa de rede (Ex.: ninja.local),
para o host B se comunicar com o host A, basta digitar:
• ping a

Configurando o Sufixo DNS
Cliente Microsoft

Configurando o Sufixo DNS
Cliente Linux
• Basta adicionar no arquivo /etc/resolv.conf o nome do domínio:
• Ex.: search nome.do.dominio

Comando NSLOOKUP – (Cliente DNS)
• Permite realizar a consulta em qualquer servidor DNS;
• Disponível no Windows e na maioria das distribuições GNU/Linux. Sintaxe:
• nslookup host_desejado (consulta nos Servidores DNS configurados no cliente);
• Ex.: nslookup www.google.com

• nslookup host_desejado servidor_dns (consulta no servidor DNS especificado);
• Ex.: nslookup www.google.com 8.8.8.8

Tipos de resposta DNS
• A resposta pode ser “AUTHORITATIVE” ou “NON-AUTHORITATIVE”, ou seja, o
servidor que respondeu a consulta DNS possui autoridade para responder por
aquele domínio, ou não.
• Como assim?
• Simples, se a resposta for “AUTHORITATIVE” o servidor que respondeu é o responsável por aquele
domínio (responsável por publicar o arquivo de zona);
• Se a resposta for “NON-AUTHORITATIVE” o servidor que respondeu teve que recorrer a outros
servidores DNS para obter a resposta (ou seja, não publica o arquivo de zona do domínio solicitado
pelo cliente DNS).

Tipos de resposta DNS
• Resposta “AUTHORITATIVE”:
• Resposta “NON-AUTHORITATIVE”:

Comando NSLOOKUP
Opções de sintaxe
• Através do cliente DNS, pode-se realizar consultas para diversos tipos de registro:
• Consulta direta (para identificar o IP de determinado Hostname):
• nslookup www.domain.com
• Consulta reversa (para identificar o Hostname de determinado IP):

• nslookup x.x.x.x
• Identificar os servidores DNS de um domínio (que publicam o “zone file”):

• nslookup –type=ns dominio.desejado
• Identificar os servidores de E-mail de um domínio (MX - Mail eXchange):

• nslookup –type=mx dominio.desejado
• Identificar as configurações do registro SOA de um domínio (SOA – Start of Authority):

• nslookup –type=soa domínio.desejado
Comando NSLOOKUP
Opções de sintaxe
• Analisando uma consulta do tipo SOA (Start of Authority)

Comando NSLOOKUP
Opções de sintaxe
• Analisando uma consulta do tipo NS (Name Servers):

Comando NSLOOKUP
Opções de sintaxe
• Analisando uma consulta do tipo MX (Mail eXchange):

Analisando a troca de pacotes
de uma consulta
• Teste de resolução de nomes com o “NSLOOKUP”:
• Observe que a zona reversa não está configurada no servidor DNS (192.168.1.52):
• Tráfego capturado pelo WireShark:
31
Conceitos sobre o
Serviço DNS e
Servidores DNS
Tó p i c o 2 : D N S
32
Servidores DNS
• O serviço DNS utiliza a porta 53 UDP para resolução de nomes;
• Cada domínio deve publicar os RR (REGISTRO DE RECURSO) no arquivo de zona

(zone file) de seu respectivo domínio, no Servidor DNS.
• É possível ter um servidor primário e diversos servidores secundários, com o

arquivo de zona sendo replicado entre eles.
• Zona primária (DNS Master): publica as atualizações para os secundários.
• Zona secundária (DNS Slave): possui uma cópia do arquivo de zona (read only).
• A existência de servidores secundários aumenta a disponibilidade do ambiente.

Servidores DNS
Replicação do arquivo de zona
• O serviço DNS utiliza a porta 53 TCP para
replicação (transferência) do arquivo de
zona.
• A transferência do arquivo de zona apenas

será realizada caso o servidor DNS Master
tenha uma versão mais atual do arquivo de
zona (valor do Serial no registro SOA).
• A transferência do arquivo pode ser integral

(AXFR), ou apenas incremental (IXFR). Fonte da Imagem: http://technet.microsoft.com/pt-br/library/dd197495%28WS.10%29.aspx

Servidores DNS
Replicação do arquivo de zona
• Para possibilitar a replicação do arquivo de zona, deve-se:
• Configurar no servidor primário (DNS Master), a transferência de zona.
• Pode-se restringir por razões de segurança a transferência do arquivo de zona para apenas os endereços
IP dos servidores secundários.
• Configurar no servidor secundário (DNS Slave), qual o nome do domínio e o IP do Servidor

Master, além de defini-lo como servidor secundário.
• Após realizar estas configurações, o arquivo será transferido sempre que o número
da versão do arquivo de zona for incrementado (parâmetro Serial no registro SOA).

Registros de Recurso no DNS
• Existem diversos tipos de registro de recurso, dentre os principais, temos:
• SOA (Start of Authority):
• É sempre o primeiro registro em um arquivo de zona;
• Contém informações sobre o domínio, como o servidor primário, “versão” do arquivo de zona e
intervalos de tempo que afetam a renovação ou expiração do arquivo de zona, bem como o cache
DNS (do lado do cliente).
• NS (Name Server):
• Registro que define quais os servidores DNS possuem autoridade para responder requisições do
respectivo domínio.
• Ao definir um registro NS, devemos especificar o FQDN do Servidor DNS.
• Ex.: @ IN NS hostname.dominio.com.br.
• MX (Mail eXchange):
• Define o(s) servidor(es) de e-mail do domínio e a prioridade (útil caso tenha 2 ou mais servidores).
• Ex.: @ IN MX 10 mail.empresa.com.
• A (Host):
• Registro do tipo A é utilizado para mapear nomes (hostnames) a endereços IP do domínio referente
ao arquivo de zona.
• Ex.: www IN A 200.0.0.1
• Caso o registro acima esteja no arquivo de zona do domínio “empresa.com”, significa que o host
“www.empresa.com” possui o IP 200.0.0.1.
• CNAME (Alias – Canonical Name):

• Registros do tipo CNAME são “aliases” (apelidos) de outro hostname do mesmo ou de outro domínio.
• Ex.: ftp IN CNAME www.empresa.com.
• Os Hosts FTP e o WWW são o mesmo computador (mesmo IP).

• PTR (Pointer – Reverso):
• Registros PTR são utilizados apenas na zona reversa e possuem a função inversa do registro do tipo A
(ou seja, indicam o Hostname de um determinado IP).
• Ex.: 10 IN PTR smtp.empresa.com.
• O host com IP final 10 (Ex.: 200.0.0.10), aponta para o hostname “smtp.empresa.com”.
• OBS.: O nome da zona reversa deve “representar” a sua respectiva faixa de IP (Ex.: 0.0.200.in-addr.arpa),
porém, “invertido”.
• Temos outros tipos de Registro de Recurso, como os registros TXT, SRV, AAAA,
porém, serão demonstrados durante os vídeos de implementação.

Infraestrutura
Hierárquica do DNS
39
Root Servers
• Quando um cliente solicita uma resolução de nome de um domínio diferente do
publicado pelo servidor DNS consultado, a solicitação é encaminhada aos “ROOT
SERVERS” (Servidores raiz de DNS).
• Como o DNS é constituído de uma estrutura hierárquica e descentralizada, os

ROOT-SERVERS possuem o endereço de todos os “Domínios de Alto Nível” (TLD –
Top Level Domains), informando ao cliente DNS o caminho para prosseguir com a
resolução de nome.
• Os endereços dos ROOT-SERVERS já vem configurados nos Servidores.
• A raiz é representada pelo caractere “ponto” ( . ).

Root Servers
• Estrutura hierárquica do DNS.
Fonte: http://wiki.sj.ifsc.edu.br/wiki/index.php/GER-2010-1
Como funciona a consulta DNS?
• Como o DNS consiste em

uma estrutura hierárquica e
descentralizada, temos um
longo caminho ao solicitar
uma resolução DNS.

Perspectivas de uma Consulta
DNS: Iterativa e Recursiva
Quando um cliente realiza uma consulta, ela pode
ser analisada em duas perspectivas…
Iterativa Recursiva
• O cliente DNS processa toda a requisição • O cliente DNS encaminha o pedido para
DNS. outro servidor DNS que sempre
• Buscando do nível mais alto da hierarquia fornecerá a resposta.
(ROOT-SERVERS), posteriormente • Neste caso, o servidor consultado se
consultando ao TLD correspondente até encarrega de realizar a consulta em outros
obter a resposta de um servidor com servidores DNS (ROOT-SERVERS, TLD, etc...)
autoridade para responder a consulta DNS. para entregar a resposta ao cliente.

Domínios, subdomínios e
arquivos de zona
• Ao registrar um domínio DNS é possível criar subdomínios, incrementando o
“espaço de nomes DNS” (sufixo DNS).
• É possível gerenciar todo este “espaço de nomes DNS” com apenas um arquivo de
zona, ou possuir arquivos de zona distintos para gerenciar cada um destes
subdomínios.
• Na imagem ao lado, há uma
representação de arquivos de
zona distintos para cada sufixo
DNS (domínio e subdomínio).
Administração de Servidores e Serviços de Rede Fonte da imagem: Microsoft TechNet 44

Instalação e
Configuração do
Servidor DNS
45
Antes de Começar...
Vamos pensar um pouco!
• Antes de iniciar as configurações, vamos reforçar o conceito e definir as etapas
necessárias:
• Independente da plataforma, precisamos:

• Instalar o serviço/pacote;
• Linux  Bind 9 (em algumas distribuições terá o nome “named”);
• Windows  Microsoft DNS;
• Criar/Definir as zonas (domínios) que serão publicadas (como master e/ou slave);
• Linux  Arquivo “named.conf” ou “named.conf.local”;
• Windows  Clique com o botão direito... “New Zone”.. “next”, “next”, “Finish”.
• Criar os registros de recurso do domínio (SOA, NS, MX, A, etc...);
• Linux  Criar um arquivo de zona em “/var/named” ou “/var/cache/bind”; * = CentOS ou Red Hat
* = Debian e derivados
• Windows  Clique com o botão direito... “New Host A”, ou “New CNAME”...

BIND
Berkeley Internet Name Domain
• O BIND é um dos servidores DNS mais utilizados no mundo TCP/IP.
• Pacotes que compõe a solução BIND:

• Serviço de DNS;
• Biblioteca utilizada pelo serviço de DNS;
• Ferramentas de teste do servidor DNS (bind-utils);
• O BIND pode ser instalado no GNU/Linux de maneiras distintas de acordo com a

distribuição, porém, geralmente realizamos através de:
• Gerenciadores de Pacotes (APT, YUM, YAST, entre outros);
• Pacotes pré-compilados (“.DEB”, “.RPM”, ...)
• Compilando através do código fonte (arquivo .tar.gz).

Instalando o DNS no GNU/LINUX
• Assim como outros pacotes, podemos realizar a instalação através de gerenciadores
de pacotes, ou código-fonte.
• Código fonte disponível em: http://www.isc.org/;
• Instalando o DNS Server no DEBIAN:

• apt-get install bind9
• Instalando o DHCP Server no Red-Hat e derivados:

• yum install bind

Principais comandos de
administração do serviço
Debian Red Hat / Cent OS
• Iniciar o serviço: • Iniciar o serviço:
• systemctl start bind9 • systemctl start named
• Parar o serviço: • Parar o serviço:
• systemctl stop bind9 • systemctl stop named
• Reiniciar o serviço: • Reiniciar o serviço:
• systemctl restart bind9 • systemctl restart named
• Verificar o “status” do serviço: • Verificar o “status” do serviço:
• systemctl status bind9 • systemctl status named
• Atualizar as configurações: • Atualizar as configurações:
• systemctl reload bind9 • systemctl reload named
• Para habilitar a inicialização com o sistema: • Para habilitar a inicialização com o sistema:
• systemctl enable bind9 • systemctl enable named
• Para desabilitar a inicialização com o sistema: • Para desabilitar a inicialização com o sistema:
49
• systemctl disable bind9 • systemctl disable named
Arquivos de configuração e logs
Debian Red Hat / Cent OS
• Arquivo de configuração: • Arquivo de configuração:

• /etc/bind/named.conf • /etc/named.conf
• OBS.: Para adicionar zonas, arquivo
“named.conf.local”
• Arquivo de Log: • Arquivo de log:

• /var/log/syslog • /var/log/messages
• Diretório padrão dos “zone files”: • Diretório padrão dos “zone files”:
• /var/cache/bind/ • /var/named/
O arquivo “named.conf”
• O “named.conf” consiste em uma “coleção de declarações” no seguinte formato:
A listagem das declarações está disponível em:

http://www.zytrax.com/books/dns/ch7/statements.html
• Dentre os tipos de declaração, seguem os quatro principais:

• options  Define configurações globais do servidor DNS (porta, IPv6, “recursive”);
• acl  Define grupos de hosts que podem consultar no servidor DNS:
• Existem 4 “ACL’s” predefinidas (any, localhost, localnets, none).
• zone  Define as características de uma zona (domínio);
• Nome do domínio, “master” ou “slave”, permissões de replicação e atualização.
• include  Inclui o conteúdo de outros arquivos nas configurações do “named.conf”.
O arquivo “named.conf”
• Podemos definir no “/etc/named.conf”
ou “/etc/named.conf.*” :
• Diretório padrão dos arquivos de zona
“/var/named/” ou “/var/cache/bind”;
• Porta (UDP 53);
• Domínios que serão publicados;
• Observe a zona “.” (Root Servers);
• Observe o “Include” no arquivo que

contém as “zonas” padrão (RFC 1912);

Cenário de exemplo para implantação
• A topologia a seguir descreve um cenário de exemplo para os PRINTS de
configuração disponíveis nos próximos slides.
• Observe o IP e hostname de cada Servidor na figura:

BIND no DEBIAN
• named.conf.local: arquivo destinado para configurações dos domínios que serão
publicados por este servidor.
• Observe os domínios “exemplo.com.br” (zona direta) e a zona reversa para a rede
“192.168.0.0/24” que estão configurados:
• Zona Direta
“exemplo.com.br”;
• Zona Reversa
“192.168.0.0/24”
BIND no CentOS
• No CentOS, devemos modificar duas opções para possibilitar que outros
computadores realizem consultas DNS:
• listen-on port 53 { any; };
• allow-query { any; };
• Observe ao lado as zonas:

• “Root-Hint” (Root Servers), já existente
• Zona direta “exemplo.com.br”
• Zona Reversa “192.168.0.0/24”

BIND no DEBIAN ou CentOS
(Exemplo Servidor Slave)
• Após instalar o BIND no Servidor DNS secundário (SLAVE), utilizamos o mesmo
arquivo “named.conf.local” (DEBIAN) ou “named.conf” (CentOS), para adicionar
uma zona secundária (type SLAVE), conforme exemplo abaixo:
• Observe que no parâmetro “masters” devemos informar o IP do Servidor DNS Master.

• No servidor SLAVE, não precisamos criar os arquivos de zona.
• Para mais informações sobre cada uma das opções (declarações) utilizadas, acesse:
Administração de Servidores e Serviços de Rede http://www.zytrax.com/books/dns/ch7/statements.html 56
Configurando o arquivo de zona direta
• Exemplo de um arquivo de zona direta – Domínio “exemplo.com.br”:
• No DEBIAN os arquivos de zona devem ser criados em “/var/cache/bind/”;
• No CentOS os arquivos de zona devem ser criados em “/var/named/”;
57
Configurando o arquivo de zona reversa
• Exemplo de um arquivo de zona reversa – Para a rede “192.168.0.0/24”:
• No DEBIAN os arquivos de zona devem ser criados em “/var/cache/bind/”;
• No CentOS os arquivos de zona devem ser criados em “/var/named/”;
58
Realizando testes no serviço de DNS
• Podemos realizar testes através do comando NSLOOKUP para verificar se ambos os
servidores DNS respondem pelo nome de domínio:
• Observe que no final da linha de comando, podemos especificar o IP do Servidor DNS que desejamos realizar a
consulta, caso não tenha configurado o cliente “/etc/resolv.conf”.
59
Realizando testes no serviço de DNS
• Continuação... Podemos realizar testes através do comando NSLOOKUP:
• Pesquisa de um FQDN (resolução de um registro do tipo A – Zona Direta):
• Pesquisa de um IP (resolução de um registro do tipo PTR – Zona Reversa):
60
Instalando o Microsoft DNS
• Após esse overview, podemos instalar a “Função de DNS” no Server 2008.
• Através do “Server Manager”  “Add Roles”  “DNS Server”;
Fonte: Elaborado pelo autor 61

Instalando o Microsoft DNS
• Após a instalação, podemos acessar a console de administração do DNS através do
seguinte caminho:
• Menu Iniciar  Administrative Tools  DNS.
62
Bibliografia Básica
• COMER, Douglas E., Interligação de Redes com TCP/IP - Volume I - Princípios,
protocolos e arquitetura - Tradução da 6ª Edição. Rio de Janeiro: ELSEVIER, 2015.
• KUROSE, James F.; ROSS, Keith W., Redes de Computadores e a Internet: Uma
abordagem top-down. – 6. ed. São Paulo: Pearson Education – BR, 2013.
• TANENBAUM, Andrew S., Redes de Computadores. 5. ed. São Paulo: Pearson
Prentice Hall, 2011.

Referências
• RFC 1035 – DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION:
• https://tools.ietf.org/html/rfc1035
• RFC 1912 – Common DNS Operational and Configuration Errors:

• RFC 2142 - MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS
• RIPE – Recommendations for DNS SOA Values:

• https://www.ripe.net/publications/docs/ripe-203
64
Referências
• BIND Configuration Files (Documentation CentOS):
• http://www.centos.org/docs/2/rhl-rg-en-7.2/s1-bind-configuration.html
• BIND 9 – Debian Wiki:

• http://wiki.debian.org/Bind9
• BIND 9 – Manual Pages:

• http://www.bind9.net/manuals/
• Brief History of the Internet:

• https://www.internetsociety.org/internet/history-internet/brief-history-internet/
• Microsoft eLearning (Training 10221).
65
Vamos Praticar?
Obrigado!
Guilherme Rodrigues

Udem SRV 2 DNS

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Udem SRV 2 DNS

Enviado por

Direitos autorais:

Formatos disponíveis

Título do Curso:

• Tópico 1: Introdução aos Serviços de Rede.

Administração de Servidores e Serviços de Rede 2

Propósito do curso Papel do aluno

Administração de Servidores e Serviços de Rede 3

• Com o crescimento da internet, memorizar

• Para tornar a usabilidade das redes IP algo mais

• Exemplo: 107.154.172.49 = www.dgpti.com.br

Administração de Servidores e Serviços de Rede 5

• Em 1973, houve um consenso de que centralizar a gestão minimizaria erros e

• Antes do surgimento do DNS (vide RFC 625 publicada em Mar/1974), a resolução de

Administração de Servidores e Serviços de Rede 6

• Motivações (justificativas) para evolução na resolução de nomes:

Administração de Servidores e Serviços de Rede 7

• Atualmente, o processo de resolução de nomes (na maior parte dos sistemas) é

Fonte: Elaborado pelo autor

Administração de Servidores e Serviços de Rede 9

Fonte: Elaborado pelo autor

Administração de Servidores e Serviços de Rede 10

• Consulta/Pesquisa reversa: Perguntar o Hostname de um determinado endereço IP.

Administração de Servidores e Serviços de Rede 11

Administração de Servidores e Serviços de Rede 12

Administração de Servidores e Serviços de Rede 13

• É apenas a ordem de pesquisa!!

• O cliente realiza a consulta no servidor

Administração de Servidores e Serviços de Rede 14

• Portanto, durante este período, o cliente não precisa consultar o servidor

Administração de Servidores e Serviços de Rede 15

• Visualizando o Cache DNS:

• Limpando o Cache DNS:

Administração de Servidores e Serviços de Rede 16

Administração de Servidores e Serviços de Rede 17

Administração de Servidores e Serviços de Rede 18

• Domínio = nome único utilizado para identificar um “grupo” de computadores na

Administração de Servidores e Serviços de Rede 19

Administração de Servidores e Serviços de Rede 20

Administração de Servidores e Serviços de Rede 21

Administração de Servidores e Serviços de Rede 22

Fonte: Elaborado pelo autor

Administração de Servidores e Serviços de Rede 23

Fonte: Elaborado pelo autor

Administração de Servidores e Serviços de Rede 24

Administração de Servidores e Serviços de Rede 25

Fonte: Elaborado pelo autor

Fonte: Elaborado pelo autor

Administração de Servidores e Serviços de Rede 26

• Consulta reversa (para identificar o Hostname de determinado IP):

• Identificar os servidores DNS de um domínio (que publicam o “zone file”):

• Identificar os servidores de E-mail de um domínio (MX - Mail eXchange):

• Identificar as configurações do registro SOA de um domínio (SOA – Start of Authority):

Administração de Servidores e Serviços de Rede 28

Administração de Servidores e Serviços de Rede 29

Administração de Servidores e Serviços de Rede 30

• Tráfego capturado pelo WireShark:

• Cada domínio deve publicar os RR (REGISTRO DE RECURSO) no arquivo de zona

• É possível ter um servidor primário e diversos servidores secundários, com o

• A existência de servidores secundários aumenta a disponibilidade do ambiente.

• A transferência do arquivo de zona apenas

• A transferência do arquivo pode ser integral

Administração de Servidores e Serviços de Rede 34

• Configurar no servidor secundário (DNS Slave), qual o nome do domínio e o IP do Servidor

Administração de Servidores e Serviços de Rede 35

• CNAME (Alias – Canonical Name):