Os nomes de host de uma letra são válidos?


14

A RFC-952 (última frase do ponto 1 em Suposições) proíbe nomes de host de um caractere e eu tive experiências (há mais de 7 anos no verão de 2002) em que alguns serviços se recusariam a trabalhar com nomes de host de um caractere (porque esses nomes eram não é compatível com os padrões), mas vi vários nomes de host de um caractere em uso nos últimos anos. Os nomes de host de um caractere agora são válidos? (Em caso afirmativo, qual é a referência de validação adequada?)

editar (para consolidar algumas informações das respostas): vários aspectos do DNS parecem ser definidos em várias RFCs, incluindo 1035 , 1123 e 2181 . Na seção 11 da RFC-2181 :

Note however, that the various applications that make use of DNS data
can have restrictions imposed on what particular values are
acceptable in their environment.  For example, that any binary label
can have an MX record does not imply that any binary name can be used
as the host part of an e-mail address.
[ ... ]
See also [RFC1123] section 6.1.3.5.

Na seção 6.1.3.5 da RFC-1123 :

The DNS defines domain name syntax very generally -- a
string of labels each containing up to 63 8-bit octets,
separated by dots, and with a maximum total of 255
octets.  Particular applications of the DNS are
permitted to further constrain the syntax of the domain
names they use, although the DNS deployment has led to
some applications allowing more general names.  In
particular, Section 2.1 of this document liberalizes
slightly the syntax of a legal Internet host name that
was defined in RFC-952 [DNS:4].

Na seção 2.1 do RFC-1123 :

The syntax of a legal Internet host name was specified in RFC-952
[DNS:4].  One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit.  Host software MUST support this more liberal
syntax.

E, finalmente, como referenciado originalmente, no RFC-952 :

1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.).  Note that periods are only allowed when
they serve to delimit components of "domain style names". (See
RFC-921, "Domain Name System Implementation Schedule", for
background).  No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case.  The first
character must be an alpha character.  The last character must not be
a minus sign or period.
[ ... ]
Single character names or nicknames are not allowed.

É por seguir essa cadeia que eu vim originalmente a dizer que o RFC-952 proíbe nomes de host de caracteres únicos.

Respostas:


2

Há uma diferença entre 'válido' e 'funciona'. É perfeitamente possível que os nomes de host não sejam considerados válidos se forem caracteres únicos (minha postagem anterior não é válida). No entanto, muitos sistemas permitem isso. Um sistema principal, o sistema AD / DNS da Microsoft, tem um motivo legado para permitir nomes de caracteres únicos.

Os nomes NetBIOS da velha escola podem ter de 1 a 15 caracteres. Essa especificação foi desenvolvida independentemente da RFC952, e é baseada em um arquivo diferente chamado lmhosts, para que funcione. O problema surgiu quando a Microsoft saiu do NetBEUI (na verdade NBF, NetBIOS Frame Protocol) e entrou no TCP / IP (na verdade NBT), e a Microsoft precisou permitir a resolução de nomes nas redes TCP / IP. A MS optou por manter a resolução no estilo NetBIOS com servidores WINS, ignorando a necessidade de hosts compatíveis com RFC952.

Depois veio o Active Directory e suas dependências DNS. O DNS dinâmico era a regra; portanto, os clientes tinham que registrar o nome do computador (os 15 primeiros caracteres também são o nome NetBIOS) no domínio DNS. Como a MS permite que nomes NetBIOS de um caractere se registrem no DNS, isso entrou em conflito com o RFC952. Eles decidiram codificar seus sistemas para permitir isso, pois isso emulava como sempre funcionava nos dias WINS.

O DNS BIND também permite nomes de host com um único caractere. Mas o RFC2181 afirma bastante que os aplicativos precisam examinar seus próprios dados, e não o DNS. O que nos deixa com uma grande população de dispositivos e software para os quais os nomes de host de um caractere são excelentes e alguns outliers que são restritos à RFC952 e que não permitem isso.


There is a difference between 'valid' and 'it works'. Por fim, acho que essa é a resposta mais razoável, embora tenha apreciado muito toda a discussão gerada. A conclusão que eu tiraria é que os nomes de host de um caractere ainda são tecnicamente inválidos, mas funcionam praticamente universalmente neste momento. (Da mesma forma, sublinhados são proibidos, mas fazer o trabalho para a maior parte.)
Isaac

11

Você acha que eles são válidos porque os servidores de nomes raiz são todos hosts de uma letra (a.root-servers.net) e a especificação de DNS não cria uma exceção específica para eles. O RFC em questão é especificamente para o formato de arquivo host, não DNS. O DNS foi definido em uma RFC posterior (a RFC 1035 inicia). A RFC 1123 (1989) afirma claramente.

 The syntax of a legal Internet host name was specified in RFC-952
 [DNS:4].  One aspect of host name syntax is hereby changed: the
 restriction on the first character is relaxed to allow either a
 letter or a digit.  Host software MUST support this more liberal
 syntax.

Portanto, nomes de host com uma letra são válidos em sistemas baseados em DNS e foram desde antes da invenção do spam. Sistemas que não são compatíveis com RFC e podem ser ridicularizados. A menos que eles não usem DNS e usem apenas arquivos hosts, nesse ponto a pena é uma escolha melhor.


Ok, eu li isso na RFC-1123, mas interpretei que as especificações que li na RFC-952 se aplicam, exceto que um dígito também é permitido como o primeiro caractere (como você citou, isso não altera o proibição de nomes de caracteres únicos). Quanto aos servidores raiz, me disseram em algum momento que eles eram algum tipo de exceção especial à regra.
Isaac

2

Como os nomes de host estavam por aí antes que alguém sequer pensasse em escrever uma RFC sobre eles, não vejo motivo para que nomes de host com um único caractere subitamente se tornem "ilegais". Essa RFC em particular me perdeu quando afirmou

Esta RFC é a especificação oficial

porque um RFC NÃO é um padrão. Nem mesmo perto.

Apesar do exposto, deve-se notar que a RFC em questão foi criada para se aplicar a um grupo relativamente pequeno, a saber, o Departamento de Defesa (presumivelmente dos EUA).


RFC por definição própria não é um padrão. "Solicitação de comentários" não grita exatamente "padrão" para ninguém. Interessante que eles se deram bem em seus próprios documentos.
Mark Henderson

1
en.wikipedia.org/wiki/Domain_name_system#Internet_standards lista muitos RFCs que "definem" o protocolo DNS. O RFC-1123 (como mencionado por sysadmin1138) está entre os listados e faz referência ao RFC-952. Foi minha experiência que, embora os RFCs sejam solicitações, elas se tornam definições quando são aceitas.
Isaac

@ Farseeker, não estou dizendo que é o caso aqui, mas sempre fico surpreso com as pessoas, a maioria das quais deveria saber melhor, que citam RFCs como se fossem a autoridade máxima sobre qualquer assunto em particular. Tenho certeza de que existe uma RFC em algum lugar. ;)
John Gardeniers

1
Na verdade, algumas RFCs são padrões - as RFCs 1034 e 1035 juntas, por exemplo, compreendem STD0013. O motivo pelo qual eles são chamados de "Solicitações de Comentários" é histórico e, em essência, tinha a ver com um monte de pós-graduandos de baixa qualidade no final dos anos 60, que não queriam deixar seus superiores (eu ouvi isso diretamente do autor da RFC 1).
Alnitak

2
@ John, sugiro a leitura da RFC 2026. "Uma especificação que atinge o status de Padrão recebe um número na série STD, mantendo seu número RFC". Escrevo documentos IETF para o meu trabalho diário.
Alnitak

1

Eu acho que os nomes de host atuais são mais dependentes das especificações de DNS, já que o DNS é o que a maioria das pessoas usará dentro de uma rede ou na Internet. Dito isso, três RFCs vêm à mente (1034 - conceitos, 1035 - implementação e 2181 - esclarecimentos sobre o DNS).

A seção 3 da RFC 1034 diz:

O espaço para nome de domínio é uma estrutura em árvore. Cada nó e folha na árvore corresponde a um conjunto de recursos (que pode estar vazio). O sistema de domínio não faz distinções entre os usos dos nós e folhas internos, e esse memorando usa o termo "nó" para se referir a ambos.

Cada nó tem um rótulo com zero a 63 octetos de comprimento. Os nós da Brother podem não ter o mesmo rótulo, embora o mesmo rótulo possa ser usado para nós que não são irmãos. Um rótulo é reservado e esse é o rótulo nulo (ou seja, comprimento zero) usado para a raiz.

E na seção 11 da RFC 2181 , temos um esclarecimento sobre como nomear cada nó do endereço:

O próprio DNS coloca apenas uma restrição nos rótulos específicos
que podem ser usados ​​para identificar registros de recursos. Essa restrição está
relacionada ao comprimento do rótulo e ao nome completo. O comprimento de qualquer rótulo é limitado a entre 1 e 63 octetos. Um nome de domínio completo é limitado a 255 octetos (incluindo os separadores)

Portanto, à luz das especificações do DNS, você pode ter um a.domain.tld


A partir do próximo parágrafo da Seção 11 da RFC-2181: Note however, that the various applications that make use of DNS data can have restrictions imposed on what particular values are acceptable in their environment. For example, that any binary label can have an MX record does not imply that any binary name can be used as the host part of an e-mail address. Basicamente, porque a.domain.tld é válido no DNS não o torna um nome de host válido. O final da Seção 11 faz referência à Seção 6.1.3.5 da RFC-1123, que cita a Seção 2.1 em si e a RFC-952, conforme discutido na resposta do sysadmin1138.
Isaac

A citação no final da seção 6.1.3.5 fala sobre menos restrições na convenção de nomenclatura definida em 952. Além disso, o 952 define uma tabela de host DOD e não estou totalmente convencido de que seja mais relevante do que as especificações de DNS.
Coredump

Penso que a liberalização das restrições mencionadas no final do 6.1.3.5 se refere apenas a permitir que o primeiro caractere seja um número - esta é a única modificação mencionada na seção 2.1 da mesma RFC (que é a seção na qual 6.1. 3.5 refere-se). É nessa seção 2.1 que a definição do RFC-952 é referenciada como sendo a definição de um nome de host legal.
Isaac

Verifique também o RFC 920 e 921, que trata da migração do antigo DARPA para nomes de domínio.
Coredump

1

Como você determinou, o RFC 1123 não está completamente claro sobre esse problema.

A seção 2.1 diz:

Host software deve lidar com nomes de host de até 63 caracteres e deve lidar com nomes de host de até 255 caracteres

Como esse texto efetivamente substitui completamente o texto do RFC 952, também deve ser considerado que qualquer comprimento de até 255 caracteres é legal.

Infelizmente, em 1989, o Internet Drafts não recebeu a revisão incrivelmente rigorosa que eles recebem agora, então a ambiguidade provavelmente não foi identificada.


1
Mas o 2.1 também diz The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. : Não é razoável interpretar isso para significar que sua citação não substitui completamente o texto do RFC-952?
Isaac

Diz isso, mas está claramente errado. O RFC 1123 também altera explicitamente o comprimento permitido de um nome de host.
Alnitak
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.