Delega della zona inversa alle sottoreti inferiori a /24 in BIND. Come funziona

Un giorno mi sono trovato di fronte al compito di dare a uno dei miei clienti il ​​diritto di modificare i record PTR della sottorete /28 a lui assegnata. Non ho l'automazione per modificare le impostazioni di BIND dall'esterno. Pertanto, ho deciso di prendere una strada diversa: delegare al cliente una parte della zona PTR della sottorete /24.

Sembrerebbe: cosa potrebbe essere più semplice? Registriamo semplicemente la sottorete come richiesto e la indirizziamo al NS desiderato, come si fa con un sottodominio. Ma no. Non è così semplice (anche se in realtà è generalmente primitivo, ma l’intuizione non aiuta), ecco perché sto scrivendo questo articolo.

Chiunque voglia capirlo da solo può leggere RFC
Chi desidera una soluzione già pronta, benvenuto in cat.

Per non far ritardare chi ama il metodo copia-incolla, pubblicherò prima la parte pratica, e poi quella teorica.

1. Pratica. Zona delegante /28

Diciamo che abbiamo una sottorete 7.8.9.0/24. Dobbiamo delegare la sottorete 7.8.9.240/28 al client DNS 7.8.7.8 (ns1.client.dominio).

Sul DNS del provider devi trovare un file che descriva la zona inversa di questa sottorete. Lascia fare 9.8.7.in-addr.arpa.
Commentiamo le voci da 240 a 255, se ce ne sono. E alla fine del file scriviamo quanto segue:

255-240  IN  NS      7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240

non dimenticare di aumentare la zona seriale e farlo

rndc reload

Questo completa la parte del fornitore. Passiamo ai DNS del client.

Per prima cosa creiamo un file /etc/bind/master/255-240.9.8.7.in-addr.arpa come segue:

$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@                       1D IN SOA       ns1.client.domain. root.client.domain. (
                        2008152607      ; serial
                        3H              ; refresh
                        15M             ; retry
                        1W              ; expiry
                        1D )            ; minimum
@                       IN NS        ns1.client.domain.
@                       IN NS        ns2.client.domain.
241                     IN PTR          test.client.domain.
242                     IN PTR          test2.client.domain.
245                     IN PTR          test5.client.domain.

E in nome.conf aggiungi una descrizione del nostro nuovo file:

zone "255-240.9.8.7.in-addr.arpa." IN {
        type master;
        file "master/255-240.9.8.7.in-addr.arpa";
};

B riavviare il processo di associazione.

/etc/init.d/named restart

Tutto. Ora puoi controllare.

#>  host 7.8.9.245 
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.

Tieni presente che non viene fornito solo il record PTR, ma anche il CNAME. E' così che dovrebbe essere. Se vi state chiedendo perché, benvenuti al prossimo capitolo.

2. Teoria. Come funziona.

È difficile configurare ed eseguire il debug di una scatola nera. È molto più semplice se capisci cosa sta succedendo dentro.

Quando deleghiamo un sottodominio in un dominio dominio, quindi scriviamo qualcosa del genere:

client.domain.	NS	ns1.client.domain.
ns1.client.domain.	A	7.8.7.8

Diciamo a tutti coloro che ce lo chiedono che non siamo responsabili di questo sito e diciamo chi è il responsabile. E tutte le richieste di cliente.dominio reindirizzare a 7.8.7.8. Durante il controllo, vediamo la seguente immagine (ometteremo ciò che il client ha lì, non importa):

# host test.client.domain
test.client.domain has address 7.8.9.241

Quelli. siamo stati informati che esiste un record A e il suo IP è 7.8.9.241. Nessuna informazione non necessaria.

Come si può fare la stessa cosa con una sottorete?

Perché il nostro server DNS è registrato nel RIPE, quindi quando richiederemo un indirizzo IP PTR dalla nostra rete, la prima richiesta sarà comunque rivolta a noi. La logica è la stessa dei domini. Ma come si inserisce una sottorete in un file di zona?

Proviamo ad inserirlo così:

255-240  IN  NS      7.8.7.8

E... il miracolo non è avvenuto. Non riceviamo alcun reindirizzamento delle richieste. Il fatto è che bind non sa nemmeno che queste voci nel file della zona inversa sono indirizzi IP e certamente non capisce la voce dell'intervallo. Per lui, questo è solo una sorta di sottodominio simbolico. Quelli. per il bind non ci sarà alcuna differenza tra "255-240"E"il nostrosupercliente". E affinché la richiesta vada dove deve andare, l'indirizzo nella richiesta dovrebbe assomigliare a questo: 241.255-240.9.8.7.in-addr.arpa. O così se utilizziamo un sottodominio di caratteri: 241.oursuperclient.9.8.7.in-addr.arpa. Questo è diverso dal solito: 241.9.8.7.in-addr.arpa.

Sarà difficile effettuare tale richiesta manualmente. E anche se funzionasse, non è ancora chiaro come applicarlo nella vita reale. Dopotutto, su richiesta 7.8.9.241 A noi risponde ancora il DNS del provider, non quello del client.

Ed è qui che entrano in gioco CNAME.

Dal lato del provider, è necessario creare un alias per tutti gli indirizzi IP della sottorete in un formato che inoltrerà la richiesta al DNS del client.

255-240  IN  NS      ns1.client.domain.
241     IN  CNAME   241.255-240
242     IN  CNAME   242.255-240
и т.д.

Questo è per i laboriosi =).

E per i più pigri, il disegno seguente è più adatto:

255-240  IN  NS      ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240

Ora richiedi informazioni a 7.8.9.241 di 241.9.8.7.in-addr.arpa sul server DNS del provider verrà convertito in 241.255-240.9.8.7.in-addr.arpa e va al client DNS.

Il lato client dovrà gestire tali richieste. Di conseguenza, creiamo una zona 255-240.9.8.7.in-addr.arpa. In esso possiamo, in linea di principio, inserire voci inverse per qualsiasi IP dell'intera sottorete /24, ma ci chiederanno solo quelle che il provider ci inoltra, quindi non potremo scherzare =).
Per illustrare, fornirò ancora una volta un esempio del contenuto di un file di zona inversa dal lato client:

$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@                       1D IN SOA       ns1.client.domain. root.client.domain. (
                        2008152607      ; serial
                        3H              ; refresh
                        15M             ; retry
                        1W              ; expiry
                        1D )            ; minimum
@                       IN NS        ns1.client.domain.
@                       IN NS        ns2.client.domain.
241                     IN PTR          test.client.domain.
242                     IN PTR          test2.client.domain.
245                     IN PTR          test5.client.domain.

È perché utilizziamo CNAME dal lato del provider e in risposta a una richiesta di dati tramite indirizzo IP riceviamo due record, non uno.

#>  host 7.8.9.245 
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.

E non dimenticare di configurare correttamente l'ACL. Perché non ha senso prendersi una zona PTR per sé e non rispondere a nessuno dall'esterno =).

Fonte: habr.com

Aggiungi un commento