En dag sto jeg overfor oppgaven med å gi en av mine klienter rett til å redigere PTR-poster for /28-undernettet som ble tildelt ham. Jeg har ikke automatisering for redigering av BIND-innstillinger fra utsiden. Derfor bestemte jeg meg for å ta en annen rute - å delegere til klienten en del av PTR-sonen til /24-undernettet.
Det ser ut til - hva kan være enklere? Vi registrerer ganske enkelt subnettet etter behov og dirigerer det til ønsket NS, slik det gjøres med et subdomene. Men nei. Det er ikke så enkelt (selv om det i virkeligheten generelt er primitivt, men intuisjon vil ikke hjelpe), det er derfor jeg skriver denne artikkelen.
Alle som vil finne ut av det selv kan lese
Hvem ønsker en ferdig løsning, velkommen til katt.
For ikke å forsinke de som liker copy-paste-metoden, vil jeg legge ut den praktiske delen først, og deretter den teoretiske delen.
1. Øv. Delegeringssone /28
La oss si at vi har et subnett 7.8.9.0/24. Vi må delegere subnettet 7.8.9.240/28 til dns klient 7.8.7.8 (ns1.client.domene).
På leverandørens DNS må du finne en fil som beskriver den omvendte sonen til dette subnettet. La det være 9.8.7.in-addr.harpe.
Vi kommenterer oppføringer fra 240 til 255, hvis det er noen. Og på slutten av filen skriver vi følgende:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240ikke glem å øke seriesonen og gjør
rndc reloadDette fullfører leverandørdelen. La oss gå videre til klient-dns.
Først, la oss lage en fil /etc/bind/master/255-240.9.8.7.in-addr.arpa følgende innhold:
$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 heter.konf legg til en beskrivelse av vår 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 start bindingsprosessen på nytt.
/etc/init.d/named restartAlle. Nå kan du sjekke.
#> 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.Vær oppmerksom på at ikke bare PTR-posten er gitt, men også CNAME. Sånn skal det være. Hvis du lurer på hvorfor, så velkommen til neste kapittel.
2. Teori. Hvordan det fungerer.
Det er vanskelig å konfigurere og feilsøke en svart boks. Det er mye lettere hvis du forstår hva som foregår på innsiden.
Når vi delegerer et underdomene i et domene domene, så skriver vi noe slikt:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Vi forteller alle som spør at vi ikke er ansvarlige for denne siden og sier hvem som er ansvarlig. Og alle forespørsler om klient.domene omdirigere til 7.8.7.8. Når vi sjekker, ser vi følgende bilde (vi utelater det kunden har der. Det spiller ingen rolle):
# host test.client.domain
test.client.domain has address 7.8.9.241De. vi ble informert om at det er en slik A-post og dens ip er 7.8.9.241. Ingen unødvendig informasjon.
Hvordan kan det samme gjøres med et subnett?
Fordi vår DNS-server er registrert i RIPE, så når du ber om en PTR IP-adresse fra nettverket vårt, vil den første forespørselen fortsatt være til oss. Logikken er den samme som med domener. Men hvordan legger du inn et subnett i en sonefil?
La oss prøve å legge det inn slik:
255-240 IN NS 7.8.7.8Og... miraklet skjedde ikke. Vi mottar ingen omdirigering av forespørselen. Saken er at bind ikke engang vet at disse oppføringene i den omvendte sonefilen er IP-adresser, og enda mer forstår ikke rekkeviddeoppføringen. For ham er dette bare et slags symbolsk underdomene. De. for bind vil det ikke være noen forskjell mellom "255-240"Og"vår superklient". Og for at forespørselen skal gå dit den skal, skal adressen i forespørselen se slik ut: 241.255-240.9.8.7.in-addr.arpa. Eller slik hvis vi bruker et underdomene for tegn: 241.vårsuperklient.9.8.7.i-addr.arpa. Dette er forskjellig fra det vanlige: 241.9.8.7.in-addr.harpe.
Det vil være vanskelig å gjøre en slik forespørsel manuelt. Og selv om det fungerer, er det fortsatt uklart hvordan du bruker det i det virkelige liv. Tross alt, på forespørsel 7.8.9.241 Leverandørens DNS svarer fortsatt til oss, ikke klientens.
Og det er her de spiller inn administrasjon.
På leverandørens side må du lage et alias for alle IP-adressene til subnettet i et format som vil videresende forespørselen 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 hardtarbeidende =).
Og for de late er designet nedenfor mer egnet:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Be nå om informasjon på 7.8.9.241 av 241.9.8.7.in-addr.harpe på leverandørens DNS-server vil bli konvertert til 241.255-240.9.8.7.in-addr.arpa og går til dns-klienten.
Kundesiden må håndtere slike forespørsler. Følgelig oppretter vi en sone 255-240.9.8.7.in-addr.arpa. I den kan vi i prinsippet plassere omvendte oppføringer for hvilken som helst ip av hele /24-undernettet, men de vil bare spørre oss om de som leverandøren videresender til oss, så vi kan ikke spille rundt =).
For å illustrere vil jeg nok en gang gi et eksempel på innholdet i en omvendt sonefil 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 bruker CNAME på leverandørens side, og som svar på en forespørsel om data etter IP-adresse mottar 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 ikke glem å konfigurere ACL riktig. For det gir ingen mening å ta en PTR-sone for deg selv og ikke svare noen utenfra =).
Kilde: www.habr.com