En dag stod jeg over for opgaven at give en af mine klienter ret til at redigere PTR-registreringer af /28-undernettet, der var tildelt ham. Jeg har ikke automatisering til at redigere BIND-indstillinger udefra. Derfor besluttede jeg at tage en anden rute - at uddelegere til klienten et stykke af PTR-zonen i /24-undernettet.
Det ser ud til - hvad kunne være nemmere? Vi registrerer blot subnettet efter behov og dirigerer det til det ønskede NS, som det gøres med et underdomæne. Men nej. Det er ikke så enkelt (selvom det i virkeligheden generelt er primitivt, men intuition hjælper ikke), det er derfor, jeg skriver denne artikel.
Alle, der selv vil finde ud af det, kan læse
Hvem ønsker en færdig løsning, velkommen til kat.
For ikke at forsinke dem, der kan lide copy-paste-metoden, vil jeg først poste den praktiske del og derefter den teoretiske del.
1. Øv. Delegerende zone /28
Lad os sige, at vi har et undernet 7.8.9.0/24. Vi skal uddelegere undernettet 7.8.9.240/28 til dns klient 7.8.7.8 (ns1.client.domæne).
På udbyderens DNS skal du finde en fil, der beskriver den omvendte zone af dette undernet. Lad det være 9.8.7.i-addr.arpa.
Vi kommenterer indlæg fra 240 til 255, hvis der er nogen. Og i slutningen af filen skriver vi følgende:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240glem ikke at øge den serielle zone og gør
rndc reloadDette fuldender udbyderdelen. Lad os gå videre til klient dns.
Lad os først oprette en fil /etc/bind/master/255-240.9.8.7.in-addr.arpa 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 opkaldt.konf tilføj en beskrivelse 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 genstart bindingsprocessen.
/etc/init.d/named restartAlle. Nu kan du tjekke.
#> 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 ikke kun PTR-posten er angivet, men også CNAME. Sådan skal det være. Hvis du undrer dig over hvorfor, så velkommen til næste kapitel.
2. Teori. Hvordan det virker.
Det er svært at konfigurere og fejlfinde en sort boks. Det er meget nemmere, hvis du forstår, hvad der foregår indeni.
Når vi uddelegerer et underdomæne i et domæne domæne, så skriver vi noget som dette:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Vi fortæller alle, der spørger, at vi ikke er ansvarlige for denne side og siger, hvem der er ansvarlig. Og alle anmodninger om klient.domæne omdirigere til 7.8.7.8. Når vi tjekker, ser vi følgende billede (vi udelader, hvad klienten har der. Det betyder ikke noget):
# host test.client.domain
test.client.domain has address 7.8.9.241De der. vi blev informeret om, at der er sådan en A-record, og dens ip er 7.8.9.241. Ingen unødvendig information.
Hvordan kan det samme gøres med et undernet?
Fordi vores DNS-server er registreret i RIPE, så når du anmoder om en PTR IP-adresse fra vores netværk, vil den første anmodning stadig være til os. Logikken er den samme som med domæner. Men hvordan indtaster du et undernet i en zonefil?
Lad os prøve at indtaste det sådan her:
255-240 IN NS 7.8.7.8Og... miraklet skete ikke. Vi modtager ingen anmodningsomdirigering. Sagen er, at bind ikke engang ved, at disse poster i den omvendte zone-fil er IP-adresser, og bestemt ikke forstår rækkevidden. For ham er dette blot en slags symbolsk underdomæne. De der. for bind vil der ikke være nogen forskel mellem "255-240"Og"vores superklient". Og for at anmodningen skal gå, hvor den skal hen, skal adressen i anmodningen se sådan ud: 241.255-240.9.8.7.in-addr.arpa. Eller sådan her, hvis vi bruger et karakterunderdomæne: 241.vores superklient.9.8.7.i-addr.arpa. Dette er anderledes end det sædvanlige: 241.9.8.7.i-addr.arpa.
Det vil være vanskeligt at lave en sådan anmodning manuelt. Og selvom det virker, er det stadig uklart, hvordan man anvender det i det virkelige liv. Efter alt efter anmodning 7.8.9.241 Udbyderens DNS svarer stadig til os, ikke kundens.
Og det er her, de kommer i spil CNAME.
På udbyderens side skal du lave et alias for alle IP-adresser på undernettet i et format, der videresender anmodningen til klientens DNS.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
и т.д.
Dette er for de hårdtarbejdende =).
Og for de dovne er designet nedenfor mere egnet:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Bed nu om oplysninger på 7.8.9.241 af 241.9.8.7.i-addr.arpa på udbyderens DNS-server vil blive konverteret til 241.255-240.9.8.7.in-addr.arpa og går til dns-klienten.
Kundesiden skal håndtere sådanne anmodninger. Derfor opretter vi en zone 255-240.9.8.7.in-addr.arpa. I den kan vi i princippet placere omvendte indtastninger for enhver ip af hele /24-undernettet, men de vil kun spørge os om dem, som udbyderen videresender til os, så vi kan ikke spille rundt =).
Til illustration vil jeg endnu en gang give et eksempel på indholdet af en omvendt zonefil fra klientsiden:
$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 bruger CNAME på udbyderens side, og som svar på en anmodning om data efter IP-adresse modtager vi to poster, ikke én.
#> 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 glem ikke at konfigurere ACL korrekt. For det giver ingen mening at tage en PTR-zone for sig selv og ikke reagere på nogen udefra =).
Kilde: www.habr.com