_ (Sublinhado) é ilegal em um registro CNAME?

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

Cada linha pode aceitar apenas 256 caracteres.

Tentamos várias linhas e, em seguida, tentamos adicionar ("no início e ")no final, como sugerem alguns. Nem funciona.

Em seguida, tentámos fazer um cname para um recorde em outra hoster, onde pode fazer os registros DKIM TXT.

Mas agora a interface da web reclama de nome ilegal no CNAMEregistro.

mail._domainkey.example.com TXTestá ok
mail._domainkey.example.com CNAMEnão está ok
mail.domainkey.example.com CNAMEestá ok, mas não o que queremos.

A interface da web está determinada a nos deixar loucos ou é realmente "ilegal" ter sublinhados CNAME?

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; portanto mail.-domainkey.our.dom, não seria válido.

https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames

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 /programming/13650233/underscore-in-cname-required-by-ses-not-allowed-by-registrar/26692491#26692491

Quaisquer caracteres válidos são permitidos no DNS. Consulte https://tools.ietf.org/html/rfc2181#section-11

"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 1 a 63 octetos. "

O cliente deve validar os valores dos nomes, por exemplo, 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 email válido.

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

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

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

TL; DR, sublinhado sim é válido em um CNAMEregistro de ambos os lados, leia abaixo o motivo.

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

Mas alguns registros têm regras mais rígidas para o nome do proprietário e / ou os dados do recurso (RDATA). Somente um nome de host será aceito e, de fato, as regras estão agora (elas foram relaxadas no passado em que um nome de host não pôde ser iniciado com um dígito) que você pode usar qualquer letra ASCII (sem distinção entre maiúsculas e minúsculas), quaisquer dígitos ASCII e os hífens , além de algumas regras de posição extras: nenhum hífen no início ou no final e nenhum hífen duplo nas posições 3 e 4 (por causa da "reserva" para IDNs que possuem a forma xn--que é apenas permitida).

Por exemplo, o nome do proprietário de um Aou AAAAregistro é um nome de host, não um nome de domínio. Portanto, 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 as coisas com o named-checkzoneprograma (parte do bindsoftware do servidor de nomes, mas pode ser usado e instalado separadamente e outros servidores de nomes podem ter ferramentas de verificação semelhantes e provavelmente existem interfaces online para isso também), basta colocar os registros em um arquivo e executar 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 anterior a INé o TTL, isso não está relacionado ao nosso problema aqui, mas é necessário apenas para passar na validação da sintaxe de um registro).

Para outros registros, é o contrário: pois NSnão há restrições para o proprietário, mas restrições para o "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 servidores de nomes autoritativos que são hosts físicos que respondem a consultas DNS.

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

"owner: qual é o nome do domínio em que o RR é encontrado." o que significa, por padrão, qualquer nome, não apenas um nome de host (como fonte do registro CNAME)

"RDATA: que é o tipo e, às vezes, dados dependentes da classe que descrevem o recurso:"

"CNAME um nome de domínio."

Portanto, o proprietário de um CNAME(o que está à esquerda) e os dados de recursos anexados a ele, seu destino / destino (o que está à direita) são nomes de domínio e não apenas nomes de host. Basicamente, qualquer personagem, portanto, incluir _é permitido nos dois lados.

Novamente, fácil de 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, pois na minha zona falsa eu não coloquei nenhum SOAou NSregistros como uma zona verdadeira teria)