_ (Sublinhado) é ilegal em um registro CNAME?

9

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?

domain-name-system opendkim

— Lenne
fonte

1

O provedor está corrigindo a interface da web enquanto escrevo isso!

— Lenne

18

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

— Sven
fonte

Mas um CNAME é um nome de host? Algumas documentações mostram o uso de sublinhado em um cname, portanto, aparentemente ele funciona. kb.mailchimp.com/accounts/email-authentication/…

— Lenne

Além disso, os sublinhados aparecem nas entradas DNS nas zonas integradas ao MS Windows Active Directory que subjazem aos domínios do Windows, pelo menos na ferramenta de gerenciamento de DNS da Microsoft, mas não tenho certeza se esses sublinhados realmente fazem parte do nome e o Windows suporta sublinhados no DNS solicitações ou se os sublinhados aparecerem apenas no snap-in de gerenciamento de DNS e, na verdade, não fazem parte dos nomes.

— 21417 Todd Wilcox

Observe que a entrada da Wikipedia citada tem a ver com nomes da Internet e não com DNS.

— Jim B

@ Lenne: Um CNAME é um nome de host válido porque é um alias para um host. @ToddWilcox: sim, isso é conhecido e é uma violação (deliberada?) Das especificações da MS que causou a outros sistemas nenhuma quantidade de problemas, pois eles aparecem nos pacotes DNS, DHCP, ... apesar de não serem legais.

— mirabilos

2

@mirabilos "Um CNAME é um nome de host válido" não, o destino (RDATA) de um CNAME é um nome de domínio, não um nome de host (um nome de domínio é um superconjunto de todos os nomes de host possíveis). _foo CNAME _baré completamente legítimo, você pode testar named-checkzone.

— Patrick Mevzek

2

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ê.

— Jim B
fonte

"Qualquer caractere válido é permitido no DNS" é um pouco mais complicado que isso. Existem nomes de domínio e nomes de host. Exceto se dito o contrário, em todos os lugares você tem rótulos que são nomes de domínio, o que significa de fato qualquer caractere, _ou qualquer outra coisa que você queira. Mas, para alguns registros, você pode usar apenas nomes de host e não nomes de domínio. Nomes de host são apenas letras, dígitos e hífens, nada mais. Por exemplo, o proprietário de um Aou AAAAregistro é um nome de host, não um nome de domínio. O RDATA (destino) de um NSregistro também é um nome de host, não um nome de domínio.

— Patrick Mevzek

1

"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." Desde quando os RRs MX fazem referência a endereços de email?

— um CVn

0

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.

— micmav
fonte

Também tenho problemas com o Arduino, onde algumas bibliotecas fornecem um nome de host como ESP_245537, esse nome é rejeitado quando o servidor DHCP tenta atualizar o DNS.

— Lenne

Isto está errado. O rótulo de um CNAME não é necessariamente um nome de host, portanto, todos os caracteres são válidos aqui, incluindo o _.

— Patrick Mevzek

1

E mesmo sem isso, essas são as regras antigas. Eles estavam proibindo nomes de host começando com um dígito, mas para acomodar, 3com.compor exemplo, esta regra, foi relaxada, consulte tools.ietf.org/html/rfc1123#page-13 "Um aspecto da sintaxe do nome do host é alterado: a restrição do primeiro caractere é relaxado para permitir uma letra ou um dígito ".

— Patrick Mevzek

@Lenne se esp_245537for usado como um nome de host, a atualização do DNS deverá ser recusada, pois não é um nome de host válido. Se isso for usado como nome de domínio, a atualização do DNS deverá ser bem-sucedida (caso contrário, é um bug), porque é um rótulo DNS válido.

— Patrick Mevzek

Eu já vi dicas de que é possível converter caracteres inválidos do DHCP para o DNS, mas nunca consegui funcionar.

— 27418 Lenne

0

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)

— Patrick Mevzek
fonte