Zone File Directives

RFC 1035 define uma série de diretrizes para uso em arquivos de zona. Estes são resumidos abaixo:
• $TTL - Obrigatório como primeira entrada em um arquivo de zona BIND 9. Define o TTL
padrão (ou a vida útil do cache) para qualquer Registro de Recursos que não contenha um.
• $ORIGIN - altera o 'nome da zona' que é adicionado a qualquer nome 'não qualificado'. O
ponto é opcional no final de um nome que aparece em uma diretiva ORIGIN.
• $INCLUDE - permite que o conteúdo de um arquivo seja inserido no arquivo de zona. O
ponto crítico a ser observado é que se um arquivo INCLUDE'd contiver uma declaração $
ORIGIN é o escopo (é válido) apenas para o arquivo INCLUDE'd, os valores originais de
ORIGIN e 'nome da zona' são restaurados após o arquivo INCLUDE'd foi totalmente
processado.
BIND adicionalmente fornece $GENERATE, uma diretiva não padrão para simplificar a
geração de delegações reversas em arquivos inaddr.arpa. Se você acha que deseja mudar o software
DNS, não use $ GENERATE.

Zones and Zone files

Uma zona é conveniente para a parte do nome do domínio para o qual estamos
configurando o servidor DNS, por exemplo, BIND e sempre é uma entidade pela qual somos
competentes.
Suponha que possamos ter um nome de domínio do example.com. Isso é composto por um
nome de domínio (exemplo) e um nome de gTLD (com). A zona neste caso é example.com. Se nós
possuímos um subdomínio que foi delegado a nós chamado us.example.com, então a zona é
us.example.com.
As zonas são descritas em arquivos de zona (às vezes chamados de arquivos mestre e
normalmente localizados em / var / named) que podem conter Directives usado pelo software DNS,
por exemplo, BIND e Resource Records que descrevem as características da zona e hosts e serviços
individuais dentro da zona. As diretrizes e os registros de recursos são um padrão definido pelo
RFC 1035, de modo que pode ser lido por qualquer software de servidor DNS auto-respeitado. A
única exceção a isso é o BIND-specific $GENERATE directive. Então, se você acha que vai mudar
os servidores DNS, não use $GENERATE.Example Zone File
example.com. IN SOA ns1.example.com. hostmaster.example.com.(
2003080800 ; se = serial number
3h ; ref = refresh
15m ; ret = update retry
3w ; ex = expiry
3h ; min = minimum
)
IN NS ns1.example.com.
IN NS ns2.example.com.
IN MX 10 mail.anotherdomain.com.
joe IN A 192.168.254.3
www IN CNAME joe
Resource Records
Os registros de recursos são definidos pelo RFC 1035 (e aumentados por outros). Os
registros de recursos descrevem as propriedades globais de uma zona e os hosts ou serviços que
fazem parte da zona. Os registros de recursos têm um formato binário, usado internamente pelo
software DNS e quando enviado através de uma rede, e. atualizações de zona e um formato de texto
que é usado em arquivos de zona.
Os registros de recursos incluem SOA Record, NS Records, A Records, CNAME Records, PTR
Records, MX Records.

Example of Resource Records in a Zone File

foo.com. IN SOA ns.joe.com. root.foo.com. (
2003080800 ; se = serial number
3h ; ref = refresh
15m ; ret = update retry
3w ; ex = expiry
3h ; min = minimum
)
IN NS ns1.foo.com.
IN MX 10 mail.anotherdomain.com.
joe IN A 192.168.254.3
www IN CNAME joe

Os registros de recursos DNS (RRs) descrevem as características de uma zona (ou

domínio) e têm um formato binário ou wire-format, que é usado em consultas e respostas, e um
formato de texto usado em arquivos de zona e que é descrito neste capítulo.

Zone file example

; zone file for example.com
$TTL 2d ; 172800 secs default TTL for zone
$ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2003080800 ; se = serial number
12h ; ref = refresh
15m ; ret = update retry
3w ; ex = expiry
3h ; min = minimum
)
IN NS ns1.example.com.
IN MX 10 mail.example.net.
joe IN A 192.168.254.3
www IN CNAME joe
O exemplo acima mostra um arquivo de zona muito simples, mas bastante normal. As
seguintes notas aplicam-se aos arquivos de zona:
Os arquivos de zona consistem em comentários, diretivas e registros de recursos
1. Os comentários começam com ';' (ponto e vírgula) e presume-se que continuem até o final
da linha. Os comentários podem ocupar uma linha inteira ou parte de uma linha como
mostrado no exemplo acima.
 2. As diretivas começam com '$' e são padronizadas - $ORIGIN e $INCLUDE (definido na
RFC 1035) e $TTL (definido na RFC 2308). BIND adicionalmente fornece o não padrão
$GENERATE diretiva.
3. Existem vários tipos de registro de recursos (RR) definidos no RFC 1035 e aumentados por
RFCs subseqüentes.
4. A diretiva $TTL deve estar presente e aparecer antes do primeiro RR (RFC 2308
implementado no BIND 9).
5. O primeiro registro de recursos deve ser o registro SOA (Start of Authority). O formato
genérico é descrito abaixo.

DNS Generic Record Format

Os registros de recursos têm duas representações. Um formato textual descrito neste
capítulo e um formato binário ou em wire-format.
O formato textual possui a seguinte forma genérica:
owner-name ttl class type type-specific-data

Onde:

O owner-name (ou rótulo) do nó no arquivo de zona ao qual essa gravação

pertence. Às vezes referido como o nome da mão esquerda para diferenciá-lo
de qualquer nome que possa aparecer nos dados específicos do tipo (como
para NS ou MX RR) que, às vezes, é surpreendentemente chamado o nome da
mão direita ou o alvo- nome. O campo owner-name também pode ter um dos
seguintes valores:
owner-name
@
; substitua pelo valor atual de $ORIGIN

; Espaço em branco ou tabulação (tab), fará com que o

; owner-name use o valor de $ORIGEM
; (ou o seu valor padrão)
Valor de 32 bits. o Time to Live em segundos (com intervalo é 1 a
ttl 2147483647) indica quanto tempo o RR pode ser armazenado em cache. O
valor zero indica que os dados não devem ser armazenados em cache.
Um valor de 16 bits que define a família de protocolos ou uma instância do
class protocolo. O valor normal é IN = protocolo da Internet (outros valores são HS
e CH, ambos os protocolos MIT históricos).
O tipo de registro de recursos que determina o(s) valor(es) do type-specific-
Type
data campo. Tipo toma um dos valores abaixo.
type-specific-data O conteúdo de dados de cada registro é definido pelo type e class valores.

O formato genérico binário ou wire-format é:

name ttl class type rdlen rdata

Field Name Meaning/Use
O nome retornado, ex. www ou ns1.example.net Se o nome estiver no mesmo
NAME domínio, normalmente, apenas a parte do host (rótulo) é retornada, caso não seja
retornado um FQDN.
TYPE O tipo RR, por exemplo, SOA ou AAAA
CLASS A classe RR, por exemplo, Internet, Caos etc.
TTL O TTL em segundos do RR, digamos, 2800
RLENGTH O comprimento dos dados específicos do RR em octetos, por exemplo, 27
Os dados específicos de RR (ver Formatos de RR binários abaixo) cujo comprimento
RDATA
é definido por RDLENGTH, por exemplo, 192.168.254.2

Resource Record (RR) Types

Esta é uma lista incompleta, mas consiste nos principais tipos de RR utilizados na zona do
mapa direto e reverso, juntamente com links para outros tipos de RR que são úteis, divertidos,
complexos ou que possuem nomes interessantes. Uma lista completa de tipos de registro de
recursos DNS (RR) pode ser obtida a partir de IANA DNS Parameters.

RR Value RFC Description

Registro de endereço IPv4. Um endereço IPv4 para um
A 1 RFC 1035
host.
IPv6 Address record. An IPv6 address for a host.
AAAA 28 RFC 3596 Current IETF recommendation for IPv6 forward-
mapped zones.
Obsoleto. AAAA é o registro de endereço IPv6
A6 38 RFC 6563
recomendado. Situação histórica.
Localização dos servidores AFS. Experimental -
AFSDB 18 RFC 1183
aplicativos especiais apenas.
Nome canônico. Um nome de alias para um host. Causa
CNAME 5 RFC 1035
o redirecionamento para um único RR no owner-name.
Redirecionamento no DNS. Como CNAME, mas afeta
DNAME 39 RFC 6672 todos os RR abaixo do espaço de endereço de owner-
name.
DNSKEY 48 RFC 4034 DNSSEC. Chave pública DNS RR.
DS 43 RFC 4034 DNSSEC. Delegado Signer RR.
Método de armazenamento de endereços EUI
(Extended Unique Identifier) de 48 bits no DNS. Os
endereços EUI-48 são usados por redes definidas pelo
IEEE, como Ethernet, Bluetooth e muitos outros.
EUI48 108 RFC 7043 Devido a preocupações de segurança (descoberta de
detalhes de configuração local que podem ser usados
para montar ataques DDoS), recomenda-se que o
endereço EUI48 seja armazenado apenas no DNS de
namespace privado. Suportado a partir do BIND 9.10+.
Método de armazenamento de endereços de 64 bits EUI
(Extended Unique Identifier) no DNS. Os endereços
EUI64 109 RFC 7043
EUI-64 são usados por redes definidas pelo IEEE, como
Firewire, 802.15 (WPAN) e outros. Também é usado
 pelo IPv6 como 64 bits de ordem baixa do endereço em
configurações sem estado. Devido a preocupações de
segurança (descoberta de detalhes de configuração local
que podem ser usados para montar ataques DDoS),
recomenda-se que o endereço EUI64 seja armazenado
apenas no DNS de namespace privado. Suportado a
partir de BIND 9.10+.
Informação do host - dados de texto opcionais sobre um
HINFO 13 RFC 1035
host.
ISDN address. Experimental = aplicações especiais
ISDN 20 RFC 1183
apenas.
KEY 25 RFC 2535 Public key associado a um nome DNS.
Stores GPS data. Experimental - as considerações de
LOC 29 RFC 1876
segurança reduziram o uso.
Mail Exchanger. Um valor de preferência e o nome do
MX 15 RFC 1035 host para um servidor de correio / trocador que irá
atender esta zona. RFC 974 define nomes válidos.
Naming Authority Pointer Record. Mínimo número
equivocado. Definição de definição geral de conjunto
de regras a ser usado por aplicativos para o Sistema de
NAPTR 35 RFC 3403
Descoberta de Delegação Dinâmica (DDDS), por
exemplo, VoIP ou ENUM. RR complexo mas
interessante.
Name Server. Define o (s) servidor (es) de nome
NS 2 RFC 1035 autorizado para o domínio (definido pelo registro SOA)
ou o subdomínio.
DNSSEC. Próximo registro seguro. Ssed para fornecer
NSEC 47 RFC 4034
prova de inexistência de um nome.
DNSSEC Next Domain record type. Uso obsoleto
NXT 30
NSEC.
Endereço IP (IPv4 ou IPv6) para hospedar. Usado em
PTR 12 RFC 1035
reverse maps.
Informações sobre pessoa responsável. Experimental -
RP 17 RFC 1183
aplicativos especiais apenas.
RRSIG 46 RFC 4034 DNSSEC. Assinado RRset.
Through-route binding. Experimental - aplicativos
RT 21 RFC 1183
especiais apenas.
SIG 24 RFC 2535 DNSSEC. Uso obsoleto RRSIG. SIG (0) é sintetizado
como um meta RR especial em DDNS e segurança de
transferência de zona.
SOA 6 RFC 1035 Start of Authority. Define o nome da zona, um contato
de e-mail e vários tempos e atualiza os valores
aplicáveis à zona.
The Sender Policy Framework (v1). Usado tipicamente
em conjunto com um TXT RR contendo a mesma
informação e, além do tipo RR, o mesmo formato.
SPF 99 RFC 4408
Define os servidores que estão autorizados a enviar o
correio para um domínio. Sua principal função é
prevenir o roubo de identidade por spammers.
 Define serviços disponíveis na zona, por exemplo, ldap,
SRV 33 RFC 2872 http, sip etc. Permite a descoberta de servidores de
domínio que oferecem serviços específicos.
Informações de texto associadas a um nome. o SPF
record should be defined using a TXT record and pode
(a partir de abril de 2006) ser definido usando um SPF
TXT 16 RFC 1035
RR. DKIM (RFC 4871 também faz uso do TXT RR
para autenticação de e-mail. Relacionado: How to
define DKIM/ADSP RRs.
Uma alternativa ao registro SRV, pelo qual a string URI
completa é retornada para o serviço necessário. Ao
URI 256 RFC 7553 contrário do SRV RR onde a corda URI final deve ser
montada a partir de uma mistura de cordas de busca e
resultado.
Bem conhecidos serviços. Desaparecido a favor de
WKS 11 RFC 1035
SRV.
X.25 address. Experimental - aplicativos especiais
X25 19 RFC 1183
apenas.
O valor é o valor decimal do tipo RR em binary or wire-format.

Zone File Directives

As diretivas começam com '$' e são padronizados - $ORIGIN e $INCLUDE (definido na RFC
1035) e $TTL (definido na RFC 2308). BIND adicionalmente fornece o não padrão $GENERATE
diretiva.

Directive Description
$INCLUDE Inclui o arquivo definido em linha.
Define o nome da base (aka label) para ser usado para a substituição do nome "não
$ORIGIN
qualificado".
Define o valor TTL do Recurso de Recurso padrão, usado se nenhum TTL for
$TTL
definido em um registro de recursos.

DNS Queries
A principal tarefa realizada por um servidor DNS é responder a perguntas (perguntas) de
um resolvedor local ou remoto ou outro DNS atuando em nome de um resolvedor. Uma consulta
seria algo como "qual é o endereço IP de fred.example.com".
Um servidor de DNS pode receber tal consulta para qualquer domínio. Os servidores DNS
podem ser configurados para serem autorizados para alguns domínios, escravos para outros,
encaminhar consultas ou outras combinações.
A maioria das consultas que um servidor DNS receberá será para domínios para os quais
não possui conhecimento, ou seja, para o qual não possui arquivos de zona local. O software de
DNS geralmente permite que o servidor de nomes responda de maneiras diferentes às consultas
sobre quais não tem conhecimento.
Há três tipos de consultas definidas para o DNS:
 1. A Recursive Queries - A resposta completa à pergunta sempre é retornada. Os servidores
DNS não são necessários para suportar consultas recursivas.
2. A Interative (ou não recursiva) - onde a resposta completa pode ser devolvida ou uma
referência fornecida a outro DNS. Todos os servidores DNS devem suportar consultas
Iterativas.
3. A Inverse query - onde o usuário deseja conhecer o nome do domínio, dado um registro de
recursos. As consultas inversas foram mal suportadas, muito pouco frequentes e agora são
obsoletas (RFC 3425).
Nota: O processo chamado Reverse Mapping (retorna um nome de host dado um endereço IP) não
usa consultas inversas, mas usa consultas Recursivas e Iterativas (não recursivas) usando o nome de
domínio especial IN-ADDR.ARPA.
Historicamente o reverso do mapeamento IPv4 não era obrigatório. Muitos sistemas, no
entanto, agora usam mapeamento reverso para segurança e esquemas de autenticação simples
(especialmente servidores de correio), de modo que a implementação e manutenção corretas são
praticamente essenciais. O IPv6 originalmente requisitou o mapeamento reverso, mas, como muitos
dos mandatos originais do IPv6, agora foi revertido.

Recursive Queries
Uma consulta recursiva é aquela em que o servidor DNS responderá completamente a
consulta (ou dará um erro). Os servidores DNS não necessitam suportar consultas recursivas e o
resolvedor (ou outro DNS atuando de forma recursiva em nome de outro resolvedor) negociam o
uso do serviço recursivo usando um bit no RD do cabeçalho da consulta.
Existem três respostas possíveis para uma consulta recursiva:
1. A resposta à consulta acompanhada de qualquer CNAME records (alias) que podem ser
úteis. A resposta indicará se os dados são autoritativos ou armazenados em cache.
2. Um erro indicando o domínio ou o host não existe (NXDOMAIN). Esta resposta também
pode conter registros CNAME que apontaram para o host não existente.
3. Uma indicação de erro temporário - por exemplo, não pode acessar outros DNS devido a
erros de rede etc.
Em uma consulta recursiva, um DNS Resolver irá, em nome do cliente (stub-resolvedor),
perseguir a trilha do sistema DNS em todo o universo para obter a resposta real à questão. A jornada
de uma consulta simples, como "o que é o endereço IP de www.example.com" para um Resolvedor
de DNS que suporta consultas recursivas, mas não autorizada para exemplo.com, é mostrada no
Diagrama 1-3 abaixo:
Iterative (non-recursive) Queries
Uma consulta Iterativa (ou não recursiva) é aquela em que o servidor DNS pode fornecer
uma resposta ou uma resposta parcial (uma referência) à consulta (ou dar um erro). Todos os
servidores DNS devem suportar consultas não recursivas (Iterativas). Uma consulta iterativa é
tecnicamente simplesmente uma consulta de DNS normal que não solicita serviços recursivos.
Existem quatro respostas possíveis para uma consulta não recursiva:
1. A resposta à consulta acompanhada de qualquer CNAME records (alias) que podem ser úteis
(em uma Consulta Iterativa isso só ocorrerá se os dados solicitados já estiverem disponíveis
no cache). A resposta indicará se os dados são autoritativos ou armazenados em cache.
2. Não existe um erro indicando o domínio ou o host (NXDOMAIN). Esta resposta também
pode conter registros CNAME que apontaram para o host não existente.
3. Uma indicação de erro temporário, por exemplo, não pode acessar outros DNS devido a
erros de rede, etc.
4. Uma referência: se os dados solicitados não estiverem disponíveis no cache, então o nome e
as adenções de IP de um ou mais servidores de nomes mais próximos do nome de domínio
solicitado (em todos os casos, este é o próximo nível mais baixo em a hierarquia do DNS)
será retornada. Esta referência pode ou não ser para o servidor de nomes autoritário para o
domínio alvo.
No Diagrama 1-3 acima, as transações (3), (4) e (5) são normalmente todas as consultas
iterativas. Mesmo que o servidor DNS solicite Recursão (RD = 1), seria negado e uma referência
normal (ou resposta) retornada. Por que usar consultas Iterativas? Eles são muito mais rápidos, o
servidor DNS que recebe a consulta já possui a resposta no seu cache, caso em que o envia ou não,
caso em que envia um encaminhamento. Sem mexer. As consultas iterativas dão maior poder ao
solicitante. Normalmente, uma referência contém uma lista de servidores de nomes para o próximo
nível na hierarquia de DNS. O solicitante pode ter informações adicionais sobre um ou mais desses
servidores de nomes em seu cache (incluindo qual é o mais rápido) a partir do qual ele pode tomar
uma decisão melhor sobre o servidor de nomes a ser usado. As consultas iterativas também são
extremamente úteis em situações de diagnóstico.