Texto original
Refresh: How often a secondary will poll the primary server to see
Sugira uma tradução melhor
Rede Grupo de Trabalho D. Barr
Pedido de Comentários: 1912 A Universidade Estadual da Pensilvânia
Obsoletes: 1537 fevereiro 1996
Categoria: Informativos
DNS erros comuns operacionais e Configuração
Status do presente Memo
Esta nota fornece informações para a comunidade da Internet. Este memorando
não especifica um padrão Internet de qualquer tipo. Distribuição de
Este memorando é ilimitado.
Abstrato
Este memorando descreve os erros encontrados frequentemente em tanto a operação de
Domain Name System (DNS), e em que estes dados DNS
servidores contêm. Este memorando tenta resumir Internet atual
bem como os requisitos de prática comum na operação e
configuração do DNS. Esta nota também tenta resumir ou
sobre questões levantadas em [RFC 1537].
1. Introdução
Executando um servidor de nomes não é uma tarefa trivial. Há muitas coisas
que pode dar errado, e muitas decisões têm de ser feitas sobre os dados
para colocar no DNS e como configurar servidores. Este memorando tentativas de
resolver muitos dos erros comuns e armadilhas que são feitos em DNS
dados, bem como na exploração de nomes. As discussões estão
Também fez relativamente a outras questões relevantes, tais como servidor ou
bugs de resolver, e algumas questões políticas com relação ao
operação de DNS na Internet.
2. Dados DNS
Esta seção discute as pessoas normalmente têm problemas com o DNS
dados em seus nomes, como os encontrados nos arquivos de dados da zona que o
cargas nameserver na memória.
2,1 inconsistentes, dados perdidos, ou Bad
Cada host Internet-alcançável deve ter um nome. As conseqüências
deste estão se tornando mais e mais evidente. Muitos serviços disponíveis
na Internet não vai falar com você se você não for corretamente
registrado no DNS.
Barr Informativa [Page 1]
RFC 1912 DNS erros comuns fevereiro 1996
Verifique se o seu PTR e A correspondência entre os registros. Para cada endereço IP, não
deve ser um registro PTR correspondência no domínio in-addr.arpa. Se um
hospedeiro é multi-homed, (mais de um endereço IP) para garantir que todos os IP
endereços têm um registro PTR correspondente (e não apenas o primeiro).
A não têm correspondência e registros PTR pode causar perda de Internet
serviços similares ao não ter sido registrado no DNS em todas. Além disso,
PTR deve voltar a um ponto válido um registro, não um alias definido
por um CNAME. É altamente recomendado que você use algum software
que automatiza esta verificação, ou gerar os dados do DNS de um
banco de dados que cria automaticamente dados consistentes.
Nomes de domínio DNS consistem de "rótulos" separados por pontos individuais. O
DNS é muito liberal em suas regras para os caracteres permitidos em um
nome de domínio. No entanto, se um nome de domínio é usado para nomear um hospedeiro, ela
deve seguir regras que restringem nomes de host. Além disso, se um nome é
utilizado para o correio, deve seguir as regras de nomenclatura para nomes no correio
endereços.
Caracteres permitidos em um rótulo para um nome de host são apenas ASCII
letras, dígitos, e as `- 'personagem. Rótulos não pode ser tudo
números, mas pode ter um dígito (por exemplo, 3com.com). As etiquetas devem
final e só comece com uma letra ou um dígito. Veja [RFC 1035] e [RFC
1123]. (As etiquetas foram inicialmente limitados em [RFC 1035] para começar
uma carta, e alguns mais antigos anfitriões ainda tem problemas com relatos
o relaxamento em [RFC 1123].) Nota: existem algumas Internet
hostnames que violam esta regra (411.org, 1776.com). A presença
de sublinhados em uma etiqueta é permitida em [RFC 1033], excepto [RFC 1033]
é apenas informativa e não foi a definição de um padrão. Há menos
pelo menos uma implementação de TCP / IP popular que atualmente se recusa a
hosts chamado a falar com eles em sublinhados. Deve-se notar que
o idioma em [1035] é tal que essas normas são voluntárias - eles
estão lá para aqueles que desejam minimizar os problemas. Note-se que o
regras para nomes de host de Internet também se aplicam aos hosts e endereços utilizados
em SMTP (Veja RFC 821).
Se o nome de domínio é para ser utilizado para o correio (que não envolvam SMTP), deve
seguir as regras para o correio em [RFC 822], o que é realmente mais
liberal do que as regras acima. Etiquetas para e-mail pode ser qualquer ASCII
caractere, exceto "especiais", caracteres de controle, e espaços em branco
caracteres. "Specials" são símbolos específicos utilizados na análise de
endereços. Eles são os personagens "() <> @,;: \" [] "." (A ".!
carácter não estava em [RFC 822], no entanto, também não deve ser utilizado devido
para o conflito com o correio UUCP como definido na RFC 976) No entanto, desde
hoje, quase todos os nomes que são usados para o correio na Internet são
também nomes usados para nomes de hosts, raramente vê endereços usando estes
padrão relaxado, mas o software de e-mail deve ser feita liberal e robusto
o suficiente para aceitá-los.
Barr Informativa [Página 2]
RFC 1912 DNS erros comuns fevereiro 1996
Você também deve ter cuidado para não ter endereços que são válidos
sintaxes suplente para a chamada da biblioteca inet_ntoa (). Por exemplo 0xe
é um nome válido, mas se você digitar "telnet 0xe", seria tentar
se conectar ao endereço IP 0.0.0.14. É também rumores de que há
Existe algum quebrado inet_ntoa () rotinas que tratar um endereço como
x400 como um endereço IP.
Determinados sistemas operacionais possuem limitações no comprimento do seu próprio
hostname. Embora não seja estritamente de emissão para o DNS, você deve ser
consciência dos limites do seu sistema operacional antes de escolher o comprimento
nome de um host.
Lembre-se que muitos dos recursos registros (abreviadamente RR) assumir mais
de um argumento. HINFO exige dois argumentos, como faz RP. Se você
não fornecer argumentos suficientes, os servidores em algum momento por volta de lixo
faltam os campos. Se você precisa incluir qualquer espaço no interior
de dados, você deve colocar a string entre aspas.
2,2 SOA registros
No registro SOA de cada zona, lembre-se de preencher o e-mail
endereço que vai chegar à pessoa que mantém o DNS em seu
site (vulgarmente designado por "hostmaster"). O `@ 'no e-mail
deve ser substituído por um `. ' em primeiro lugar. Não tente colocar um `@ 'sinal em
este endereço. Se a parte local do endereço já contém um
`. ' (Por exemplo, John.Smith @ widget.xx), então você precisa citar os `. ' por
precedendo-o com `\ 'personagem. (Por exemplo, para se tornar
John \ Smith.widget.xx.) Alternativa (e preferido), você pode apenas usar
o nome genérico `hostmaster ', e usar um alias para redirecionar-mail para
as pessoas competentes. Existe software que utiliza este campo
para gerar automaticamente o endereço de e-mail para a zona contato.
Este software vai quebrar se este campo está mal formatado. Ele
É imperativo que este endereço para obter uma ou mais pessoas reais,
porque muitas vezes é usado para relatar tudo de mau dados DNS
para notificação de incidentes de segurança.
Mesmo que algumas versões do BIND permitem que você use um decimal em uma série
número, não. Um número decimal é convertido para um unsigned
32-bit inteiro internamente qualquer maneira. A fórmula para uma série nm
número é n * 10 ^ (3 + int (0,9 + log10 (m))) + m que se traduz em
algo bastante inesperado. Por exemplo, é possível rotineiramente
com um número decimal (talvez gerado automaticamente por
SCCS) a ser incrementado tal que é numericamente maior, mas depois
a conversão rendimento acima de um número de série, que é inferior
antes. Decimal números de série foram oficialmente substituído no
versões recentes do BIND. A sintaxe recomendada é YYYYMMDDnn
(AAAA = ano, MM = mês, DD = dia, nn = número de revisão. Isso não vai
overflow até o ano de 4294.
Barr Informativa [Página 3]
RFC 1912 DNS erros comuns fevereiro 1996
Escolha valores lógicos para os valores temporizador no registro SOA (note
valores abaixo devem ser expressas como segundos na zona de dados):
Refresh: Quantas vezes um segundo escrutínio será o principal servidor para ver
se o número de série para a zona aumentou (para que ele saiba
para solicitar uma nova cópia dos dados para a zona). Defina esta opção para
quanto tempo o seu secundários podem conter confortavelmente fora de prazo
dados. Você pode mantê-lo curto (20 minutos a 2 horas) se você
não estão preocupados com um pequeno aumento na largura de banda utilizada, ou
mais tempo (2-12 horas), se sua conexão de Internet é lenta ou é
começou na demanda. BIND versões recentes (4.9.3) tem opcionais
código para notificar automaticamente os dados secundários que tem
mudou, permitindo que você defina este valor TTL para uma longa (um
dia, ou mais).
Repetir: Se um secundário foi possível contactar o primário no
última atualização, espera repetir o valor antes de tentar novamente. Este
valor não é tão importante como os outros, a menos que o secundário está ligado
uma rede distante do primário ou primário é mais
propensos a falhas. É tipicamente uma fração da atualização
intervalo.
Expirar: Quanto tempo ainda será uma secundária tratará a sua cópia da zona
dados como válidos se ele não pode entrar em contato primário. Este valor de
deve ser maior que o tempo de uma queda de grande faria tipicamente
última, e deve ser maior do que o mínimo e de repetição
intervalos, para evitar ter um secundário expirar antes de os dados
ele tem a chance de obter uma nova cópia. Depois de uma zona é um expirou
secundário ainda vai continuar a tentar contactar o primário,
mas não mais fornecerá nameservice para a zona. 2-4
semanas são valores sugeridos.
Mínimo: O padrão TTL (time-to-live) para registros de recursos -
como os dados longas permanecerão em outros nomes "cache. ([RFC
1035] define que este é o valor mínimo, mas parece servidores
a aplicar sempre presente como o valor padrão) Esta é de longe
o temporizador mais importante. Defina esta tão grande quanto é confortável
dada a freqüência com que você atualizar seus nomes. Se você pretende
fazer grandes mudanças, é uma boa idéia de transformar esse valor para baixo
temporariamente antemão. Então espere o valor mínimo anterior,
fazer as alterações, verificar a sua correcção, e transformar este
valor de volta. 1-5 dias são valores típicos. Lembre-se disso
valor pode ser ultrapassado com recurso registros individuais.
Barr Informativa [Página 4]
RFC 1912 DNS erros comuns fevereiro 1996
Como você pode ver, os valores típicos acima para os temporizadores variam amplamente.
Popular como a documentação [RFC 1033] recomendou um dia para o
TTL mínimo, que agora é considerado muito baixo, exceto para zonas com
dados que variam regularmente. Uma vez que um DNS estabiliza, em valores da ordem
de 3 ou mais dias são recomendados. Também é recomendado que você
individualmente substituir o TTL em certos RRS que muitas vezes são
referenciado e não mudar frequentemente de ter valores muito grandes (1-2
semanas). Bons exemplos disso são o MX, A, e PTR do seu
host de correio (s), os registros NS de sua zona, e os registros de seu Um
nameservers.
2,3 Glue A Records
Cola registros são registros que estão associados com registros de NS
fornecer "bootstrapping" a informação do servidor de nomes. Por exemplo:
podunk.xx. em ns ns1.podunk.xx.
em ns ns2.podunk.xx.
ns1.podunk.xx. numa 1.2.3.4
ns2.podunk.xx. numa 1.2.3.5
Aqui, os registros A são referidas como "cola registros".
Cola registros são necessários apenas na zona transmitir arquivos de nameservers
que estão localizados no subdomínio da zona de corrente que está a ser
delegada. Você não deve ter quaisquer registros em uma zona in-addr.arpa
arquivo (a menos que você está usando RFC 1101 estilo de codificação de máscaras de sub-rede).
Se o seu servidor de nomes é multi-homed (tem mais de um endereço IP), você
deve listar todos os seus endereços na cola para evitar o cache
inconsistência devido aos diferentes valores TTL, causando algumas pesquisas para
Não é possível encontrar todos os endereços de seus nomes.
Algumas pessoas em obter o mau hábito de colocar uma cola em gravar sempre
eles adicionar um registro NS "só para ter certeza". Tendo cola duplicado
registros em seus arquivos de zona só torna mais difícil quando um servidor de nomes
move-se para um novo endereço IP, ou seja removido. Você vai passar horas tentando
descobrir por que as pessoas ainda aleatória ver o endereço IP antigo para alguns
host, porque alguém se esqueceu de alterar ou remover um recorde na cola
algum outro arquivo. Novas versões BIND irá ignorar esses extra cola
registros em arquivos de zonas locais.
As versões mais antigas do BIND (4.8.3 e anteriores) têm um problema onde ele
insere estes registos extra cola na zona de dados de transferência para
secundários. Se uma destas colas é errado, o erro pode ser
propagado a outros nomes. Se dois nomes são secundárias
para outras zonas do outro, é possível para uma continuamente
passar cola registros antigos de volta para o outro. A única maneira de se livrar de
Barr Informativa [Página 5]
RFC 1912 DNS erros comuns fevereiro 1996
os dados antigos é o de matar os dois, remover os arquivos de backup salvos,
e reiniciá-los. Combinado com que essas mesmas versões também tendem
tornar-se mais facilmente infectadas com falsos dados encontrados em outros não-
nameservers secundários (como os dados da zona de raiz).
2,4 registros CNAME
Um registro CNAME não é permitida a coexistir com quaisquer outros dados. Em
outras palavras, se suzy.podunk.xx é um alias para sue.podunk.xx, você
também não pode ter um registro MX para suzy.podunk.edu, ou um registro, ou
até mesmo gravar um TXT. Sobretudo, não tentar combinar CNAMEs e NS
registros como este!:
podunk.xx. IN NS ns1
IN NS ns2
Em Maria CNAME
Maria de 1.2.3.4
Isso é muitas vezes tentada por administradores inexperientes quanto óbvia
maneira de permitir que o seu nome de domínio para também ser um hospedeiro. No entanto, o DNS
servidores como BIND irá ver o CNAME e recusar-se a acrescentar qualquer outro
recursos para esse nome. Desde que há registros estão autorizadas a outros
coexistir com um CNAME, a NS entradas são ignorados. Portanto, todo o
hosts no domínio podunk.xx são ignorados tão bem!
Se você quiser ter o seu domínio também ser um hospedeiro, faça o seguinte:
podunk.xx. IN NS ns1
IN NS ns2
IN A 1.2.3.4
Maria de 1.2.3.4
Não ir ao mar com CNAMEs. Use-os anfitriões quando renomear, mas
plano para se livrar deles (e informar seus usuários). No entanto são CNAMEs
útil (e incentivada) generalizada para nomes de servidores - `ftp '
para o seu servidor ftp, 'www' para o servidor Web, gopher `'para o seu
Servidor Gopher, `notícias 'para seu servidor de notícias Usenet, etc
Não se esqueça de apagar o CNAMEs associado a um host se você
apagar o acolhimento é um alias para. Tais "CNAMEs antigas" são um desperdício
de recursos.
Barr Informativa [Página 6]
RFC 1912 DNS erros comuns fevereiro 1996
Não utilizar em combinação com CNAMEs RRS que apontam para outros nomes
como MX, CNAME, PTR e NS. (PTR é uma exceção se você quiser
implementar delegação in-addr sem classes.) Por exemplo, este é
fortemente desencorajado:
podunk.xx. IN MX mailhost
mailhost em Maria CNAME
Maria de 1.2.3.4
[RFC 1034], no ponto 3.6.2 diz que isso não deve ser feito, e [RFC
974] afirma explicitamente que os registros MX não deve apontar para um alias
definido por um CNAME. Isto resulta em inúteis indirecta em
acesso aos dados, e resolvedores de DNS e os servidores precisam trabalhar mais
para obter a resposta. Se você realmente quer fazer isso, você pode realizar
a mesma coisa usando um pré-processador, como m4 arquivos em seu hospedeiro.
Além disso, tendo registros acorrentados como CNAMEs apontando para CNAMEs pode
administração questões tornar mais fácil, mas é conhecido por fazer cócegas bugs
resolvedores alguns que não conseguem controlar loops corretamente. Como resultado, alguns
hosts pode não ser capaz de resolver esses nomes.
Tendo registros NS apontando para um CNAME é ruim e pode conflito mal
com servidores BIND atuais. Na verdade, implementações actuais BIND
irá ignorar tais registros, possivelmente levando a uma delegação lame.
Há um certo nível de segurança para verificação feita em BIND para
evitar a falsificação de DNS NS registros. Além disso, servidores BIND mais velhos relatos
será pego em um loop infinito query tentando descobrir o
endereço para o servidor de nome de alias, provocando um fluxo contínuo de
Solicitações de DNS para serem enviados.
2,5 registros MX
É uma boa idéia para dar a cada um registro MX acolhimento, mesmo que pontos
a si próprio! Alguns utentes irá cache registros MX, mas será sempre necessário
para verificar uma MX antes de enviar email. Se um local não tem um
MX, em seguida, cada pedaço de correio pode resultar em uma consulta mais resolver,
já que a resposta para a consulta MX muitas vezes também contém os endereços IP
MX dos anfitriões. Internet SMTP utentes são obrigados por [RFC 1123] para
apoiar o mecanismo de MX.
Ponha registros até mesmo em sistemas que não são destinados para enviar ou receber
e-mail. Se houver um problema de segurança que envolve uma destas máquinas,
algumas pessoas erroneamente enviar email para postmaster ou a raiz
site sem verificar primeiro para ver se ele é um anfitrião "real" ou apenas um
terminal ou computador pessoal que não está configurado para aceitar e-mail. Se
você der um registro MX, então o e-mail pode ser redirecionado para um real
pessoa. Caso contrário mail pode apenas sentar-se em uma fila por horas ou dias
Barr Informativa [Página 7]
RFC 1912 DNS erros comuns fevereiro 1996
até o mailer desiste de tentar enviá-lo.
Não se esqueça que sempre que você adicionar um registro MX, você precisa informar
o mailer alvo, se for para tratar o hospedeiro em primeiro lugar como "local". (O
"Cw" bandeira no sendmail, por exemplo)
Se você adicionar um registro MX que aponta para um host externo (por exemplo, para
os fins de backup mail roteamento) não se esqueça de pedir permissão
que o primeiro site. Outro local que pudesse ficar um pouco chateado e tomar
ação (como jogar seu correio de distância, ou apelar a autoridades superiores
gosto do seu pai administrador de DNS ou o provedor de rede.)
Outros 2,6 Resource Records
2.6.1 WKS
Registros WKS são preteridos em [RFC 1123]. Eles não servem útil conhecido
função, exceto internamente entre máquinas LISP. Não usá-los.
2.6.2 HINFO
Nos registros HINFO emissão, alguns argumentam que estes é uma segurança
problema (por transmitir o que o hardware eo sistema operacional fornecedor
você que as pessoas possam executar ataques sistemáticos a fornecedora de segurança conhecido
orifícios). Se você usá-los, você deve manter-se atualizado com conhecida
Problemas de segurança do fornecedor. No entanto, eles servem a um propósito útil.
Não se esqueça que HINFO exige dois argumentos, o tipo de hardware,
e o sistema operativo.
HINFO é por vezes abusado de fornecer outras informações. O recorde
destina-se a fornecer informações específicas sobre a própria máquina.
Se você precisa de expressar outras informações sobre o host no DNS,
usar TXT.
2.6.3 TXT
TXT registros não têm uma definição específica. Você pode colocar mais nada
neles. Alguns usá-lo para uma descrição genérica do hospedeiro, alguns colocam
informações específicas como a sua localização, o usuário principal, ou talvez até mesmo um
número de telefone.
2.6.4 RP
RP registros são relativamente novos. Eles são usados para especificar um e-mail
endereço (ver primeiro parágrafo da seção 2.2) do Responsável "
Pessoa "do anfitrião, eo nome de um registro TXT onde você pode obter
mais informações. Ver [RFC 1183].
Barr Informativa [Página 8]
RFC 1912 DNS erros comuns fevereiro 1996
2,7 registros curinga
MXs curinga são úteis principalmente para os não-IP conectados sites. Um comum
erro é pensar que um curinga MX para uma zona serão aplicadas a todos
anfitriões na zona. Um curinga MX será aplicável apenas aos nomes no
zona que não estão listados no DNS em todas. eg,
podunk.xx. IN NS ns1
IN NS ns2
Maria de 1.2.3.4
*. Podunk.xx. IN MX 5 sue
Correio para mary.podunk.xx será enviada para si próprio para a entrega. Apenas
e-mail para jane.podunk.xx ou quaisquer hosts você não vê acima será enviado
para o MX. Para a maioria dos sites de Internet, curinga registros MX não são
úteis. Você precisa colocar registros MX explícitas em cada host.
MXs curinga pode ser ruim, porque eles fazem algumas operações de sucesso
quando eles devem deixar em seu lugar. Considere o caso em que alguém na
o domínio "widget.com" tenta enviar email para "joe @ Larry". Se o
host "Larry" na verdade não existe, o e-mail deve, em salto fato
imediatamente. Mas por causa do domínio pesquisar o endereço fica
resolveram "larry.widget.com", e por causa do MX curinga esta
é um endereço válido de acordo com DNS. Ou talvez alguém simplesmente fez
um erro de digitação na parte de nome do host do endereço. A mensagem de correio depois
é roteada para o host de correio, que então rejeita o e-mail com
mensagens de erro estranhas como "Eu me recuso a falar para mim" ou "Local
erro de configuração ".
Registros MX curinga são bons para quando você tem um grande número de
máquinas que não são diretamente conectado à Internet (por exemplo, por trás
um firewall) e por razões administrativas ou político, é muito
difícil ter registros MX individuais para cada máquina, ou para forçar
todos os endereços de correio electrónico para ser "escondido" atrás de um ou mais nomes de domínio.
Nesse caso, você deve dividir o seu DNS em duas partes, uma interna
DNS, e um DNS externo. O DNS externo terá apenas alguns
anfitriões e MX explícitas, e um ou mais MXs curinga para cada
domínio interno. Internamente, os DNS será completa, com todos os
explícitas registros MX e sem curingas.
Como curinga e CNAMEs também são possíveis, e são realmente confuso para
usuários, e um pesadelo potencial se utilizados sem pensar primeiro. Ele
poderia resultar (devido novamente ao domínio pesquisando) em qualquer telnet / ftp
tentativas de dentro do domínio para hosts desconhecidos para ser direcionado para
um endereço. Um (edu.com em *.) Tal curinga CNAME causado
Internet em toda a perda de serviços e pesadelos de segurança em potencial devido
para interações inesperadas com a procura de domínio. Isso resultou em
correções rápidas, e até mesmo um RFC ([RFC 1535]) documentar o problema.
Barr Informativa [Página 9]
RFC 1912 DNS erros comuns fevereiro 1996
2,8 Autoridade e Erros delegação (registros NS)
Você é obrigado a ter pelo menos dois nomes para cada domínio,
embora seja mais preferido. Têm secundários fora de sua rede. Se
o secundário não está sob seu controle, verifique periodicamente se sobre eles
e certifique-se que está recebendo dados actual zona de você. Consultas para
seu servidor de nomes sobre os seus anfitriões devem sempre resultar em um
Resposta "oficial". Se não, isso é chamado de um coxo "
A delegação ". delegações lame existe quando um servidor de nomes é
responsabilidade delegada por fornecer nameservice para uma zona (via NS
registos), mas não está a funcionar nameservice para essa zona (geralmente
porque não está configurado como um primário ou secundário para a zona).
A delegação "clássico" lame pode ser ilustrado neste exemplo:
podunk.xx. IN NS ns1.podunk.xx.
IN NS ns0.widget.com.
"Podunk.xx" é um novo domínio que foi recentemente criado, e
"Ns1.podunk.xx" foi criada para executar nameservice para a zona.
Eles não completamente terminado tudo ainda e não a certeza de que
o hostmaster em "ns0.widget.com" foi criado para ser um bom
secundária, e, portanto, não tem nenhuma informação sobre o domínio podunk.xx,
mesmo que o DNS diz que é suposto. Várias coisas podem
acontecer dependendo do servidor de nome é usado. Na melhor das hipóteses, DNS extras
tráfego irá resultar de uma delegação lame. Na pior das hipóteses, você pode obter
Exércitos não resolvidos e saltou de e-mail.
Também, às vezes um servidor de nomes é movido para outro host ou removidos
a lista de secundários. Infelizmente, devido ao cache de registros NS,
muitos sites ainda pensam que um host é um secundário depois que
anfitrião parou de fornecer nameservice. A fim de evitar coxo
delegações, enquanto o cache está sendo envelhecido, continuar a fornecer
nameservice no servidor de nome de idade para o comprimento do máximo de
os tempos mínimos acrescidos de atualização para a zona e zona pai.
(Veja a seção 2.2)
Sempre que um primário ou secundário é removido ou alterado, é preciso um
quantidade de coordenação humana entre as partes envolvidas. (O
próprio site, que é pai, e do site que hospeda o secundário) Quando um
movimentos primários, certifique-se de todas as secundárias têm seus arquivos named.boot
atualizado e seus servidores recarregado. Quando se move um secundárias, fazer
certeza de que os registros de endereços, tanto a nível primário e pai são
alterados.
Também foi relatado que alguns locais distantes gosto de escolher populares
nameservers como "ns.uu.net" e basta adicioná-lo à sua lista de NS
registros na esperança de que eles vão magicamente realizar adicional
Barr Informativa [Página 10]
RFC 1912 DNS erros comuns fevereiro 1996
nameservice para eles. Esta é uma forma ainda pior de delegação lame,
uma vez que esta acrescenta o tráfego para um servidor de nomes já ocupadas. Por favor
entre em contato com o hostmasters de sítios que têm delegações lame.
Várias ferramentas podem ser usadas para detectar ou localizar activamente lame
delegações. Veja a lista de software contribuíram no BIND
distribuição.
Verifique se o seu domínio pai tem os mesmos registros NS para a sua zona como
você faz. (Não se esqueça de seus in-addr.arpa zonas também!). Não lista
demais (7 é o máximo recomendado), pois só faz as coisas
mais difícil de gerir e só é realmente necessário para a muito popular superior
nível ou zonas de raiz. Você também corre o risco de transbordamento do 512 -
limite de bytes de um pacote UDP na resposta a uma consulta NS. Se esta
acontece, resolvedores irá "retroceder" para usar pedidos TCP, resultando
em aumento de carga em seus nomes.
É importante quando se escolhe localizações geográficas para secundário
nameservers para minimizar a latência, bem como aumentar a confiabilidade.
Tenha em mente rede topologias. Por exemplo, se o seu site está no
outra extremidade de uma ligação lenta local ou internacional, considere um secundário
no outro lado da ligação para diminuir a latência média. Contato
seu provedor de serviços Internet ou contato domínio pai para mais
informações sobre secundários que podem estar disponíveis para você.
3. Operação BIND
Esta seção discute problemas comuns que as pessoas têm na real
operação do servidor de nomes (especificamente, BIND). Não só o
dados ser correcta, tal como explicado acima, mas deve ser o nameserver
operado correctamente para os dados a serem disponibilizados.
3,1 números de série
Cada zona tem um número de série associado a ele. O seu uso é para
mantendo o controle de quem tem os dados mais atuais. Se, e apenas se o
número de série do primário da zona é maior que o secundário pedir
o principal para uma cópia dos dados da zona novos (ver caso especial abaixo).
Não se esqueça de alterar o número de série quando você alterar os dados! Se
você não, seu secundários não irá transferir a nova zona
informação. Automatizando o incremento do número de série com
software também é uma boa idéia.
Se você cometer um erro e incrementar o número de série muito alto, e
você deseja redefinir o número de série para um valor inferior, use o
seguinte procedimento:
Barr Informativa [Página 11]
RFC 1912 DNS erros comuns fevereiro 1996
Leve o `número 'incorreto de série e adicionar 2147483647 a ele. Se
o número excede 4294967296, 4294967296 subtrair. Carregar o
resultando número. Então espere dois períodos de atualização para permitir que a zona
se propaguem para todos os servidores.
Repita até acima do número de série resultante é menor do que o
atingir o número de série.
Se o número de série para o alvo número de série.
Este procedimento não vai funcionar se um de seus secundários está executando um
versão antiga do BIND (4.8.3 ou anterior). Neste caso, você vai ter que
entre em contato com o hostmaster para que secundário e tê-los matar o
servidores secundários, remova o arquivo de backup salvo, e reiniciar o
servidor. Tenha cuidado ao editar o número de série - DNS administradores
não gostam de matar e reiniciar nameservers porque você perde tudo o que
dados em cache.
3,2 Zona guia de estilo arquivo
Aqui estão algumas dicas úteis na estruturação de seus arquivos de zona. Seguido
estes irão ajudá-lo a detectar erros, e evitar fazer mais.
Seja coerente com o estilo de entradas em seus arquivos de DNS. Se o seu
. $ ORIGIN é podunk.xx, tente não escrever entradas como:
Maria de 1.2.3.1
sue.podunk.xx. IN A 1.2.3.2
ou:
bobbi EM UM 1.2.3.2
IN MX mary.podunk.xx.
Ou usar todos os FQDNs (Nomes de domínio totalmente qualificado) ou em todos os lugares
utilizados nomes não qualificados em todos os lugares. Ou ter FQDNs tudo sobre o direito
lado, mas nomes não qualificados à esquerda. Acima de tudo, ser
consistente.
Use tabulações entre campos, e tentar manter as colunas alinhadas. Faz-
mais fácil de detectar campos faltantes (observe alguns campos como "IN" são
herdadas do anterior recorde e pode ser deixada de fora em certas
circunstâncias.)
Barr Informativa [Página 12]
RFC 1912 DNS erros comuns fevereiro 1996
Lembre-se que você não precisa repetir o nome do host quando você está
definir vários registros para um host. Certifique-se também de manter todos
registros associado com uma série juntos no arquivo. Isso fará com que
as coisas mais simples, quando chega a hora de remover ou renomear uma
host.
Lembre-se sempre a sua origem $. Se você não colocar um `. ' no final do
um FQDN, não é reconhecido como um FQDN. Se não é um FQDN, então
os nameserver irá acrescentar $ origem ao nome. Verificação duplo, triplo
verificar, os pontos finais, especialmente em arquivos zona in-addr.arpa,
onde eles são mais necessários.
Tenha cuidado com a sintaxe dos registros SOA e WKS (os registros
que use parênteses). BIND não é muito flexível na forma como ele analisa
esses registros. Consulte a documentação do BIND.
3.3 Dados Verificando
Verifique os dados que você acabou de inserir ou alterados por meio de consulta a resolver
com escavação (ou sua ferramenta de DNS favorito, muitos estão incluídos no BIND
distribuição) com uma alteração. Alguns segundos gasto duplo controlo
pode economizar horas de dificuldade, perdeu mail, e dores de cabeça em geral. Também ser
Certifique-se de verificar a saída de syslog quando você recarregar o servidor de nomes. Se você
tem graves erros em seus dados DNS ou o arquivo de inicialização, nomeado informará
ele via syslog.
Também é altamente recomendado que você automatizar esta verificação, ou
com software que roda checagens sobre os arquivos de dados antes que eles
são carregados para o servidor de nome, ou com o software que controla a
dados já carregados no servidor de nomes. Alguns softwares contribuíram para
fazer isto está incluído na distribuição BIND.
4. Tópicos Diversos
4,1 configuração do arquivo de inicialização
Certas zonas deve estar sempre presente em configurações do servidor de nomes:
localhost localhost primária
primária 0.0.127.in-addr.arpa 127,0
primária 255.in-addr.arpa 255
primária 0.in-addr.arpa 0
Estes são criados para fornecer ou nameservice para "especial"
endereços, ou para ajudar a eliminar consultas acidentais de transmissão ou
endereço local para ser enviado para os servidores de nomes de raiz. Todos estes
arquivos irá conter registros NS e SOA como os arquivos de zonas outros
você manter, com a exceção de que você pode provavelmente fazer o SOA
Barr Informativa [Página 13]
RFC 1912 DNS erros comuns fevereiro 1996
temporizadores muito longos, uma vez que esses dados nunca vai mudar.
O endereço "localhost" é um endereço "especial" que sempre se refere a
o host local. Ele deve conter a seguinte linha:
localhost. IN A 127.0.0.1
O arquivo "127,0" deve conter a linha:
1 localhost PTR.
Tem havido alguma discussão mais ampla sobre se deve ou não
acrescentar o domínio local para ela. A conclusão é que "localhost".
seria a melhor solução. As razões incluem:
"Localhost" por si só é utilizada e deve funcionar em alguns
sistemas.
Traduzindo em 127.0.0.1 "localhost.dom.ain" pode causar algum
software para ligar de volta para a interface de loopback quando ele não fez
quer porque "localhost" não é igual a "localhost.dom.ain".
O "255" e "0" arquivos não devem conter quaisquer dados adicionais para além
o NS e SOA registros.
Note-se que versões BIND futuras podem incluir todos ou alguns destes dados
automaticamente sem configuração adicional.
Outros 4,2 Resolver e Server erros
Versões muito antigas do resolvedor DNS tem um bug que as consultas causa
para os nomes que se parecem com os endereços IP para sair, porque o usuário
fornecido um endereço IP eo software não percebeu que isso não aconteceu
necessitam de ser resolvidos. Este foi fixado mas ocasionalmente ainda
aparece. É importante porque este erro significa que essas consultas
serão enviados diretamente para os servidores de nomes de raiz, acrescentando a uma já
DNS carga pesada.
Durante a execução de um servidor de nomes secundário fora de um outro servidor de nomes secundário
é possível, não é recomendado a menos que necessário devido à rede
topologias. Há casos conhecidos em que levou a problemas como
falsos valores TTL. Enquanto isto pode ser causado pelo DNS mais antigos ou com defeito
implementações, você não deve secundários da cadeia de fora de um outro
uma vez que esta se acumula dependências confiabilidade adicionais, bem como
acrescenta atrasos adicionais na atualizações de dados nova zona.
Barr Informativa [Página 14]
RFC 1912 DNS erros comuns fevereiro 1996
4.3 Questões do Servidor
DNS opera principalmente via UDP (User Datagram Protocol) mensagens.
Alguns sistemas operacionais UNIX, em um esforço para salvar os ciclos da CPU, execute
com UDP checksums desligado. Os méritos relativos de este ter tempo
sido debatido. No entanto, com o aumento da velocidade da CPU, o
considerações de desempenho tornam-se cada vez menos importante. É
fortemente encorajados que você ligue UDP checksum para evitar
dados corrompidos, não só com o DNS, mas com outros serviços que usam UDP
(Como NFS). Verifique com a documentação do sistema operacional para verificar
que checksumming UDP é ativado.
Referências
[RFC 974] Partridge, C., "Mail encaminhamento e sistema de domínio", STD
14, RFC 974, CSNET CIC BBN Laboratories Inc, Janeiro de 1986.
[RFC 1033] Lottor, M, "Domain Administradores Guia de Operações", RFC
1033, USC / Information Sciences Institute, novembro de 1987.
[RFC 1034] Mockapetris, P., "Nomes de Domínio - Conceitos e Recursos",
STD 13, RFC 1034, USC / Information Sciences Institute,
Novembro de 1987.
[RFC 1035] Mockapetris, P., "Nomes de Domínio - Implementação e
Especificação ", STD 13, RFC 1035, USC / Information Sciences
Institute, Novembro de 1987.
[RFC 1123] Braden, R., "Requisitos para a Internet Hosts -
Aplicação e Suporte ", STD 3, RFC 1123, IETF, outubro
1989.
[RFC 1178] Libes, D., "Escolher um nome para o computador", FYI 5, RFC
1178, Integrated Systems Group / NIST, Agosto de 1990.
[RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L e C. Everhart,
"Novas Definições DNS RR", RFC 1183, outubro de 1990.
[RFC 1535] Gavron, E., "um problema de segurança e de correção propostos
Com muito utilizados DNS Software ", RFC 1535, ACES
Research Inc., Outubro de 1993.
[RFC 1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., e S.
Miller, "DNS comuns erros de implementação e sugeriu
Correções ", RFC 1536, USC / Information Sciences Institute, USC,
Outubro de 1993.
Barr Informativa [Página 15]
RFC 1912 DNS erros comuns fevereiro 1996
[RFC 1537] Beertema, P., "DNS comuns erros de dados arquivo de configuração",
RFC 1537, CWI, outubro de 1993.
[RFC 1713] A. Romão, "Ferramentas para depuração de DNS", RFC 1713, a FCCN,
Novembro de 1994.
[BOG] Vixie, P, et. ai., "Nome do Servidor Guia de Operações para BIND",
Vixie Enterprises, Julho de 1994.
5. Considerações sobre segurança
As questões da segurança não são discutidos neste Memo.
6. Endereço do autor
David Barr
A Universidade Estadual da Pensilvânia
Departamento de Matemática
334 Whitmore Edifício
University Park, PA 16802
Voz: +1 814 863 7374
Fax: +1 814 863-8311
EMail: barr@math.psu.edu
Barr Informativa [Página 16]
Nenhum comentário:
Postar um comentário