RFC che richiede che i server DNS rispondano a richieste di dominio sconosciute

Il mio registrar di domini e DNS forniscono attualmente ignora le richieste DNS a domini sconosciuti. Per ignorare intendo buchi neri e non risponde mai, il che fa sì che i miei client DNS e le librerie del resolver riprovino, eseguano il back-off e infine il timeout.

dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org
...
;; connection timed out; no servers could be reached

Nel sondare altri servizi di nomi di dominio popolari, vedo che questo comportamento è piuttosto unico poiché altri provider restituiscono un RCODE di 5 (RIFIUTATO):

dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org
dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org
dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org

Tutti restituiscono qualcosa di simile al seguente:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732

o

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219

Restituire REFUSEDo NXDOMAINimmediatamente è appropriato IMHO invece di far cadere la richiesta sul piano della sala server.

Quando mi lamento con il mio fornitore del fatto che i loro server non rispondano, mi chiedono di citare la RFC che i loro server stanno violando. So che è strano che mi stiano chiedendo di dimostrare che i loro server dovrebbero rispondere a tutte le richieste, ma così sia.

Domande :

• Sono d'accordo che, a meno che non ci siano ID di richiesta duplicati o una sorta di risposta DOS, un server dovrebbe sempre rispondere alla richiesta. È corretto?
• Quale RFC e sezione specifica dovrei citare per supportare la mia stipulazione?

Per me, è male non rispondere a una query DNS. La maggior parte dei client esegue il backoff e quindi ritrasmette la stessa query allo stesso server DNS o a un altro server. Non solo rallentano i client, ma fanno sì che la stessa query venga ripetuta dai propri server o da altri server a seconda dei server dei nomi autorevoli e delle voci NS.

In RFC 1536 e 2308 vedo molte informazioni sulla memorizzazione nella cache negativa per motivi di prestazioni e per interrompere la ritrasmissione della stessa query. Nel 4074 vedo informazioni sulla restituzione di una risposta vuota con un RCODE di 0, quindi il client sa che non ci sono informazioni ipv6 che dovrebbero indurre il cliente a chiedere informazioni sui RR che sono un altro esempio di risposta vuota.

Ma non riesco a trovare un RFC che dice che un server DNS dovrebbe rispondere a una richiesta, probabilmente perché è implicito.

Il problema specifico si verifica quando migra il mio dominio (e i record DNS associati) sui loro server o i primi X minuti dopo aver registrato un nuovo dominio con il loro servizio. C'è un ritardo tra il momento in cui i server dei nomi autorevoli cambiano (che è abbastanza dannatamente veloce in questi giorni) e i loro server che iniziano a pubblicare i miei record DNS. Durante questo periodo di ritardo, i client DNS pensano che i loro server siano autorevoli ma non rispondono mai a una richiesta, anche con a REFUSED. Capisco il ritardo che va bene ma non sono d'accordo con la decisione di non rispondere alle richieste DNS. Per la cronaca, capisco come aggirare queste limitazioni nel loro sistema, ma sto ancora lavorando con loro per migliorare i loro servizi per essere più in linea con il protocollo DNS.

Grazie per l'aiuto.

Modificare:

Entro un paio di mesi dalla pubblicazione di questo e dal seguito con il mio provider, hanno cambiato i loro server per tornare NXDOMAINper domini sconosciuti.

Il consiglio di Shane è corretto. La mancata migrazione dei dati da un server autorevole a un altro prima di avviare un ritaglio è un invito a un'interruzione. Indipendentemente da ciò che accade da quel momento in poi, si tratta di un'interruzione avviata dalla persona che ha oscillato i record NS. Questo spiega perché più persone non stanno presentando questo reclamo al tuo fornitore.

Detto questo, questa è ancora una domanda interessante a cui rispondere, quindi ho intenzione di prenderla.

Le funzionalità di base dei server DNS sono coperte dai documenti RFC 1034 e RFC 1035 , che formano collettivamente STD 13 . La risposta deve provenire da questi due RFC o essere chiarita da un RFC successivo che lo aggiorna.

Prima di continuare, c'è un enorme insulto qui al di fuori dell'ambito del DNS che deve essere richiamato: entrambi questi RFC sono precedenti a BCP 14 (1997), il documento che ha chiarito la lingua di MAGGIO, DEVE, DOVREBBE, ecc.

• Gli standard che sono stati elaborati prima che questa lingua fosse formalizzata POTREBBERO usare un linguaggio chiaro, ma in diversi casi non lo hanno fatto. Ciò ha portato a divergenti implementazioni di software, confusione di massa, ecc.
• Purtroppo STD 13 è colpevole di essere interpretativo in diverse aree. Se la lingua non è solida su un'area di intervento, è spesso necessario trovare un RFC chiarificatore.

Detto questo, cominciamo con ciò che RFC 1034 §4.3.1 ha da dire:

• La modalità più semplice per il server non è ricorsiva, poiché può rispondere alle query utilizzando solo informazioni locali: la risposta contiene un errore, la risposta o un riferimento ad un altro server "più vicino" alla risposta. Tutti i server dei nomi devono implementare query non ricorsive.

...

Se il servizio ricorsivo non è richiesto o non è disponibile, la risposta non ricorsiva sarà una delle seguenti:

• Un errore di nome autorevole che indica che il nome non esiste.

• Un'indicazione di errore temporanea.

• Una combinazione di:

  RR che rispondono alla domanda, insieme a un'indicazione se i dati provengono da una zona o sono memorizzati nella cache.

  Un riferimento ai server dei nomi che hanno zone più vicine al nome rispetto al server che invia la risposta.

• RR che il server dei nomi ritiene possano rivelarsi utili al richiedente.

La lingua qui è ragionevolmente ferma. Non c'è "dovrebbe essere", ma un "sarà". Ciò significa che il risultato finale deve essere 1) definito nell'elenco precedente o 2) consentito da un documento successivo sulla traccia standard che modifica la funzionalità. Non sono a conoscenza di una tale verbosità esistente per ignorare la richiesta e direi che spetta allo sviluppatore trovare il linguaggio che confuta la ricerca.

Dato il ruolo frequente del DNS negli scenari di abuso di rete, non bisogna dire che il software del server DNS non fornisce le manopole per eliminare selettivamente il traffico sul pavimento, il che sarebbe tecnicamente una violazione di questo. Detto questo, questi non sono comportamenti predefiniti o con valori predefiniti molto conservativi; esempi di entrambi potrebbero essere l'utente che richiede al software di rilasciare un nome specifico ( rpz-drop.) o che vengano superate determinate soglie numeriche (BIND max-clients-per-query). Nella mia esperienza è quasi sconosciuto che il software modifichi completamente il comportamento predefinito per tutti i pacchetti in un modo che viola lo standard, a meno che l'opzione non aumenti la tolleranza per i prodotti più vecchi che violano uno standard. Questo non è il caso qui.

In breve, questo RFC può e viene violato a discrezione degli operatori, ma di solito ciò avviene con una certa precisione. È estremamente insolito ignorare completamente le sezioni dello standard come è conveniente, specialmente quando il consenso professionale (esempio: BCP 16 §3.3 ) erroneamente a favore del fatto che sia indesiderabile generare un carico non necessario sul sistema DNS nel suo insieme. Tentativi non necessari di eliminare tutte le richieste per le quali non sono presenti dati autorevoli è meno desiderabile in considerazione di ciò.

Aggiornare:

Considerando che non è desiderabile abbandonare le domande sul pavimento, naturalmente, @Alnitak ha condiviso con noi che al momento esiste un Draft BCP che tratta questo argomento in dettaglio. È un po 'prematuro usarlo come citazione, ma aiuta a rafforzare il consenso della comunità in linea con ciò che viene espresso qui. In particolare:

A meno che un server dei nomi non sia sotto attacco, dovrebbe rispondere a tutte le domande dirette a seguito delle seguenti delegazioni. Inoltre, il codice non dovrebbe presumere che non vi sia una delega al server anche se non è configurato per servire la zona. Delegazioni interrotte sono un evento comune nel DNS e la ricezione di query per zone per le quali il server non è configurato non indica necessariamente che il server è sotto attacco. Gli operatori della zona padre dovrebbero controllare regolarmente che i record NS deleganti siano coerenti con quelli della zona delegata e correggerli quando non lo sono [RFC1034]. Se ciò avvenisse regolarmente, le istanze di delegazioni infrante sarebbero molto più basse.

Questa risposta verrà aggiornata quando lo stato di questo documento cambia.

Quando sposti un DNS autorevole per un dominio su un nuovo provider, dovresti sempre (sempre!) Testare esplicitamente il nuovo provider (e assicurarti che inviino record precisi e configurati) prima di modificare le informazioni sulla registrazione del tuo dominio (whois) per puntare ai nuovi server DNS autorevoli.

All'incirca, i passi che farai:

1. Imposta tutto sul nuovo provider DNS. È necessario creare e popolare tutte le zone.

2. Assicurarsi che i nuovi server autorevoli funzionino correttamente. Interrogali esplicitamente:

   dig @new-ns.example.com mydomain.com
   

   Come sembra, dalla tua domanda, è che non stanno rispondendo a queste domande? Ma, hai detto "domini sconosciuti" che non dovrebbe essere a questo punto, dovrebbe essere completamente configurato nel loro sistema (e rispondere con i record che hai configurato).

   Ma, se avete già configurato il dominio nel loro sistema, deve essere la risposta con i record corretti a questo punto. In caso contrario, non stanno ospitando correttamente la zona e dovresti urlare contro di loro; se risponde o meno a un dominio che non ha configurato dovrebbe essere irrilevante. (Se in qualche modo mi manca ancora quello che stai dicendo, per favore fammi sapere).

3. Cambia server di nomi autorevoli con il tuo registrar di dominio (whois), lasciando il vecchio provider DNS attivo e funzionante fino a quando il traffico non lo colpisce più (dagli almeno 24 ore).

Se il nuovo provider non può assolutamente compilare i record prima di effettuare il passaggio, il modo in cui rispondono non ha davvero importanza: indirizzare gli utenti a un autore che rifiuta completamente la query comporterà tempi di inattività per il tuo dominio esattamente come se fossi non ottenere alcuna risposta.