Отдать зону третьего уровня

[Rusya]

Спасибо что согласились помочь!
Суть в том что наш месный пров выдает имя третьего уровня например home.net.ru, для этого имени создал несколько сервисов с именами www.home.net.ru proxy.home.net.ru из внутренней сети естественно все работает а вот отдать эти имена корневому серверу ns.net.ru не получается.

p.s. а разве можно ему отдавать имена в таком виде? запутался

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[terminus]

Спасибо что согласились помочь!
Суть в том что наш месный пров выдает имя третьего уровня например home.net.ru, для этого имени создал несколько сервисов с именами http://www.home.net.ru proxy.home.net.ru из внутренней сети естественно все работает а вот отдать эти имена корневому серверу ns.net.ru не получается.

p.s. а разве можно ему отдавать имена в таком виде? запутался

Тут надо уточнить - ваш провайдер дает своим клиентам только имя в домене net.ru, или же позволяет проводить именно делегирование зоны? Точно или точно? Спрашиваю потому, что мне кажется, что вы запутались и на самом деле провайдер дает только имя (А запись: home.net.ru = IP адрес)... Давать своим клиентам возможность использовать имя в домене - это распространенная практика, а вот делегировать клиентам домены это как раз экзотическая ситуация...

Чтобы было наглядней о чем разговор идет, опишу как происходит процесс делигирования.
Делегирование - это то каким образом пространство имен в DNS делится на зоны. Зона - это обособленная ветвь пространства DNS имен которая распологается на своих авторитарных DNS серверах. Делегирование из родительской зоны происходит путем создания NS записей. В дочерней (делегированной) зоне создается полное описание зоны начиная с SOA записи. Вот, например, когда регистрируется домен второго уровня через регистратора nic.ru, то там при регистрации просят указать имена и адреса минимум двух DNS серверов которые будут считаться авторитарными для данной ветви пространства DNS имен. Для проведения делегирования не обязательно иметь под зону именно два DNS сервера - просто у nic.ru такая политика, для того чтобы заставить клиентов обеспечить надежность системы. Вот эти два сервера становятся NS записями в домене ru.

Пример. Скажем регистрируется домен второго уровня под названием net.ru. Авторитарными для него будут DNS сервера ns.net.ru (IP 1.2.3.4) и ns2.dnshosting.com (IP 5.6.7.9). В записях DNS серверов отвечающих за зону ru. (которыми управляет организация nic.ru) вносится такая информация:

Код: Выделить всё

$TTL 300
ru.	IN	SOA	ns.ripn.net. hostmaster.ripn.net. (
			4014396 ;serial
			7200	;refresh
			900	;retry
			2592000	;expire
			3600	;neg. ttl
			)
		NS	sunic.sunet.se.
		NS	e.dns.ripn.net.
		NS	ns.ripn.net.
		NS	ns5.msk-ix.net.

; это добавили
net.ru.	NS	ns.net.ru.
net.ru.	NS	ns2.dnshosting.com.
ns.net.ru.	A	1.2.3.4

В свою очередь на сервере ns.net.ru который является мастером для зоны net.ru создается полная SOA запись как и пологается:

Код: Выделить всё

$TTL 300
net.ru.	IN	SOA	ns.net.ru. hostmaster.net.ru. (
			2009012500	;serial
			7200		;refresh
			900		;retry
			2592000		;expire
			3600		;neg. ttl
			)
		NS	ns.net.ru.
		NS	ns2.dnshosting.com.
		MX 10	mail.net.ru.
ns.net.ru.	A	1.2.3.4

www.net.ru.	A	9.8.7.6
ftp.net.ru.	A	10.11.12.13
mail.net.ru.	A	11.12.13.14

На slave сервере ns2.dnshosting.com в ручную записи не создаются, но он настраевается так чтобы переодически запрашивать мастер ns.net.ru и перекачивать с него всю информацию о записях в домене, а мастер ns.net.ru настраевается так чтобы отдавать все записи о зоне при запросах с подчененного.

Точно по такой же схеме происходит делегирование доменов третьего, четвертого да любого уровня. Делегировать можно даже одно единственное хост имя!

Например ваш случай с делегированием домена третьего уровня.
Если провайдер действительно предлагает такую услугу/возможность то выглядеть это будет так - в записях зоны net.ru которую администрирует провайдер, добавляется информация с NS записями о поддомене home.net.ru (допустим, что у вас будет только один авторитарный DNS сервер для этого поддомена ns.home.net.ru IP 7.7.7.7)

Код: Выделить всё

$TTL 300
net.ru.	IN	SOA	ns.net.ru. hostmaster.net.ru. (
			2009012500	;serial
			7200		;refresh
			900		;retry
			2592000		;expire
			3600		;neg. ttl
			)
		NS	ns.net.ru.
		NS	ns2.dnshosting.com.
		MX 10	mail.net.ru.
ns.net.ru.	A	1.2.3.4

www.net.ru.	A	9.8.7.6
ftp.net.ru.	A	10.11.12.13
mail.net.ru.	A	11.12.13.14

;это добавили
home.net.ru.	NS	ns.home.net.ru.
ns.home.net.ru.	A	7.7.7.7

Ну и соответственно уже у вас, на вашем DNS сервере ns.home.net.ru создается зона с новой SOA записью:

Код: Выделить всё

$TTL 300
home.net.ru.	IN	SOA	ns.home.net.ru. hostmaster.home.net.ru. (
			2009012501	;serial
			7200		;refresh
			900		;retry
			2592000		;expire
			3600		;neg. ttl
			)
		NS	ns.home.net.ru.
ns.home.net.ru.	A	7.7.7.7

home.net.ru.		A	7.7.7.8
www.home.net.ru.	A	7.7.7.8
proxy.home.net.ru.	A	7.7.7.9

Был приведен синтаксис зоны как это принято в BIND и NSD. Для djbdns то, что написано выше будет выглядеть так:

Код: Выделить всё

Zhome.net.ru:ns.home.net.ru.:hostmaster.home.net.ru.:2009012501:7200:900:2592000:3600:300
&home.net.ru:7.7.7.7:ns.home.net.ru
+home.net.ru:7.7.7.8:300
+www.home.net.ru:7.7.7.8:300
+proxy.home.net.ru:7.7.7.9:300

До кучи, напишу заодно про реверс зоны и их делегирование.
Система DNS позволяет производить обратные разрешения из IP адресов в DNS имена. Для этого в дереве имен есть специальный служебный домен под именем in-addr.arpa. Этот домен имеет 256 поддоменов, каждый из поддомменов может иметь 256 своих поддоменов, у которых могут быть 256 своих поддоменов, в которых уже будет по 256 имен. Таким образом получается структура вида a.b.c.d.in-addr.arpa. где а,b,c,d это 0-255. На эту часть DNS имен распространяются те же правила, что и на обычные имена, вот только владельцем какого-либо поддомена может стать лишь организация получившая контроль за соответсвующим блоком IP адресов - например ваш провайдер, когда покупает для своих нужд у RIPE диапазоны IP адресов. Например, если провайдер купил себе подсеть с адресами 123.44.55.0/24 (256 адресов), то он может получить от RIPE (регионального регистратора) и реверс зону:

Код: Выделить всё

$TTL 300
55.44.123.in-addr.arpa.	IN	SOA	ns.net.ru. hostmaster.net.ru. (
			2009012500	;serial
			7200		;refresh
			900		;retry
			2592000		;expire
			3600		;neg. ttl
			)
		NS	ns.net.ru.
		NS	ns2.dnshosting.com.

1.55.44.123.in-addr.arpa.	PTR	hostname.net.ru.
2.55.44.123.in-addr.arpa.	PTR	imja.net.ru.
254.55.44.123.in-addr.arpa.	PTR	esheodnoija.net.ru.

Тут все просто и красиво потому, что в этом примере деление на DNS зону и IP субнет произошло по границе третьего и четвертого байта в IP адресе, а как делегировать половину субнета или только пару IP адресов из него? Скажеи клиент купил себе 8 белых IP адресов и захотел получить контроль над назначением реверс имен для них?
В таком случае можно сделать делегирование таким образом - в родительской зоне создаются CNAME записи на подставной домен, а он уже делегируется клиенту:

Код: Выделить всё

$TTL 300
55.44.123.in-addr.arpa.	IN	SOA	ns.net.ru. hostmaster.net.ru. (
			2009012500	;serial
			7200		;refresh
			900		;retry
			2592000		;expire
			3600		;neg. ttl
			)
		NS	ns.net.ru.
		NS	ns2.dnshosting.com.

1.55.44.123.in-addr.arpa.	PTR	hostname.net.ru.
2.55.44.123.in-addr.arpa.	PTR	imja.net.ru.
254.55.44.123.in-addr.arpa.	PTR	esheodnoija.net.ru.

;создаем подставные записи
7.55.44.123.in-addr.arpa.	CNAME	7.klient.55.44.123.in-addr.arpa.
8.55.44.123.in-addr.arpa.	CNAME	8.klient.55.44.123.in-addr.arpa.
9.55.44.123.in-addr.arpa.	CNAME	9.klient.55.44.123.in-addr.arpa.
10.55.44.123.in-addr.arpa.	CNAME	10.klient.55.44.123.in-addr.arpa.
11.55.44.123.in-addr.arpa.	CNAME	11.klient.55.44.123.in-addr.arpa.
12.55.44.123.in-addr.arpa.	CNAME	12.klient.55.44.123.in-addr.arpa.
13.55.44.123.in-addr.arpa.	CNAME	13.klient.55.44.123.in-addr.arpa.
14.55.44.123.in-addr.arpa.	CNAME	14.klient.55.44.123.in-addr.arpa.

;делегируем клиенту
klient.55.44.123.in-addr.arpa.	NS	ns1.klient.ru.
klient.55.44.123.in-addr.arpa.	NS	ns2.hosting.com.

Клиент принимает у себя:

Код: Выделить всё

$TTL 300
klient.55.44.123.in-addr.arpa.	IN	SOA	ns.klient.ru. hostmaster.klient.ru. (
			2009012502	;serial
			7200		;refresh
			900		;retry
			2592000		;expire
			3600		;neg. ttl
			)
		NS	ns.klient.ru.
		NS	ns2.hosting.com.

7.klient.55.44.123.in-addr.arpa.	PTR	host1.klient.ru.
8.klient.55.44.123.in-addr.arpa.	PTR	host2.klient.ru
9.klient.55.44.123.in-addr.arpa.	PTR	host3.klient.ru
10.klient.55.44.123.in-addr.arpa.	PTR	host4.klient.ru
11.klient.55.44.123.in-addr.arpa.	PTR	host5.klient.ru
12.klient.55.44.123.in-addr.arpa.	PTR	host6.klient.ru
13.klient.55.44.123.in-addr.arpa.	PTR	host7.klient.ru
14.klient.55.44.123.in-addr.arpa.	PTR	host8.klient.ru

Типа вот так

---

Эво оно как меня поперло про DNS строчить Это неспроста... Че еще написать?

[Rusya]

Подобного ответа на форумах давно не встречал, спасибо конечно за ответ он был исчерпывающим пойдусегодня долбить своего прова

P.S. по мойму это была бы не плохая статья, но хотелось бы в качестве примеров увидеть все же djbdns настройки

[terminus]

На счет развернутости ответа - меня Лиссяра сагетировал.

djbdns это отдельная песня Он у вас уже поставлен и запущен или еще нет? Ставили из портов или из сырцов? Все ли необходимые для djbdns (tinydns) компоненты установлены:
- daemontools
- ucspi-tcp
- run скрипт для запуска tinydns через daemontools
Насколько я помню установка djbdns происходит в /var/tinydns и в /var/service. У вас так?

[Rusya]

На счет развернутости ответа - меня Лиссяра сагетировал.

djbdns это отдельная песня Он у вас уже поставлен и запущен или еще нет? Ставили из портов или из сырцов? Все ли необходимые для djbdns (tinydns) компоненты установлены:
- daemontools
- ucspi-tcp
- run скрипт для запуска tinydns через daemontools
Насколько я помню установка djbdns происходит в /var/tinydns и в /var/service. У вас так?

djbdns уже стоит и настроен и смотрит на внутреннюю сеть со всеми компанентами собран из сырцов и так далее все гуд иной раз приходится добавлять очередной сервис и прописывать его под новым именем, но это уже не проблема. Видимо есть еще много всяких примеров работы djbdns, но как практика показала с трудом в ней разбираюсь.

[terminus]

Ну если у вас уже работает сервер то видимо разобрались как к нему подключаются файлы с данными и как происходит управление настройками (каталог /var/tinydns/env и конфигурационные файлы в нем). Много чего полезного про djbdns уже написано например тут http://www.lifewithdjbdns.com - из этого я ничего нового не придумаю.

Единственное, что могу добавить это то, каким образом поддерживать удобную систему файлов с данными из множества зон раскиданных по директориям. Сервер tinydns в своей работе использует специальную базу данных в формате CDB. Чтобы эту базу создать используют команду tinydns-data. Так вот, когда на сервере запущено много доменов то держать их файлы с данными удобнее в отдельных каталогах, а не все в одном файле. Обычно в таких условиях создавали структуру директорий вида:

Код: Выделить всё

/var/tinydns/zones/master/klient.ru/klient.ru.txt
/var/tinydns/zones/master/domen.ru/domen.ru.txt
...

/var/tinydns/zones/slave/klient2.com/
/var/tinydns/zones/slave/klient3.net/
...

соответсвенно в директориях ./zones/master/ хранились данные зон для которых сервер был мастером, а в директории ./zones/slave/ с помошью axfr-get автоматически стягивались и сохранялись данные зон для которых сервер был слейвом.
Чтобы автоматизировать процесс создания файла-базы data.cdb удобно применять например такой скрипт:

Код: Выделить всё

#!/bin/sh
DNS=/var/tinydns
# Updating local
cd $DNS/root
cat ../zones/master/*/* ../zones/slave/*/* > data.tmp 2>/dev/null
mv data.tmp data
/usr/local/bin/tinydns-data
echo "Local config updated"

Он проходит по всех структуре поддиректорий в ./zones/ и делает из всех текстовых файлов один большой текстовый файл data который потом скармлевается tinydns-data и получается data.cdb.

tinydns довольно аскетичная вешь! Там все руками надо было делать... Чтобы забирать данные от мастеров надо было конфигурировать и запускать отдельную программу axfr-get, причем делали отдельный скрипт который автоматически проходил по структуре директорий в ./zones/slave/ и подключался к мастерам. Чтобы отдавать данные слейвам работающим под BIND опять же надо было конфигурировать и запускать отдельно axfrdns.
Чтобы обеспечить репликацию между двумя серверами работающими под tinydns так тоже отдельным скриптом делали rsync через ssh (копировали с мастера на слейв базу data.cdb). Наверное из-за этого я в конце-концов на Unbound с NSD и переполз - мне надоело

[Гость]

по nsd скудная документация
на оф сайте практически ничего нету
в djbdns, конкретно tinydns есть удобная штука как client location
используя её можно возвращать адреса в зависимости от адреса клиента
удобно, когда есть внутренняя и внешняя сеть
существует ли такая возможность в nsd?
про то что можно поднять два dns сервера знаю, но хотелось бы сделать все на одном
и другой вопрос: где можно найти документацию по nsd?

[exp.]

моя невнимательность
прочитал заметку про nsd и все подтвердилось
в качестве решения можно использовать локальные зоны в unbound, который предполагается установить в паре с nsd

[eex]

Не сочтите за некропостера - наткнулся на статейку только что.
Сейчас разбираюсь с работой DNS, и есть несколько непонятных моментов.
Ситуация такова - провайдер делегировал мне зону zone.gorod.ru, я поднял BIND и настроил все аккурат как расписано и у вас, после чего клиенты, у которых прописан мой DNS стали прекрасно разрешать имена в зоне zone.gorod.ru. Однако снаружи никто мою зону не увидел, пока я не прописал в конфиге BIND для моей зоны директиву allow-transfer для вышестоящего DNS сервера провайдера, который обслуживает зону gorod.ru. Почитав документацию на эту тему мне показалось, что для корректной работы вышестоящему DNS серверу должно быть достаточно allow-query, и админ провайдера что-то перемудрил с настройками, Вот и решил уточнить так ли это на самом деле. У вас в статейке нет листинга named.conf и этот момент не раскрыт вовсе.

[hizel]

смотрите

Код: Выделить всё

dig +trace  any.zone.gorod.ru

[Al]

Не сочтите за некропостера - наткнулся на статейку только что.
Сейчас разбираюсь с работой DNS, и есть несколько непонятных моментов.
Ситуация такова - провайдер делегировал мне зону zone.gorod.ru, я поднял BIND и настроил все аккурат как расписано и у вас, после чего клиенты, у которых прописан мой DNS стали прекрасно разрешать имена в зоне zone.gorod.ru. Однако снаружи никто мою зону не увидел, пока я не прописал в конфиге BIND для моей зоны директиву allow-transfer для вышестоящего DNS сервера провайдера, который обслуживает зону gorod.ru. Почитав документацию на эту тему мне показалось, что для корректной работы вышестоящему DNS серверу должно быть достаточно allow-query, и админ провайдера что-то перемудрил с настройками, Вот и решил уточнить так ли это на самом деле. У вас в статейке нет листинга named.conf и этот момент не раскрыт вовсе.

Перемудрил. Трансфер только на вторичные сервера. Из соображений безопасности. Провайдера это вообще никак не должно касаться.
Проверяй, какие сервера держат твой домен снаружи. Не провайдерские ли?