Op een dag werd ik geconfronteerd met de taak om een van mijn klanten het recht te geven om PTR-records te bewerken van het /28-subnet dat aan hem was toegewezen. Ik heb geen automatisering voor het bewerken van BIND-instellingen van buitenaf. Daarom besloot ik een andere route te volgen: een deel van de PTR-zone van het /24-subnet aan de klant delegeren.
Het lijkt erop: wat is er eenvoudiger? Wij registreren eenvoudigweg het subnet zoals vereist en sturen het door naar de gewenste NS, zoals dat bij een subdomein gebeurt. Maar nee. Zo eenvoudig is het niet (hoewel het in werkelijkheid over het algemeen primitief is, maar intuïtie helpt niet), daarom schrijf ik dit artikel.
Iedereen die het zelf wil uitzoeken, kan lezen
Wie een kant-en-klare oplossing wil, welkom bij cat.
Om degenen die van de copy-paste-methode houden niet op te houden, zal ik eerst het praktische gedeelte en daarna het theoretische gedeelte posten.
1. Oefenen. Delegatiezone /28
Laten we zeggen dat we een subnet hebben 7.8.9.0/24. We moeten het subnet delegeren 7.8.9.240/28 naar dns-client 7.8.7.8 (ns1.client.domein).
Op de DNS van de provider moet u een bestand vinden dat de omgekeerde zone van dit subnet beschrijft. Laat maar zo 9.8.7.in-addr.harp.
Wij geven commentaar op inzendingen van 240 tot en met 255, als die er zijn. En aan het einde van het bestand schrijven we het volgende:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240vergeet niet de seriële zone te vergroten en doe dat ook
rndc reloadHiermee is het providergedeelte voltooid. Laten we verder gaan met de client-DNS.
Laten we eerst een bestand maken /etc/bind/master/255-240.9.8.7.in-addr.arpa de volgende inhoud:
$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.
En c genaamd.conf voeg een beschrijving toe van ons nieuwe bestand:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B start het bindproces opnieuw.
/etc/init.d/named restartAlle. Nu kunt u het controleren.
#> 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.Houd er rekening mee dat niet alleen het PTR-record wordt opgegeven, maar ook de CNAME. Dat is hoe het moet zijn. Als je je afvraagt waarom, welkom dan bij het volgende hoofdstuk.
2. Theorie. Hoe het werkt.
Het is moeilijk om een black box te configureren en te debuggen. Het is veel gemakkelijker als je begrijpt wat er binnenin gebeurt.
Wanneer we een subdomein in een domein delegeren domein, dan schrijven we zoiets als dit:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8We vertellen iedereen die vraagt dat we niet verantwoordelijk zijn voor deze site en zeggen wie verantwoordelijk is. En alle aanvragen voor klant.domein omleiden naar 7.8.7.8. Bij controle zien we het volgende beeld (wat de klant daar heeft laten we weg. Het maakt niet uit):
# host test.client.domain
test.client.domain has address 7.8.9.241Die. we kregen te horen dat er zo'n A-record bestaat en dat het IP-adres 7.8.9.241 is. Geen onnodige informatie.
Hoe kan hetzelfde worden gedaan met een subnet?
Omdat onze DNS-server is geregistreerd in RIPE, dan zal bij het aanvragen van een PTR IP-adres uit ons netwerk het eerste verzoek nog steeds bij ons terechtkomen. De logica is hetzelfde als bij domeinen. Maar hoe voer je een subnet in een zonebestand in?
Laten we proberen het als volgt in te voeren:
255-240 IN NS 7.8.7.8En... het wonder gebeurde niet. We ontvangen geen omleiding van verzoeken. Het punt is dat bind niet eens weet dat deze vermeldingen in het omgekeerde zonebestand IP-adressen zijn, en nog meer de bereikinvoer niet begrijpt. Voor hem is dit slechts een soort symbolisch subdomein. Die. voor binden zal er geen verschil zijn tussen "255-240"En"onzesuperklant". En om het verzoek te laten gaan waar het heen moet, moet het adres in het verzoek er als volgt uitzien: 241.255-240.9.8.7.in-adr.arpa. Of zoals dit als we een karakter-subdomein gebruiken: 241.onzesuperclient.9.8.7.in-addr.arpa. Dit is anders dan gebruikelijk: 241.9.8.7.in-addr.harp.
Het zal moeilijk zijn om een dergelijk verzoek handmatig in te dienen. En zelfs als het werkt, is het nog steeds onduidelijk hoe het in het echte leven moet worden toegepast. Op verzoek immers 7.8.9.241 De DNS van de provider antwoordt nog steeds naar ons, niet die van de klant.
En dit is waar ze in het spel komen CNAME.
Aan de kant van de provider moet u een alias maken voor alle IP-adressen van het subnet in een formaat dat het verzoek doorstuurt naar de client-DNS.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
и т.д.
Dit is voor de hardwerkende =).
En voor de lui is het onderstaande ontwerp geschikter:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Vraag nu informatie aan via 7.8.9.241 van 241.9.8.7.in-addr.harp op de DNS-server van de provider wordt omgezet naar 241.255-240.9.8.7.in-adr.arpa en gaat naar de DNS-client.
De klantzijde zal dergelijke verzoeken moeten afhandelen. Dienovereenkomstig creëren we een zone 255-240.9.8.7.in-adr.arpa. Daarin kunnen we in principe omgekeerde gegevens plaatsen voor elk IP-adres van het gehele /24-subnet, maar ze zullen ons alleen vragen naar de gegevens die de provider naar ons doorstuurt, dus we kunnen er niet mee spelen =).
Ter illustratie zal ik nogmaals een voorbeeld geven van de inhoud van een reverse zone-bestand vanaf de clientzijde:
$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.
Dit komt omdat we CNAME gebruiken aan de kant van de provider, en als reactie op een verzoek om gegevens op IP-adres ontvangen we twee records, niet éé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.
En vergeet niet om de ACL correct te configureren. Omdat het geen zin heeft om voor jezelf een PTR-zone te nemen en op niemand van buitenaf te reageren =).
Bron: www.habr.com