Un giorno mi è stata posta la questione di concedere a uno dei clienti il diritto di modificare i record PTR della rete /28 che gli era stata assegnata. Non ho alcuna automazione per modificare le impostazioni di BIND dall'esterno. Pertanto, ho deciso di seguire un altro percorso: delegare al cliente una parte della zona PTR della rete /24.
A prima vista, cosa può essere più semplice? Basta specificare la rete come necessario e indirizzarla al corretto NS, come si fa con un sottodominio. Ma no. Non è così semplice (anche se in realtà è piuttosto primitivo, ma l'intuizione non aiuta), ed è per questo che scrivo questo articolo.
Chi vuole approfondire può leggere.
Chi cerca una soluzione pronta, benvenuto sotto il tag.
Per non trattenere chi ama il metodo del copia e incolla, inizierò con la parte pratica, seguita dalla parte teorica.
1. Pratica. Delegalare la zona /28.
Supponiamo di avere una rete. 7.8.9.0/24. Dobbiamo delegare la rete. 7.8.9.240/28 al dns-client. 7.8.7.8 (ns1.client.domain.).
Sui dns del fornitore, dobbiamo trovare il file che descrive la zona inversa di questa rete. Chiamiamolo. 9.8.7.in-addr.arpa..
Commentiamo le voci da 240 a 255, se presenti. E in fondo al file scriviamo quanto segue:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240non dimentichiamo di aumentare il serial della zona e facciamo.
rndc reload.A questo punto, la parte del fornitore è terminata. Passiamo al dns del cliente.
Per prima cosa, creiamo il file. /etc/bind/master/255-240.9.8.7.in-addr.arpa del seguente contenuto:
$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. 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";
};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. È così che deve essere. Se sei curioso di sapere perché, benvenuto al capitolo successivo.
2. Teoria. Come funziona.
È difficile configurare e risolvere un black box. Molto più semplice è se capisci cosa sta accadendo all'interno.
Quando delegiamo un sottodominio in un dominio. domain, scriviamo qualcosa di simile:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Diciamo a tutti coloro che chiedono che non siamo responsabili per questo dominio e indichiamo chi è responsabile. E tutte le richieste su client.domain vengono reindirizzate su 7.8.7.8. Durante il controllo vediamo la seguente situazione (saliamo sopra ciò che ha il cliente. non è importante):
# host test.client.domain
test.client.domain has address 7.8.9.241Cioè, ci hanno informato che esiste un record A e il suo ip è 7.8.9.241. Nessuna informazione aggiuntiva.
E come si può fare la stessa cosa con una sottorete?
Poiché il nostro server DNS è registrato in RIPE, quando viene effettuata una richiesta PTR su un indirizzo IP della nostra rete, comunque la prima richiesta sarà verso di noi. La logica è la stessa di quella dei domini. Solo che come inserire la sottorete nel file di zona?
Proviamo a inserirla in questo modo:
255-240 IN NS 7.8.7.8E… non è successo nulla. Non riceviamo alcun reindirizzamento della richiesta. Il fatto è che bind non è affatto a conoscenza che questi record nel file della zona inversa sono indirizzi IP e tantomeno comprende il record di intervallo. Per lui è semplicemente un qualche sottodominio simbolico. Cioè, per bind non ci sarà differenza tra "255-240" e "oursuperclient". E affinché la richiesta venga indirizzata a dove deve, l'indirizzo nella richiesta deve apparire in questo modo: 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 da un normale: 241.9.8.7.in-addr.arpa.
Creare una richiesta in questo modo sarà problematico. E anche se ci riuscisse, non è chiaro come applicarlo nella vita reale. Infatti, in risposta alla richiesta 7.8.9.241 continuiamo a ricevere risposte dal DNS del provider, non da quello del cliente.
Ma qui entrano in gioco CNAME.
Dalla parte del fornitore deve essere creato un alias per tutti gli indirizzi IP della subnet nel formato che inoltrerà 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 laboriosi =).
E per i pigri, la costruzione qui sotto è più appropriata:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Ora la richiesta di informazioni all'indirizzo 7.8.9.241 da 241.9.8.7.in-addr.arpa sul server DNS del fornitore sarà convertita in 241.255-240.9.8.7.in-addr.arpa e andrà al DNS del cliente.
Dal lato del cliente sarà necessario gestire tali richieste. Pertanto creiamo una zona 255-240.9.8.7.in-addr.arpa. In essa possiamo sostanzialmente inserire record inversi per qualsiasi IP dell'intera subnet /24, ma ci verranno chieste solo quelle che il provider ci inoltrerà, quindi non sarà possibile divertirsi =).
Per illustrare, riporto ancora una volta un esempio del contenuto del file di zona inversa dalla parte del cliente:
$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.
A causa del fatto che utilizziamo CNAME dal lato del provider, riceviamo in risposta alla richiesta di dati relativi a indirizzo IP due registrazioni, e non una sola.
#> 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 ACL. Perché non ha senso prelevare la zona PTR e non rispondere a nessuno dall'esterno =).
Fonte: habr.com
