Come dovrebbero funzionare i timeout DNS?

Di recente ho avuto un problema a cui un servizio remoto che richiedeva l'indirizzo IP per il mio server (con un provider DNS ospitato) stava rispondendo con:

DNS problem: SERVFAIL looking up A for mysql.xavamedia.nl

(Aggiornamento: il servizio remoto menzionato qui è Let's Encrypt; ho archiviato un bug sul loro tracker dei problemi, che mi ha portato su questo percorso.)

Durante i test sulla mia rete locale, sono riuscito a vedere che a volte ricevo una risposta DNS vuota dal server DNS ospitato. Apparentemente questo è intermittente perché succede solo quando i record DNS non sono nella cache, ed è solo un problema quando il server DNS è davvero occupato.

Ecco una descrizione di Wireshark di un messaggio di risposta vuoto:

Naturalmente, poiché la maggior parte delle query e delle risposte DNS vengono inviate su UDP, un resolver locale attenderà solo qualche istante per la risposta, quindi si arrenderà. Ciò che ora mi viene da chiedersi è: ci sono linee guida per i tempi di risposta DNS? Il mio hoster DNS si strinse nelle spalle e disse che il mio resolver locale aveva inviato la risposta vuota troppo presto. Non ho mai avuto questo problema prima, ma sono sorpreso dalla modalità di errore: una risposta DNS vuota senza un codice di errore.

Qualcuno conosce alcune linee guida su come dovrebbe funzionare e quando / come posso dimostrare che il mio hosting DNS sta facendo qualcosa di sbagliato?

domain-name-system dns-hosting

— DJC
fonte

Potete aggiornare la domanda per fornire ulteriori informazioni sulla risposta vuota? Ciò può significare una serie di cose a seconda del flag impostato e dell'aspetto della sezione dell'autorità. Dovremmo vedere l'output di dig/ nslookupo una dissezione di Wireshark. ( tcpdumpnon sarà abbastanza buono) Se stai usando nslookup, esegui set debugprima.

— Andrew B,

Ho un tappo, ma non sei sicuro di come posso mostrarlo al meglio qui?

— DJ

Aprilo in Wireshark, fai clic sul pacchetto, quindi espandi le informazioni per il protocollo DNS. Espandi anche le sottocategorie, quindi pubblica uno screenshot nella tua domanda utilizzando il pulsante Inserisci immagine. È possibile ritagliare lo screenshot per le cose del protocollo DNS.

— Andrew B,

Risposte:

La risposta vuota che stai osservando è uno stato sintetico noto come NODATA. NODATAed NXDOMAINentrambi indicano che il nome non esiste, ma si NXDOMAINapplica anche a tutti i nomi al di sotto del record indicato. NODATAsta avvisando che quel nome è associato a record di un tipo non richiesto o che ci sono altri record che si trovano al di sotto di ciò che stai richiedendo. (cioè example.test.xavamedia.nl.)

Il tuo asporto da NODATAed NXDOMAINè effettivamente lo stesso in questo contesto: il record del nome e del tipo richiesti non esisteva. È stato raggiunto un server dei nomi autorevole per il dominio richiesto, che ha risposto affermando che non esisteva un record con quel nome e quel tipo. Questo non è un errore di comunicazione. Il server autorevole ha detto che non aveva i dati. Molto probabilmente il server con cui stavi parlando aveva già elaborato questa richiesta e negativo ha memorizzato nella cache l'assenza di quel record nelle ultime quattro ore. (14400 secondi è l'intervallo di cache negativo definito dal record SOA per xavamedia.nl.)

Né NXDOMAINo NODATA da soli si tradurrà in un timeout quando si incontrano in questa istanza, ma la libreria del resolver probabilmente passerà da qui ad aggiungere il suffisso di ricerca DNS, che a sua volta potrebbe innescare un timeout per i server DNS autorevoli del dominio di ricerca.

Va notato che nulla di tutto ciò spiega perché hai riscontrato una SERVFAILrisposta quando guardavi in alto mysql.xavamedia.nl.. Ciò indica un problema con il server ricorsivo che ottiene la risposta dai server autorevoli. O il server autorevole ha risposto SERVFAIL, il server ricorsivo non è riuscito a raggiungere nessuno dei server autorevoli oppure il server ricorsivo ha stabilito che i dati restituiti non erano validi. Niente di tutto ciò può essere dimostrato con le informazioni che hai fornito.

— Andrew B
fonte

Grazie per la tua risposta dettagliata! Alcune cose non sono ancora chiare: se la risposta NODATA è stata avviata dal server autorevole in qualche modo, il mio hosting DNS ha un problema, perché questi domini esistevano da molto tempo (in virtù di un record jolly A). Quindi la mia altra domanda è: come potrei provare se il server autorevole ha fatto qualcosa di sbagliato?

— DJ

La NODATAcattura nel pacchetto è la prova. La domanda pertinente è "perché un server autorevole ha risposto e ha affermato che tale record non esisteva?" . Sfortunatamente è un problema difficile da premere a meno che non sia possibile dimostrarlo con ricerche dirette contro i server autorevoli (rimuovendo la capacità di scrollare le spalle e incolpare gli operatori dei server ricorsivi), tenendo presente che solo uno dei tre può occasionalmente comportarsi male.

— Andrew B,

NODATAsignifica il nome fa esistere, ma non dispone di un record del tipo richiesto. Ad esempio, chiedi un Arecord, ma ha solo un MXrecord. Potrebbe anche accadere se il nome è per un nodo intermedio nella gerarchia DNS e non ha record propri.

— Barmar,

@Barmar Sì, ciò che viene detto qui è che il server autorevole sta segnalando un'assenza di quel nome record + coppia di tipi, e djc sta esprimendo confusione su questo a causa di un record jolly che è presente da tempo.

— Andrew B,

Il mio commento è indirizzato al primo punto "NODATA e NXDOMAIN indicano entrambi che il nome non esiste". NXDOMAINsignifica che il nome non esiste, NODATAsignifica che il nome esiste ma il tipo di record richiesto non esiste.

— Barmar,

Non conosco linee guida specifiche ad eccezione di quelle definite nella sezione "6.1.3.3 Uso efficiente delle risorse" di RFC 1123 http://tools.ietf.org/rfcmarkup?rfc=1123#page-77

È stato specificato un valore di timeout di "non meno di 5 secondi". La RFC afferma inoltre che gli errori temporanei devono essere memorizzati nella cache. Questo per evitare l'eccessiva quantità di richieste DNS se i client violano la sezione 2.2 della RFC. In questa sezione si afferma che i client dovrebbero attendere un periodo "ragionevole" di tempo tra i tentativi in caso di guasti lievi.

C'è anche un thread StackOverflow su questo argomento, ma non contiene molte più informazioni tranne alcune osservazioni del mondo reale. /programming/3036054/ideal-timeout-period-for-dns-lookup

Questo è tutto ciò che posso dire su questo argomento. Se qualcun altro ha altro da aggiungere, sarei anche interessato.

— Janek Bevendorff
fonte