☰

Opção de servidor unbound.conf "domínio privado" - nome de domínio terminando em ponto ou não?

tag-icon • tag-icon domain-name-system debian-stretch syntax unbound
Opção de servidor unbound.conf "domínio privado" - nome de domínio terminando em ponto ou não?

unbound.confé usado para configurarNão consolidado, um resolvedor de DNS com cache. Odocumentaçãoda versão 1.6.8 diz:

Server Options
    private-domain: <domain name>
        Allow this domain, and all its subdomains to contain private
        addresses. Give multiple times to allow multiple domain names
        to contain private addresses. Default is none.

Executamos a versão 1.6.0 não vinculada com Debian Stretch (a página de manual e a documentação citada não diferem aqui).

Testamos as três variantes a seguir separadas por

  • edição/etc/unbound/unbound.conf
  • verificandounbound-checkconf
  • reiniciandosystemctl restart unbound.service
  • monitorando o arquivo de log não vinculado.

Variante 1 (terminando em ponto):

private-domain: domain.example.

Variante 2 (sem terminar em ponto):

private-domain: domain.example

Variante 3 (em determinada ordem):

private-domain: "domain.example. domain.example"

Para todas as três variantes unbound-checkconfretorna:

unbound-checkconf: no errors in /etc/unbound/unbound.conf

Na variante 3 encontramos no arquivo de log:

debug: ignoring duplicate private-domain: domain.example.

Faz sentido, porque uma entrada para o mesmo nome de domínio tem que ser suficiente e parece verificar que unbound tem um tratamento idêntico para ambas as formas de escrever os nomes de domínio (com/sem ponto).

Ambas as formas estão funcionando, mas qual é a sintaxe correta para definir nomes de domínio privados não vinculados? Os nomes de domínio devem terminar em ponto ou não? O ponto no final é útil ou sem sentido? Que implicações um ponto desnecessário ou ausente poderia ter?

Responder1

Essa pergunta é antiga, mas ainda apareceu para mim como a primeira entrada em uma pesquisa, então vale a pena tentar responder, na IMO.

Resumindo: neste contexto, e na maioria dos outros, não há diferença prática entre domain.example(with no trailing .) e domain.example.(with the training .). Ambos estão, portanto, corretos.

Agora a resposta longa. :) Esta resposta – e o único outro comentário agora aqui, de 2018 – procede do que diz a especificação, como também faz o comentário de 2018 ao OP. Embora possa haver diferenças semânticas entre o RFC e a forma como o Unbound usa nomes de domínio, isso seria um desvio da especificação e provavelmente considerado um bug.

RFC 1034 Seção 3.1define a sintaxe central dos nomes de domínio da seguinte forma:

Quando um usuário precisa digitar um nome de domínio, o comprimento de cada rótulo é omitido e os rótulos são separados por pontos ("."). Como um nome de domínio completo termina com o rótulo raiz, isso leva a um formulário impresso que termina com um ponto. Usamos esta propriedade para distinguir entre:

  • uma sequência de caracteres que representa um nome de domínio completo (muitas vezes chamado de "absoluto"). Por exemplo, "poneria.ISI.EDU."

  • uma sequência de caracteres que representa os rótulos iniciais de um nome de domínio que está incompleto e deve ser preenchido por software local usando o conhecimento do domínio local(frequentemente chamado de "relativo"). Por exemplo, "poneria" usado no domínio ISI.EDU.

Nomes relativos são considerados em relação a uma origem bem conhecida ou a uma lista de domínios usada como lista de pesquisa.

Observe a última frase: A menos que seja definida uma "lista de domínios usados ​​como lista de pesquisa", os nomes sem um ponto final são considerados relativos a uma "origem bem conhecida" - ou seja, a raiz da hierarquia de nomes. Para DNS público, a raiz do DNS corresponde aozona raiz; hierarquias de nomes privados raramente se desviam desta convenção.

Para fins práticos, isso significa que um nome de domínio totalmente qualificado (FQDN) sem final .deve quase sempre ser considerado relativo à raiz da hierarquia de nomes, que é equivalente ao mesmo domínio "absoluto". Portanto, domain.example== " domain.exampleem relação à raiz" == domain.example..

Quando as diferentes representações poderão ter implicações? Quando você está lidando comfragmentosde um nome de domínio em vez de um FQDN. Nesse caso, você deve omitir o período e considerar usá-lo nos FQDNs. Se você executar example.com.(observe o ponto final; o servidor raiz envia *.example.comtráfego para você) e quiser configurar east.example.com.como um subdomínio, easté o subdomínio; east.é o domínio de nível superior (TLD) .east.

Novamente: isso é o que diz a especificação. Verifique a documentação da ferramenta que você está configurando, como sempre. Existem também outras áreas da especificação, principalmente a compactação de DNS, onde algumas semânticas adicionais são introduzidas. Você pode ignorá-los se não estiver literalmente analisando ou gerando mensagens no protocolo de transmissão DNS.

Esperamos que isso responda totalmente à pergunta. Espero que isso seja útil para alguém.

informação relacionada