Una volta mi è stato chiesto di concedere a uno dei clienti il diritto di modificare i record PTR della subnet /28 a lui assegnata. Non ho automazione per modificare le impostazioni BIND da remoto. Così ho deciso di seguire un'altra strada: delegare al cliente una parte della zona PTR della subnet /24.
Sembrerebbe che sia un'impresa semplice. Basta scrivere correttamente la subnet e indirizzarla al NS desiderato, come si fa con un sottodominio. Ma no. Non è tutto così semplice (anche se in realtà è piuttosto primitivo, ma l'intuizione non aiuterà), ed è per questo che scrivo questo articolo.
Chi desidera approfondire può leggere
Per chi cerca una soluzione pronta, benvenuti sotto il post.
Per non trattenere coloro che amano il metodo copia-incolla, inizierò con la parte pratica e dopo di essa ci sarà quella teorica.
1. Pratica. Delega la zona /28
Supponiamo di avere una subnet 7.8.9.0/24. Dobbiamo delegare la subnet 7.8.9.240/28 al client DNS 7.8.7.8 (ns1.client.domain).
Sul DNS del provider, è necessario trovare il file che descrive la zona inversa di questa subnet. Supponiamo sia 9.8.7.in-addr.arpa.
Commentiamo i record da 240 a 255, se presenti. E aggiungiamo alla fine del file quanto segue:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240non dimentichiamo di aumentare il numero di versione delle zone seriali e procediamo
rndc reloadLa parte del provider è terminata. Passiamo al DNS client.
Iniziamo creando un file /etc/bind/master/255-240.9.8.7.in-addr.arpa con il seguente contenuto:
$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@ 1D IN SOA ns1.client.domain. root.client.domain. (
2008152607 ; seriale
3H ; refresh
15M ; retry
1W ; scadenza
1D ) ; minimo
@ 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 named.conf aggiungiamo la 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";
};Poi riavviamo il processo bind.
/etc/init.d/named restartTutto. Ora possiamo 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.Nota che vengono restituiti non solo i record PTR ma anche i CNAME. È tutto normale. Se sei curioso sul perché, benvenuto al capitolo successivo.
2. Teoria. Come funziona.
È difficile configurare e debug un black box. È molto più semplice se capisci cosa succede all'interno.
Quando deleghiamo un sottodominio in un dominio dominio, scriviamo qualcosa del genere:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Diciamo a tutti coloro che chiedono che non siamo responsabili per questa zona e chi è responsabile. E tutte le richieste a client.domain vengono reindirizzate a 7.8.7.8. Durante il controllo vediamo la seguente situazione (sottintendendo cosa c'è dal cliente; non è importante):
# host test.client.domain
test.client.domain has address 7.8.9.241Cioè, ci è stato comunicato che esiste un record A e il suo ip 7.8.9.241. Nessuna informazione aggiuntiva.
E come si può fare lo stesso con una sottorete?
Poiché il nostro server DNS è registrato in RIPE, quando viene effettuata una richiesta PTR per l'ip dalla nostra rete, la prima richiesta sarà comunque verso di noi. La logica è la stessa che con i domini. Ma come scrivere la sottorete nel file di zona?
Proviamo a scrivere in questo modo:
255-240 IN NS 7.8.7.8E… il miracolo non è avvenuto. Non riceviamo alcun reindirizzamento della richiesta. Tutto il problema è che bind non sa che queste voci nel file di zona inversa sono indirizzi ip e tantomeno non comprende la registrazione dell'intervallo. Per lui è semplicemente un sottodominio simbolico. Cioè, per bind non ci sarà differenza tra «255-240» e «oursuperclient». E perché la richiesta vada dove deve, l'indirizzo nella richiesta deve apparire così: 241.255-240.9.8.7.in-addr.arpa. O in questo modo, se usiamo un sottodominio simbolico: 241.oursuperclient.9.8.7.in-addr.arpa. Questo è diverso dal normale: 241.9.8.7.in-addr.arpa.
È complicato effettuare una richiesta del genere manualmente. E se ci riesci, non è chiaro come applicarlo nella vita reale. Infatti, la richiesta 7.8.9.241 continua a rispondere il DNS del provider, non quello del cliente.
E qui entra in gioco CNAME.
Dallato del provider, è necessario creare un alias per tutti gli indirizzi IP della sottorete in un formato che reindirizzi la richiesta al DNS del cliente.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
e così via.
Questo è per i lavoratori =).
E per i più pigri, è più adatta la costruzione seguente:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Ora la richiesta di informazioni all'indirizzo 7.8.9.241 di 241.9.8.7.in-addr.arpa sul server DNS del provider verrà trasformata in 241.255-240.9.8.7.in-addr.arpa e si dirigerà verso il DNS del cliente.
Dal lato del cliente, sarà necessario gestire tali richieste. Pertanto, creiamo la zona 255-240.9.8.7.in-addr.arpa. In essa possiamo in linea di principio collocare record inversi per qualsiasi IP dell'intera sottorete /24, ma ci chiederanno solo quelli a cui il provider ci reindirizza, quindi non ci si può divertire =).
Per illustrare, riporto ancora un esempio del contenuto del file di zona inversa da parte del cliente:
$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@ 1D IN SOA ns1.client.domain. root.client.domain. (
2008152607 ; seriale
3H ; refresh
15M ; retry
1W ; scadenza
1D ) ; minimo
@ 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.
Questo è il motivo per cui, da parte del fornitore, utilizziamo CNAME, e quindi riceviamo in risposta una richiesta di dati per indirizzo IP due record, e non uno solo.
#> 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 dimenticate di configurare correttamente le ACL. Perché non ha senso prendere la zona PTR e non rispondere a nessuno dall'esterno =).
Fonte: habr.com
