En dag stod jeg over for opgaven at give en af mine kunder rettigheder til at redigere PTR-posterne for den tildelte subnet /28. Jeg har ingen automatisering til at redigere BIND-indstillinger udefra. Derfor besluttede jeg mig for at tage en anden vej - at delegere en del af PTR-zonen af subnet /24 til kunden.
Det burde være enkelt, ikke? Vi angiver blot subnettet korrekt og peger på den ønskede NS, som man gør med underdomæner. Men nej. Det er ikke så enkelt (selvom det faktisk er ganske primitivt, men intuitionen hjælper ikke), derfor skriver jeg denne artikel.
Den, der vil finde ud af det selv, kan læse
Den, der ønsker en færdig løsning, er velkommen under cut.
For ikke at forsinke dem, der elsker metode kopier og indsæt, vil jeg først offentliggøre den praktiske del, og derefter den teoretiske.
1. Praksis. Vi delegere zonen /28.
Lad os antage, at vi har en subnet. 7.8.9.0/24. Vi skal delegere subnettet 7.8.9.240/28 til DNS-klienten 7.8.7.8 (ns1.client.domain).
På udbyderens DNS skal vi finde filen, som beskriver den omvendte zone for dette subnet. Lad det være 9.8.7.in-addr.arpa.
Poster fra 240 til 255 kommenteres, hvis der er nogen. Og til slutningen af filen skriver vi følgende:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240Husk at øge zonens serial og kør
rndc reloadDette afslutter udbyderens del. Lad os gå videre til klientens DNS.
Først opretter vi filen /etc/bind/master/255-240.9.8.7.in-addr.arpa med følgende indhold:
$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.
Og i named.conf tilføjer vi beskrivelsen af vores nye fil:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B genstarter bind-processen.
/etc/init.d/named restartDet er alt. Nu kan vi kontrollere.
#> 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.Bemærk, at der ikke kun gives PTR-poster, men også CNAME. Det er sådan, det skal være. Hvis du er interesseret i hvorfor, er du velkommen til næste kapitel.
2. Teori. Hvordan det fungerer.
Det er svært at konfigurere og debugge en sort boks. Meget lettere, hvis man forstår, hvad der sker indeni.
Når vi delegere en underdomæne i domænet domæne, skriver vi noget i stil med dette:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Vi informerer alle, der spørger, at vi ikke er ansvarlige for dette område og fortæller, hvem der er ansvarlig. Og alle forespørgsler på client.domain bliver omdirigeret til 7.8.7.8. Ved kontrol ser vi følgende billede (lad os antage, at der er noget hos klienten, det er ikke vigtigt):
# host test.client.domain
test.client.domain has address 7.8.9.241Det vil sige, vi er blevet informeret om, at der findes en A-post, og dens IP er 7.8.9.241. Ingen ekstra information.
Hvordan kan man gøre det samme med et subnet?
Da vores DNS-server er registreret i RIPE, vil den første forespørgsel på PTR IP-adressen fra vores netværk stadig være til os. Logikken er den samme som med domæner. Men hvordan skriver man subnettet ind i zonefilen?
Vi prøver at skrive det sådan her:
255-240 IN NS 7.8.7.8Og… miraklet skete ikke. Vi modtager ingen omdirigering af forespørgslen. Alt skyldes, at bind overhovedet ikke er klar over, at disse poster i den omvendte zonefil er IP-adresser, og slet ikke forstår intervalposten. For den er det simpelthen en slags symbolsk underdomæne. Det vil sige, for bind vil der ikke være nogen forskel mellem “255-240" og "oursuperclient“. Og for at forespørgslen skal sende det, den skal, skal adressen i forespørgslen se sådan her ud: 241.255-240.9.8.7.in-addr.arpa. Eller sådan her, hvis vi bruger et symbolsk underdomæne: 241.oursuperclient.9.8.7.in-addr.arpa. Dette adskiller sig fra den almindelige: 241.9.8.7.in-addr.arpa.
Det vil være problematisk at lave en sådan forespørgsel manuelt. Og hvis det lykkes, er det stadig uklart, hvordan man anvender dette i praksis. For ved forespørgslen 7.8.9.241 vil vi stadig få svar fra udbyderens DNS, ikke klientens.
Men her kommer CNAME.
I udbyderens side skal der laves et alias for alle IP-adresser i subnettet i det format, som videresender forespørgslen til klientens DNS.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
og så videre.
Dette er for de flittige =).
Og for de dovne passer nedenstående konstruktion bedre:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Nu vil forespørgslen om information om adressen 7.8.9.241 af 241.9.8.7.in-addr.arpa på udbyderens DNS-server blive omdannet til 241.255-240.9.8.7.in-addr.arpa og sendes til DNS-klienten.
På klientens side skal sådanne forespørgsler behandles. Derfor opretter vi en zone 255-240.9.8.7.in-addr.arpa. I den kan vi i princippet placere omvendte poster for alle IP'er i hele subnettet /24, men der vil kun blive spurgt om dem, som udbyderen videresender til os, så vi kan ikke lege for meget =).
For at illustrere vil jeg endnu engang give et eksempel på indholdet af den omvendte zonefil fra klientens side:
$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.
Det er fordi, vi fra udbyderens side bruger CNAME, at vi modtager to poster som svar på forespørgslen om data. IP-adresse to poster i stedet for en.
#> 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. Og husk at indstille ACL korrekt. For det giver ikke mening at tage PTR-zonen til sig og ikke svare nogen udefra =).
Kilde: habr.com
