Record SRV pubblicati che indicano l'alias CNAME in violazione di RFC 2782?

Nel corso di alcune responsabilità lavorative ho bisogno di approfondire i record SRV e sto cercando di conciliare un'istruzione Wikipedia con ciò che vedo negli scavi DNS.

Secondo la voce del record SRV di Wikipedia ,

la destinazione nei record SRV deve puntare al nome host con un record di indirizzo (record A o AAAA). Puntare a un nome host con un record CNAME non è una configurazione valida.

ma vedo i record in cui digrestituisce un record SRV che punta a un nome che è l'alias in un record CNAME.

Cioè, qualcosa del genere:

> dig _https._tcp.alpha.domain.com SRV

;; QUESTION SECTION:
;_https._tcp.alpha.domain.com.    IN    SRV

;; ANSWER SECTION:
_https._tcp.alpha.domain.com 59 IN SRV 30 30 4443 alias.domain.com


> dig alias.domain.com

;; QUESTION SECTION:
;alias.domain.com.    IN    A

;; ANSWER SECTION:
alias.domain.com.  35  IN  CNAME canonical.name.amazonaws.com.
canonical.name.amazonaws.com. 35 IN A 52.78.234.189
canonical.name.amazonaws.com. 35 IN A 107.21.179.88
canonical.name.amazonaws.com. 35 IN A 52.12.126.92

Sembra che il record SRV sia configurato esattamente come la voce di Wikipedia dice non è consentita. Cosa sto fraintendendo? Non sta mostrando che il record SRV punta su alias.domain.com, che ha un record CNAME, non un record di indirizzo?

domain-name-system cname-record srv-record

— Scott
fonte

nella mia azienda usiamo molto i record SRV, e molti di loro usano CNAME e funziona bene, quindi contro le regole o no, funziona bene :)

— olivierg

Risposte:

L'articolo di Wikipedia che stai citando riporta ciò che la RFC 2782 pertinente per i record SRV afferma:

Bersaglio

Il nome di dominio dell'host di destinazione. DEVONO esserci uno o più record di indirizzi per questo nome, il nome NON DEVE essere un alias (nel senso di RFC 1034 o RFC 2181).

Quello che vedi è una chiara violazione delle regole; tuttavia, potrebbe funzionare (e di solito funziona), se qualunque applicazione client cerchi quel record SRV è abbastanza intelligente da gestire correttamente un record CNAME, anche se dovrebbe aspettarsi solo un record A nella risposta.

Ma potrebbe anche non funzionare affatto: non è supportato e dipende completamente dall'applicazione client; quindi dovrebbe essere evitato, perché non sta seguendo le regole appropriate e potrebbe portare a risultati errati e / o imprevedibili.

Questo è simile al puntamento di un record MX a un CNAME, che è definito come errato non solo in uno , ma due RFC, eppure è una pratica abbastanza comune (e nessun server di posta sembra avere un problema con esso).

— Massimo
fonte

Tieni presente che "abbastanza intelligente" è relativo. Alcuni progettisti di software sono convinti che sopportare implementazioni Braindead incoraggia solo più implementazioni dello stesso. RFC 2781 è stato aggiornato da un solo RFC e la lingua su cosa aspettarsi è molto ferma, quindi non mi aspetterei molta misericordia qui.

— Andrew B,

La maggior parte delle applicazioni client si basano solo sulle librerie di sistema per eseguire query DNS, e la maggior parte delle librerie (specialmente in linguaggi di livello superiore) farà del proprio meglio per risolvere qualsiasi query lanciata e seguirà felicemente e silenziosamente un CNAME fino alla sua destinazione. Indirizzo IP.

— Massimo

L'applicazione non ha bisogno di molta intelligenza, chiederà semplicemente al sistema operativo di connettersi a "alias.domain.com" sulla porta 4443 e lasciare tutti i dettagli ad essa.

— Massimo

L'applicazione client e le librerie di sistema non avranno l'opportunità di seguire l'alias se il ricursore a monte rifiuta i dati autorevoli e rifiuta di continuare. (che è la relativa intelligenza a cui mi riferivo) La gestione dei NSrecord da parte di BIND e l'aliasing proibito è il classico esempio di questo. Indipendentemente da ciò, siamo d'accordo che è il gioco di chiunque con risultati imprevedibili.

— Andrew B,

Alcuni server di posta hanno iniziato a ignorare attivamente gli MX verso i CNAME, ad esempio GMX medienconsulting.at/…

— Marcel Waldvogel il

Questo è un esempio del comportamento limitato, sì. La stessa limitazione deriva da RFC 2781 nella definizione di "target":

   Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.  Unless and until permitted by future standards
        action, name compression is not to be used for this field.

        A Target of "." means that the service is decidedly not
        available at this domain.

Sfortunatamente, il software server DNS che consente configurazioni vietate non è una novità. Può e succede, come succede con altri tipi di record in cui sono vietati obiettivi con alias come NSe MX. (menzionato sopra)

Solo perché può essere trovato in natura non significa che sia "ok" e che cosa succede quando uno standard viene ignorato varia da prodotto a prodotto. Non ho testato l'interazione con i SRVrecord, ma una decisione progettuale molto nota di ISC BIND per quanto riguarda i NSrecord che puntano agli alias è di eliminare completamente il record se trovato durante la ricorsione. Se tutti i NSrecord vengono eliminati in questo modo, il risultato di tutte le query saràSERVFAIL per il sottodominio in questione.

In breve, attenersi allo standard. È l'unica cosa sicura da fare.

— Andrew B
fonte