En dag stod jag inför uppgiften att ge en av mina klienter rätten att redigera PTR-poster för /28-undernätet som tilldelats honom. Jag har ingen automatisering för att redigera BIND-inställningar utifrån. Därför bestämde jag mig för att ta en annan väg - att delegera till klienten en del av PTR-zonen i /24-undernätet.
Det verkar - vad kan vara enklare? Vi registrerar helt enkelt subnätet efter behov och dirigerar det till önskad NS, som man gör med en subdomän. Men nej. Det är inte så enkelt (även om det i verkligheten i allmänhet är primitivt, men intuition hjälper inte), det är därför jag skriver den här artikeln.
Den som vill klura ut det själv kan läsa
Vem vill ha en färdig lösning, välkommen till katt.
För att inte fördröja de som gillar copy-paste-metoden kommer jag att lägga upp den praktiska delen först och sedan den teoretiska delen.
1. Öva. Delegerande zon /28
Låt oss säga att vi har ett subnät 7.8.9.0/24. Vi måste delegera subnätet 7.8.9.240/28 till dns-klient 7.8.7.8 (ns1.client.domain).
På leverantörens DNS måste du hitta en fil som beskriver den omvända zonen för detta subnät. Låt det vara 9.8.7.in-addr.harpa.
Vi kommenterar inlägg från 240 till 255, om det finns några. Och i slutet av filen skriver vi följande:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240glöm inte att öka den seriella zonen och gör
rndc reloadDetta slutför leverantörsdelen. Låt oss gå vidare till klientens dns.
Låt oss först skapa en fil /etc/bind/master/255-240.9.8.7.in-addr.arpa följande innehåll:
$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.
Och i heter.konf lägg till en beskrivning av vår nya fil:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B starta om bindningsprocessen.
/etc/init.d/named restartAllt. Nu kan du kolla.
#> 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.Observera att inte bara PTR-posten anges, utan även CNAME. Det är så det ska vara. Om du undrar varför, välkommen till nästa kapitel.
2. Teori. Hur det fungerar.
Det är svårt att konfigurera och felsöka en svart låda. Det är mycket lättare om du förstår vad som händer inuti.
När vi delegerar en underdomän i en domän domän, då skriver vi ungefär så här:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Vi säger till alla som frågar att vi inte är ansvariga för denna sida och säger vem som är ansvarig. Och alla förfrågningar om klient.domän omdirigera till 7.8.7.8. När vi kontrollerar ser vi följande bild (vi utelämnar vad kunden har där. Det spelar ingen roll):
# host test.client.domain
test.client.domain has address 7.8.9.241De där. vi fick information om att det finns en sådan A-post och dess ip är 7.8.9.241. Ingen onödig information.
Hur kan samma sak göras med ett subnät?
Därför att vår DNS-server är registrerad i RIPE, då när du begär en PTR IP-adress från vårt nätverk kommer den första begäran fortfarande att vara till oss. Logiken är densamma som med domäner. Men hur lägger man in ett subnät i en zonfil?
Låt oss försöka skriva in det så här:
255-240 IN NS 7.8.7.8Och... miraklet hände inte. Vi tar inte emot någon omdirigering av begäran. Saken är att bind inte ens vet att dessa poster i den omvända zonfilen är IP-adresser, och ännu mer förstår inte intervallposten. För honom är detta bara någon form av symbolisk underdomän. De där. för bind blir det ingen skillnad mellan "255-240"Och"vår superklient". Och för att förfrågan ska gå dit den ska, bör adressen i begäran se ut så här: 241.255-240.9.8.7.in-addr.arpa. Eller så här om vi använder en teckenunderdomän: 241.vår superklient.9.8.7.i-addr.arpa. Detta skiljer sig från det vanliga: 241.9.8.7.in-addr.harpa.
Det kommer att vara svårt att göra en sådan begäran manuellt. Och även om det fungerar är det fortfarande oklart hur man använder det i verkligheten. När allt kommer omkring på begäran 7.8.9.241 Leverantörens DNS svarar fortfarande till oss, inte kundens.
Och det är här de kommer in i bilden administration.
På leverantörens sida måste du skapa ett alias för alla IP-adresser i undernätet i ett format som vidarebefordrar begäran till klientens DNS.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
и т.д.
Detta är för de hårt arbetande =).
Och för de lata är designen nedan mer lämplig:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Begär nu information på 7.8.9.241 av 241.9.8.7.in-addr.harpa på leverantörens DNS-server kommer att konverteras till 241.255-240.9.8.7.in-addr.arpa och går till dns-klienten.
Kundsidan kommer att behöva hantera sådana förfrågningar. Följaktligen skapar vi en zon 255-240.9.8.7.in-addr.arpa. I den kan vi i princip placera omvända poster för vilken ip som helst i hela /24-undernätet, men de kommer bara att fråga oss om de som leverantören vidarebefordrar till oss, så vi kommer inte att kunna leka =).
För att illustrera kommer jag återigen ge ett exempel på innehållet i en omvänd zonfil från klientsidan:
$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 beror på att vi använder CNAME på leverantörens sida, och som svar på en begäran om data per IP-adress får vi två poster, inte 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.
Och glöm inte att konfigurera ACL korrekt. För det är ingen mening att ta en PTR-zon för sig själv och inte svara på någon utifrån =).
Källa: will.com