Forza le richieste DNS del server d'inoltro in modalità TCP

Ho impostato un server DNS su SLES10 (attualmente associare 9.6) su un server multihomed. Questo server può essere interrogato da tutte le reti interne e fornisce risposte per tutte le reti interne. Abbiamo due zone "master" DNS separate. Ognuna di queste zone è servita da un numero di server DNS-Windows autorevoli.

Ora il mio server Linux è un server DNS secondario per una di queste zone (zona interna privata) e funge da server d'inoltro per l'altra zona (zona interna pubblica).

Fino a poco tempo fa questa configurazione funzionava senza problemi. Ora ricevo - dopo aver interrogato la zona interna pubblica (ad es. Tramite il hostcomando su un client Linux) il messaggio di errore

;; Troncato, nuovo tentativo in modalità TCP

un dump di wirehark ha rivelato la causa di ciò: la prima query esce in modalità UDP, la risposta non rientra in UDP (a causa dell'elenco lungo di NS autorevole), quindi viene ritentata in modalità TCP, fornendo la risposta giusta.

Ora la domanda: posso configurare il mio bind per interrogare i server d'inoltro in modalità TCP senza prima provare UDP?

Aggiornamento: provando la mia mano su ASCII-art ...

+--------------+   +--------------+   +-----------------+
| W2K8R2 DNS   |   | SLES 10 DNS  |   | W2K8R2 DNS      |
| Zone private +---+ All internal +---+ Zone public     |
| internal 2x  |   |   Zones      |   | internal 30+ x  |
+--------------+   +-+----------+-+   +-----------------+
                     |          |
                  +--+---+   +--+---+
                  |Client|   |Client|
                  +------+   +------+

— Nils
fonte

un piccolo diagramma di questo sarebbe utile - sto lottando per capire quale server è quale dalla tua descrizione.

— Alnitak,

un po 'meglio, anche se non è ancora chiaro tra esattamente quali host stai eseguendo questo hostcomando e quale query viene inviata.

— Alnitak,

I clienti richiedono tramite SLES10 le voci dalla zona pubblica interna. La zona privata interna non ne risente - in quanto vi sono solo 2 voci NS.

— Nils,

e i client sono semplicemente risolutori di stub?

— Alnitak,

ti suggerisco di aggiungere minimal-responses: yesalla configurazione BIND su SLES 10 - potrebbe ridurre le dimensioni della risposta. In ogni caso, le query più normali non supereranno il limite di 512 byte.

— Alnitak,

Risposte:

Innanzitutto, non lo definirei un errore, ma solo un messaggio informativo.

In secondo luogo, i server DNS risponderanno sempre alle query UDP (almeno BIND, non riesco a trovare le opzioni per disabilitare UDP) e i client proveranno sempre (?) A inviare prima una query UDP (ad esempio non ci sono opzioni in resolv.conf per cambiarlo né nella JVM) - se rientrano in un pacchetto UDP (le richieste normalmente lo fanno)

Se hai un caso d'uso specifico, puoi specificare di usare TCP, ad esempio nello script di shell usa 'dig + tcp' o 'host -T' per la risoluzione, e puoi usare le chiamate di sistema 'sethostent / gethostbyname / endhostent' (vedi man pagina) per forzare TCP in altri casi.

Se vuoi davvero provare a bloccare UDP, l'unica opzione che posso vedere è con una regola iptable, ma non sono sicuro che quell'impostazione funzionerebbe. Mi aspetto che la risoluzione DNS fallisca semplicemente.

— Dan Andreatta
fonte

c'è un vantaggio prestazionale dal sapere a priori che la query UDP fallirà e provare prima su TCP. Vedi RFC 5966 per qualche discussione al riguardo.

— Alnitak,

@Alnitak e vorrei ottenere questo vantaggio.

— Nils,

@Nils quindi dobbiamo capire perché apparentemente EDNS non funziona ...

— Alnitak

Non ho un caso d'uso speciale - i client useranno la loro libreria di resolver - ma ogni richiesta e ogni risposta andranno sulla rete due volte - non mi piace.

— Nils,

@Nils, il problema è che il client decide UDP / TCP, ma il server conosceva la dimensione della risposta.

— Dan Andreatta,

Il tuo server BIND dovrebbe utilizzare EDNS (vedi RFC 2671) per consentire pacchetti UDP più lunghi di 512 byte.

options {
    edns-udp-size 4096;
    max-udp-size 4096;
};

Ciò dovrebbe consentire il recupero del set NS di grandi dimensioni su UDP, senza richiedere l'overhead di una connessione TCP per altre query più piccole.

Si noti tuttavia che questi sono in realtà i valori predefiniti. Se EDNS non viene utilizzato, o qualcosa lo sta bloccando o i server che ricevono le opzioni EDNS non lo supportano.

Inoltre, si noti che hostnon supporta EDNS. È perfettamente possibile che il server di inoltro -> le query del server stiano già utilizzando EDNS e non riesci a vederlo quando provi con il tuo client locale.

Prova dig +bufsize=4096 @server hostname Ainvece di utilizzare host.

— Alnitak
fonte

Chi dovrebbe usarlo? Probabilmente sia il mio server che i miei server di inoltro dalla zona "pubblica interna"?

— Nils,

Qual è il senso di inviare comunque l'elenco completo di NS nella risposta?

— Nils,

@Nils il protocollo DNS richiede che l'insieme completo di voci corrispondenti alla stessa tupla (QNAME, QTYPE e QCLASS) sia indivisibile (aka un "RRset")

— Alnitak,

puoi indicarmi la RFC riguardo questo RRset?

— Nils,

L'host Actaully utilizza la libreria di resolver standard e sulla mia workstation supporta EDNS0. Per verificare se le richieste specificano EDNS0, eseguire 'tcpdump -x port 53' e il dump esadecimale deve contenere (verso la fine, nella sezione aggiuntiva) la sequenza 0029 1000 0000 8000 0000, che è la rappresentazione binaria dell'OPT RR.

— Dan Andreatta,