Еден ден се соочив со задача на еден од моите клиенти да му дадам право да уредува PTR записи на подмрежата /28 што му беше доделена. Немам автоматизација за уредување на поставките BIND однадвор. Затоа, решив да одам поинаков пат - да делегирам на клиентот дел од зоната PTR на подмрежата /24.
Се чини - што може да биде поедноставно? Едноставно ја регистрираме подмрежата како што се бара и ја насочуваме кон саканиот NS, како што се прави со поддомен. Но не. Не е толку едноставно (иако во реалноста е генерално примитивно, но интуицијата нема да помогне), затоа ја пишувам оваа статија.
Секој што сака да го сфати сам може да прочита
Кој сака готово решение, добредојде на мачка.
За да не ги одложувам оние на кои им се допаѓа методот copy-paste, прво ќе го постирам практичниот, а потоа теоретскиот.
1. Вежбајте. Зона на делегирање /28
Да речеме дека имаме подмрежа 7.8.9.0/24. Треба да ја делегираме подмрежата 7.8.9.240/28 на dns клиентот 7.8.7.8 (ns1.клиент.домен).
На DNS на провајдерот треба да најдете датотека што ја опишува обратната зона на оваа подмрежа. Нека биде 9.8.7. во-адреса .рпа.
Коментираме за записи од 240 до 255, доколку ги има. И на крајот од датотеката го пишуваме следново:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240не заборавајте да ја зголемите сериската зона и направете
rndc reloadОва го комплетира делот на провајдерот. Ајде да преминеме на DNS на клиентот.
Прво, ајде да создадеме датотека /etc/bind/master/255-240.9.8.7.in-addr.arpa следната содржина:
$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.
И во именуван.конф додадете опис на нашата нова датотека:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};Б рестартирајте го процесот на врзување.
/etc/init.d/named restartСите. Сега можете да проверите.
#> 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.Ве молиме имајте предвид дека не е даден само записот PTR, туку и CNAME. Така треба да биде. Ако се прашувате зошто, тогаш добре дојдовте во следното поглавје.
2. Теорија. Како работи.
Тешко е да се конфигурира и дебагира црна кутија. Многу е полесно ако разберете што се случува внатре.
Кога делегираме поддомен во домен домен, тогаш пишуваме нешто вака:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8На сите што прашуваат им кажуваме дека не сме одговорни за оваа страница и кажуваме кој е одговорен. И сите барања за клиент.домен пренасочи на 7.8.7.8. При проверка, ја гледаме следнава слика (ќе испуштиме што има клиентот таму. Не е важно):
# host test.client.domain
test.client.domain has address 7.8.9.241Оние. бевме информирани дека постои таков запис А и неговата ip е 7.8.9.241. Нема непотребни информации.
Како може истото да се направи со подмрежа?
Бидејќи нашиот DNS сервер е регистриран во RIPE, тогаш кога бараме PTR IP адреса од нашата мрежа, првото барање сепак ќе биде до нас. Логиката е иста како кај домените. Но, како да внесете подмрежа во датотека со зона?
Ајде да се обидеме да го внесеме вака:
255-240 IN NS 7.8.7.8И... чудото не се случи. Не добиваме пренасочување на барањето. Работата е што bind дури и не знае дека овие записи во датотеката со обратна зона се IP адреси, а уште повеќе не го разбира внесувањето на опсегот. За него ова е само некаков симболичен поддомен. Оние. за врзување нема да има разлика помеѓу "255-240"И"нашиот суперклиент“. А за барањето да оди таму каде што треба, адресата во барањето треба да изгледа вака: 241.255-240.9.8.7.in-addr.arpa. Или вака ако користиме поддомен на знаци: 241.нашиот суперклиент.9.8.7.in-addr.arpa. Ова е различно од вообичаеното: 241.9.8.7. во-адреса .рпа.
Ќе биде тешко да се направи такво барање рачно. И дури и ако функционира, сè уште не е јасно како да се примени во реалниот живот. Впрочем, на барање 7.8.9.241 DNS на давателот сè уште ни одговара, а не на клиентот.
И тука влегуваат во игра CNAME.
Од страната на провајдерот, треба да направите псевдоним за сите IP адреси на подмрежата во формат што ќе го проследи барањето до DNS на клиентот.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
и т.д.
Ова е за вредните =).
И за мрзливите, дизајнот подолу е посоодветен:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Сега побарајте информации на 7.8.9.241 на 241.9.8.7. во-адреса .рпа на DNS серверот на давателот ќе се конвертира во 241.255-240.9.8.7.in-addr.arpa и оди до клиентот dns.
Страната на клиентот ќе треба да се справи со таквите барања. Соодветно на тоа, создаваме зона 255-240.9.8.7.in-addr.arpa. Во него, во принцип, можеме да поставиме обратни записи за која било IP адреса на целата подмрежа /24, но тие ќе не прашаат само за оние што ни ги проследува давателот, така што нема да можеме да играме околу =).
За илустрација, уште еднаш ќе дадам пример за содржината на датотеката со обратна зона од страната на клиентот:
$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.
Тоа е затоа што користиме CNAME на страната на давателот и како одговор на барање за податоци по IP адреса добиваме два записи, а не еден.
#> 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.
И не заборавајте правилно да го конфигурирате ACL. Затоа што нема смисла да земете PTR зона за себе и да не одговарате на никого однадвор =).
Извор: www.habr.com