O _ (sublinhado) é ilegal em um registro CNAME?

Question

Estamos com problemas para criar o longo registro TXT para a chave DKIM na interface da Web em nosso hoster.

Cada linha só aceita 256 caracteres.

Nós tentamos várias linhas, depois tentamos adicionar (" no primeiro e ") após o último, como alguns sugerem. Nem funciona.

Então tentamos fazer um cname para um registro em outro hoster, onde podemos fazer os registros DKIM TXT.

Mas agora a interface web reclama de nome ilegal no registro CNAME .

mail._domainkey.example.com TXT está ok
mail._domainkey.example.com CNAME não está ok
mail.domainkey.example.com CNAME está ok, mas não o que queremos.

A webinterface está determinada a enlouquecer ou é realmente "ilegal" ter sublinhados em CNAME ?

    

Answer 1

Sim, os nomes DNS (isso também inclui A / AAAA) podem conter apenas [0-9], [a-z], - , portanto, o sublinhado não é válido. Observe que um registro TXT não é um nome de host e essa restrição não se aplica a ele. E uma última edição: - também não pode ser usado como o primeiro caractere, então mail.-domainkey.our.dom não seria válido.

link

Edição final: eu estava parcialmente errado. Quando um CNAME é usado como um nome de host, as restrições acima se aplicam. Parece que um CNAME não é considerado um nome de host no contexto DKIM e, nesse caso, _ deve ser uma parte válida de uma entrada CNAME. Consulte o link

    

Answer 2

Quaisquer caracteres válidos são permitidos no DNS. Consulte o link

"O próprio DNS coloca apenas uma restrição nos rótulos específicos    que pode ser usado para identificar registros de recursos. Essa restrição    refere-se ao comprimento do rótulo e ao nome completo. O comprimento do    qualquer um rótulo é limitado a entre 1 e 63 octetos. "

O cliente deve validar os valores de nome, EG, um registro MX pode conter o valor "Alice", mas após a pesquisa, esse valor deve ser rejeitado, pois "Alice" não é um endereço de e-mail válido.

Nesse caso, parece que seu hoster está "validando" sua entrada e deve poder inseri-la manualmente para você.

    

Answer 3

RFC 1034: Os rótulos devem seguir as regras para o host ARPANET nomes. Eles devem começar com uma carta, terminar com uma letra ou dígito e tem como caracteres interiores apenas letras, dígitos e hífen. tem também algumas restrições no comprimento. Os rótulos devem ter 63 caracteres ou menos.

    

Answer 4

@ A resposta de Sven, com a edição, já está certa, mas apenas para expressar as coisas diretamente.

TL é válido em um registro CNAME em ambos os lados, leia abaixo o motivo.

RFC 1034 e outros definem registros baseados em "nomes de domínio", que são rótulos com qualquer caractere, incluindo _ .

Mas alguns registros possuem regras mais rigorosas para o nome do proprietário e / ou os dados do recurso (RDATA). Apenas um nome de host será aceito e, de fato, as regras são agora (elas foram relaxadas no passado onde um nome de host não pôde ser iniciado com um dígito) que você pode usar qualquer letra ASCII (sem diferenciação de maiúsculas), qualquer dígito ASCII e hífens , além de algumas regras extras de posição: sem hífen no início ou no final e sem hífens duplos nas posições 3 e 4 (por causa de "reserva" para IDNs que estão no formato xn-- , o que é apenas um caso permitido).

Por exemplo, o nome do proprietário de um registro A ou AAAA é um nome de host, não um nome de domínio. assim test.example.com A 192.0.2.1 é válido porque todos estes não são:

_test.example.com A 192.0.2.1
-test.example.com A 192.0.2.1
test-.example.com A 192.0.2.1

É fácil testar coisas com o programa named-checkzone (parte do software bind nameserver, mas pode ser usado e instalado separadamente e outros servidores de nomes podem ter ferramentas de verificação semelhantes e provavelmente também existem interfaces online para isso) , basta colocar registros em um arquivo e executá-lo em:

$ cat z1.txt
test.example.com. 1 IN A 192.0.2.1
_test.example.com. 1 IN A 192.0.2.1
-test.example.com. 1 IN A 192.0.2.1
test-.example.com. 1 IN A 192.0.2.1
$ /usr/local/sbin/named-checkzone example.com z1.txt
z1.txt:2: _test.example.com: bad owner name (check-names)
z1.txt:3: -test.example.com: bad owner name (check-names)
z1.txt:4: test-.example.com: bad owner name (check-names)

(o número antes de o IN ser o TTL, isso não está relacionado ao nosso problema aqui, mas necessário apenas para passar a validação da sintaxe de um registro).

Para outros registros, é o oposto: para NS não há restrições sobre o proprietário, mas restrições no "destino" que são os dados. Os dados podem ser apenas um nome de host, não um nome de domínio, porque você precisa apontar para os servidores de nomes autoritativos que são hosts físicos que respondem às consultas DNS.

Agora, sobre CNAME , aqui estão as citações relevantes da RFC 1034, na seção 3.6:

"owner: which is the domain name where the RR is found." which means by default any name, not just an hostname (as source of the CNAME record)

"RDATA: which is the type and sometimes class dependent data which describes the resource:"

"CNAME a domain name."

Portanto, o proprietário de um CNAME (o que está à esquerda dele) e os dados de recurso anexados a ele, seu destino / destino (o que está à direita dele) são nomes de domínio e não nomes de host só. Basicamente, qualquer caractere, portanto, incluir _ é permitido em ambos os lados.

Mais uma vez, é fácil testar com named-checkzone :

$ cat z2.txt
_foo 1 CNAME _bar
$ /usr/local/sbin/named-checkzone example.com z2.txt
zone example.com/IN: has 0 SOA records
zone example.com/IN: has no NS records
zone example.com/IN: not loaded due to errors.

Não há nenhum erro sobre o CNAME (os outros erros são esperados, já que na minha zona falsa eu não coloquei nenhum registro SOA ou NS como uma zona verdadeira teria)