_ (Trattino basso) è illegale in un record CNAME?

9

Stiamo riscontrando problemi nella creazione del record TXT lungo per la chiave DKIM sull'interfaccia Web del nostro hoster.

Ogni riga può accettare solo 256 caratteri.

Abbiamo provato più righe, quindi abbiamo provato ad aggiungere ("prima e ")dopo l'ultimo, come alcuni suggeriscono. Né funziona.

Poi abbiamo provato a fare un CNAME a un record su un altro hoster, dove noi possiamo fare i record DKIM TXT.

Ma ora l'interfaccia web si lamenta del nome illegale nel CNAMEdocumento.

mail._domainkey.example.com TXTva bene
mail._domainkey.example.com CNAMEnon va bene
mail.domainkey.example.com CNAMEva bene, ma non quello che vogliamo.

L'interfaccia web è determinata a farci impazzire o è davvero "illegale" avere caratteri di sottolineatura CNAME?

domain-name-system opendkim

— Lenne
fonte

1

Il provider sta riparando l'interfaccia web mentre scrivo questo!

— Lenne

18

Sì, i nomi DNS (incluso anche A / AAAA) possono contenere solo [0-9], [a-z], -, quindi il carattere di sottolineatura non è valido. Si noti che un record TXT non è un nome host e questa limitazione non è applicabile. E un'ultima modifica: -non può essere utilizzato neanche come primo carattere, quindi mail.-domainkey.our.domnon sarebbe valido.

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

Modifica finale: ho parzialmente sbagliato. Quando un CNAME viene utilizzato come nome host, si applicano le restrizioni di cui sopra. Sembra che un CNAME non sia considerato un nome host nel contesto DKIM e, in tal caso, _dovrebbe essere una parte valida di una voce CNAME. Vedi /programming/13650233/underscore-in-cname-required-by-ses-not-allowed-by-registrar/26692491#26692491

— Sven
fonte

Ma un CNAME è un nome host? Alcuni documenti dimostrano di usare la sottolineatura in un cname, quindi apparentemente funziona. kb.mailchimp.com/accounts/email-authentication/…

— Lenne

Inoltre, i caratteri di sottolineatura compaiono nelle voci DNS su zone integrate in Active Directory di MS Windows che sono alla base dei domini Windows, almeno nello strumento di gestione DNS di Microsoft, ma non sono sicuro che tali caratteri di sottolineatura siano effettivamente parte del nome e Windows supporta i caratteri di sottolineatura in DNS richieste o se i caratteri di sottolineatura compaiono solo nello snap-in di gestione DNS e in realtà non fanno parte dei nomi.

— Todd Wilcox,

Nota che la voce di Wikipedia citata ha a che fare con nomi di Internet non DNS.

— Jim B,

@ Lenne: un CNAME è un nome host valido perché è un alias per un host. @ToddWilcox: sì, questo è noto, e questa è una violazione (intenzionale?) Delle specifiche da parte di MS che ha causato ad altri sistemi nessuna quantità di problemi come appaiono in DNS, DHCP, ... pacchetti nonostante non siano legali.

— mirabilos,

2

@mirabilos "Un CNAME è un nome host valido" no, la destinazione (RDATA) di un CNAME è un nome di dominio, non un nome host (un nome di dominio è un superset di tutti i possibili nomi host). _foo CNAME _barè completamente legittimo, con cui puoi provare named-checkzone.

— Patrick Mevzek,

2

Qualsiasi carattere valido è consentito nel DNS. Vedi https://tools.ietf.org/html/rfc2181#section-11

"Il DNS stesso pone una sola restrizione sulle etichette particolari che possono essere utilizzate per identificare i record di risorse. Quella restrizione si riferisce alla lunghezza dell'etichetta e al nome completo. La lunghezza di ogni etichetta è limitata da 1 a 63 ottetti. "

Il client deve convalidare i valori dei nomi, ad esempio un record MX potrebbe contenere il valore "Alice" ma dopo la ricerca quel valore dovrebbe essere rifiutato poiché "Alice" non è un indirizzo e-mail valido.

In questo caso sembra che il tuo hoster stia "convalidando" il tuo input e dovrebbero essere in grado di inserirlo manualmente per te.

— Jim B
fonte

"Qualsiasi carattere valido è consentito nel DNS" è un po 'più complicato di così. Ci sono nomi di dominio e nomi host. Tranne se detto diversamente, ovunque hai etichette che sono nomi di dominio che significano davvero qualsiasi personaggio, quindi _o qualunque altra cosa tu voglia. Ma, per alcuni record, è possibile utilizzare solo nomi host e non nomi di dominio. I nomi host sono solo lettere e trattini, nient'altro. Ad esempio, il proprietario di un record Ao AAAAè un nome host, non un nome di dominio. Anche RDATA (destinazione) di un NSrecord è un nome host, non un nome di dominio.

— Patrick Mevzek,

1

"un record MX potrebbe contenere il valore" Alice "ma dopo la ricerca quel valore dovrebbe essere rifiutato poiché" Alice "non è un indirizzo email valido." Da quando gli RR MX fanno riferimento agli indirizzi e-mail?

— un CVn

0

RFC 1034: le etichette devono seguire le regole per i nomi host ARPANET. Devono iniziare con una lettera, terminare con una lettera o una cifra e avere come caratteri interni solo lettere, cifre e trattino. Ci sono anche alcune restrizioni sulla lunghezza. Le etichette devono contenere 63 caratteri o meno.

— micmav
fonte

Ho anche problemi con Arduino, dove alcune librerie danno un nome host come ESP_245537, questo nome viene rifiutato quando il server DHCP tenta di aggiornare il DNS.

— Lenne,

Questo è sbagliato. L'etichetta di un CNAME non è necessariamente un nome host, quindi tutti i caratteri sono validi qui, incluso il _.

— Patrick Mevzek,

1

E anche senza quello, queste sono le vecchie regole. Stavano vietando i nomi host che iniziano con una cifra, ma per soddisfare3com.com ad esempio questa regola era rilassata, consultare tools.ietf.org/html/rfc1123#page-13 "Un aspetto della sintassi del nome host è modificato: la restrizione sul primo carattere è rilassato per consentire una lettera o una cifra. "

— Patrick Mevzek,

@Lenne se esp_245537viene utilizzato come nome host, l'aggiornamento DNS deve essere rifiutato poiché non è un nome host valido. Se viene utilizzato come nome di dominio, l'aggiornamento DNS dovrebbe avere esito positivo (altrimenti si tratta di un bug), poiché è un'etichetta DNS valida.

— Patrick Mevzek,

Ho visto suggerimenti che è possibile tradurre caratteri non validi da DHCP a DNS, ma non è mai riuscito a farlo funzionare.

— Lenne,

0

La risposta di @ Sven, con la modifica, è già giusta, ma solo per esprimere le cose direttamente.

TL; DR Sì il carattere di sottolineatura è valido in un CNAMErecord su entrambi i lati, leggi sotto per il perché.

RFC 1034 e altri definiscono i record in base a "nomi di dominio" che sono etichette con qualsiasi carattere, incluso _.

Ma alcuni record hanno regole più rigide per il nome del proprietario e / o i dati delle risorse (RDATA). Verrà accettato solo un nome host e in effetti le regole sono ora (in passato erano rilassate in cui un nome host non poteva iniziare con una cifra) che è possibile utilizzare qualsiasi lettera ASCII (nessuna distinzione tra maiuscole e minuscole), qualsiasi cifra ASCII e i trattini , oltre ad alcune regole di posizione extra: nessun trattino all'inizio o alla fine e nessun trattino doppio nelle posizioni 3 e 4 (a causa della "prenotazione" per gli IDN che sono nel modulo xn--che è solo il caso consentito).

Ad esempio, il nome del proprietario di Ao AAAArecord è un nome host, non un nome di dominio. Quindi test.example.com A 192.0.2.1è valido perché tutti questi non lo sono:

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

È facile testare le cose con il named-checkzoneprogramma (parte del bindsoftware nameserver ma può essere usato e installato separatamente e altri nameserver possono avere strumenti di controllo simili e probabilmente ci sono anche interfacce online per quello), basta mettere i record in un file ed eseguire su:

$ 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)

(il numero prima di INè il TTL, questo non è correlato al nostro problema qui, ma era necessario solo per passare la convalida della sintassi di un record).

Per altri record, è il contrario: perché NSnon ci sono restrizioni sul proprietario, ma restrizioni sulla "destinazione" che sono i dati. I dati possono essere solo un nome host, non un nome di dominio, poiché è necessario puntare a server dei nomi autorevoli che sono host fisici che rispondono alle query DNS.

Ora a proposito CNAME, ecco le citazioni rilevanti da RFC 1034, nella sezione 3.6:

"proprietario: qual è il nome di dominio in cui si trova la RR." il che significa per impostazione predefinita qualsiasi nome, non solo un nome host (come fonte del record CNAME)

"RDATA: che è il tipo e talvolta i dati dipendenti dalla classe che descrivono la risorsa:"

"CNAME un nome di dominio."

Quindi sia il proprietario di un CNAME(ciò che è alla sua sinistra), sia i dati delle risorse ad esso collegati, la sua destinazione / destinazione (ciò che è alla sua destra) sono nomi di dominio e non solo nomi di host. Praticamente qualsiasi personaggio, incluso l'inclusione _è consentito su entrambi i lati.

Ancora una volta, facile da testare con 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.

Nessun errore di sorta CNAME(gli altri errori sono previsti poiché nella mia zona falsa non ho inserito alcuno SOAo i NSrecord come una zona vera avrebbero)

— Patrick Mevzek
fonte