Come funzionano i timeout DNS?

Recentemente ho avuto un problema in cui un servizio remoto che richiede 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 depositato un bug contro il loro tracker di emissione, che mi ha portto in questo path.)

Nel testare sulla mia networking locale ho potuto vedere che a volte ricevo una risposta DNS vuota dal server DNS ospitato. A quanto pare questo è intermittente perché accade solo quando i record DNS non sono nella cache ed è solo un problema quando il server DNS è veramente occupato.

Ecco una descrizione Wireshark di un messaggio di risposta vuoto:

Wireshark screenshot di risposta vuota

Naturalmente, poiché la maggior parte delle domande e risposte DNS vengono inviate su UDP, un risolutore locale aspetterà un po 'per la risposta e poi rinuncerà. Quello che mi chiedo è ora, ci sono delle linee guida per i tempi di risposta DNS? Il mio tipo di hoster DNS ha scrollato le spalle e ha detto che il mio resolver locale ha inviato la risposta vuota troppo presto. Non ho mai avuto questo problema prima, ma sono sorpreso dalla modalità di guasto – una risposta DNS vuota senza un codice di errore.

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

  • Come impostare il record SPF?
  • Docker debian slow dns risolvere
  • Problemi con inondazioni MDNS sulla port 5353 UDP
  • Mismatch DNS inversa SMTP
  • Sovrascrivere un record DNS utilizzando BIND9?
  • Imansible associarsi alla macchina Fedora 20 a Active Directory RODC con realmd
  • Domini multipli (con e senza prefisso www) sullo stesso server, eseguendo lo stesso codice
  • Perché la mia email viene da un dominio o un IP diverso?
  • 2 Solutions collect form web for “Come funzionano i timeout DNS?”

    La risposta vuota che state guardando è uno stato sintetico noto come NODATA . NODATA e NXDOMAIN indicano entrambi che il nome non esiste, ma NXDOMAIN applica a tutti i nomi anche sotto il record indicato. NODATA consiglia che questo nome sia associato a record di un tipo non richiesto o che ci siano altri record che sono inferiori a quello che stai chiedendo. (es example.test.xavamedia.nl. )

    Il tuo takeaway da NODATA e NXDOMAIN è effettivamente lo stesso in questo context: il record del nome e del tipo richiesto non esisteva. È stato raggiunto un nome server autorevole per il dominio richiesto e ha risposto indietro affermando che un record di quel nome e di un tipo non esisteva. Questo non è un errore di comunicazione. Il server autorevole ha dichiarato di non avere i dati. Più probabilmente il server con cui stavi parlando aveva già elaborato questa richiesta e negativo 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. )

    NXDOMAINNODATA da soli provocheranno un timeout quando si è verificato in questa istanza, ma la libreria del resolver probabilmente passerà da qui per aggiungere il suffisso di ricerca DNS, che può a sua volta triggersre un timeout per i server DNS autorevoli del dominio di ricerca .

    Va notato che nessuna di queste spiega perché hai incontrato una risposta SERVFAIL quando esaminate mysql.xavamedia.nl. . Questo indica un problema con il server ricorsivo che ottiene la risposta dai server autorevoli. Il server autorevole ha risposto con SERVFAIL , il server ricorsivo non è riuscito a raggiungere uno dei server autorevoli oppure il server ricorsivo ha determinato che i dati restituiti non sono validi. Nessuno di questi può essere provato con le informazioni che hai fornito.

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

    Viene specificato un valore di timeout di "non less di 5 secondi". L'RFC indica inoltre che i guasti temporanei dovrebbero essere memorizzati nella cache. Ciò impedisce una quantità eccessiva di richieste DNS se i client violano la sezione 2.2 del RFC. Tale sezione stabilisce che i clienti dovrebbero aspettare una "ragionevole" quantità di tempo tra i tentativi in ​​caso di guasti morbidi.

    C'è anche un thread Stackoverflow su questo argomento, ma non contiene molto più informazioni, ad exception di alcune osservazioni reali. https://stackoverflow.com/questions/3036054/ideal-timeout-period-for-dns-lookup

    Questo è tutto quello che posso dire su questo argomento. Se qualcun altro ha più da aggiungere, mi sarei interessato pure.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.