[alibek]

Столкнулся со странным поведением DNS-сервера.

 

Есть такая конфигурация:

server:
       port: 5353
...
pattern:
       name: "public"
       rrl-whitelist: nxdomain

zone:
       name: "domain.ru."
       zonefile: "zones/zone-public"
       include-pattern: "public"

zone:
       name: "domain.com.ru."
       zonefile: "zones/zone-public"
       include-pattern: "public"

 

И такая зона:

$TTL 1h

@   IN SOA    ns root    (20141031001 1d 6h 1w 1h)
      NS     ns
      NS     ns01
      NS     ns02
      A      127.0.0.1
ns     A      aa.aa.aa.1
ns01   A      aa.aa.aa.1
ns02   A      aa.aa.aa.124
...
test           A     aa.aa.aa.99
*.test         CNAME test
...
domain.com.ru.     A     aa.aa.aa.100
                  MX 10 mx.yandex.ru.
www.domain.com.ru. CNAME domain.com.ru.
...
mail.domain.ru.    CNAME ghs.l.google.com.
...

 

Зоны domain.ru и domain.com.ru идентичны, за исключением того, что в есть несколько записей, которые присутствуют в одной зоне и отсутствуют в другой зоне.

При старте сервиса в логах появляются записи типа "error: zones/zone-public:42: out of zone data", поскольку RR с полным именем в данном случае выходит за пределы зоны. Но насколько я понимаю, в этом случае подобные записи игнорируются, что меня устраивает.

 

Однако странность заключается в следующем.

 

# dig @10.1.128.12 -p 5353 test.domain.ru

; <<>> DiG 9.10.2 <<>> @10.1.128.12 -p 5353 test.domain.ru
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24443
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;test.domain.ru.                        IN      A

;; ANSWER SECTION:
test.domain.ru.         3600    IN      A       aa.aa.aa.99

;; AUTHORITY SECTION:
domain.ru.              3600    IN      NS      ns.domain.ru.
domain.ru.              3600    IN      NS      ns01.domain.ru.
domain.ru.              3600    IN      NS      ns02.domain.ru.

;; ADDITIONAL SECTION:
ns.domain.ru.           3600    IN      A       aa.aa.aa.1
ns01.domain.ru.         3600    IN      A       aa.aa.aa.1
ns02.domain.ru.         3600    IN      A       aa.aa.aa.124

;; Query time: 0 msec
;; SERVER: 10.1.128.12#5353(10.1.128.12)
;; WHEN: ср апр 08 17:39:55 MSK 2015
;; MSG SIZE  rcvd: 208


# dig @10.1.128.12 -p 5353 test.domain.com.ru

; <<>> DiG 9.10.2 <<>> @10.1.128.12 -p 5353 test.domain.com.ru
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 36173
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;test.domain.com.ru.             IN      A

;; Query time: 0 msec
;; SERVER: 10.1.128.12#5353(10.1.128.12)
;; WHEN: ср апр 08 17:40:15 MSK 2015
;; MSG SIZE  rcvd: 46

 

Почему запрос на test.domain.ru выполняется, а на test.domain.com.ru не выполняется?

[vop]

Видимо, потому, что он отбрасывает кривые зоны. Сомневаюсь я, что он может игнорировать отдельные записи.

[alibek]

Тогда бы ни одна зона не загрузилась.

А ведь первая зона обрабатывается нормально.

[vlad11]

Замените на named.

[alibek]

У меня на одном сервере все еще BIND работает, там все хорошо.

Но он тяжелый и не без глюков.

Поэтому я его заменяю на связку NSD/Unbound.

Связка работает лучше, но иногда вылезают особенности, как сейчас.

[vlad11]

Поэтому я его заменяю на связку NSD/Unbound.

Связка работает лучше, но иногда вылезают особенности, как сейчас.

 

Это ваши проблемы. bind работает как часы в самых разнообразных схемах использования.

[pavel.odintsov]

NSD рулез - 224 000 зон в режиме авторитативного сервера, выкидывайте Bind на свалку (на 30 000 доменов он у меня загржался 30 минут - это норм вообще? Я уже молчу про спорадические зависания и адо-подобные конфиги).

 

NSD выкидывает зону целиком, да - там компилятор зон так устроен. Но прежде чем коммитить изменения в файл зоны - не мешало бы его проверять спец тулзой от nsd - zone_checker, она в коде лежит. Она сильно жестче к ошибкам и бреду нежели похожая тулза от named.

[alibek]

NSD выкидывает зону целиком, да - там компилятор зон так устроен.

Странно, почему же тогда первая зона ресолвится?

Что ж, видимо придется использовать разные файлы зон для разных зон.

В BIND было удобно, что он может игнорировать отдельные RR, а не зону целиком.

[pavel.odintsov]

Вот поподробнее от авторов NSD: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=607

[vlad11]

NSD рулез - 224 000 зон в режиме авторитативного сервера, выкидывайте Bind на свалку (на 30 000 доменов он у меня загржался 30 минут - это норм вообще? Я уже молчу про спорадические зависания и адо-подобные конфиги).

 

А теперь подскажите, скольки организациям в стране надо обслуживать овер 200K зон?

 

Файлы зон можно положить на ssd, сами зоны положить в LDAP или Mysql. И потом правильно организовать обновление зон, а не использовать опцию restart.

[zi_rus]

 

А теперь подскажите, скольки организациям в стране надо обслуживать овер 200K зон?

То есть те, кому не надо 200к зон, должны использовать бинд просто потому что?

[vlad11]

 

А теперь подскажите, скольки организациям в стране надо обслуживать овер 200K зон?

То есть те, кому не надо 200к зон, должны использовать бинд просто потому что?

 

А потому что некорректная постановка задачи.

bind - стандарт в ДНС.

[GrandPr1de]

bind - стандарт в ДНС.

А с чего бы это вдруг бинд стал стандартом? То что он в той же фре до 10 версии шел в комплекте? :)

То что он просто популярный - от этого стал стандартом?

[Ivan_83]

То что он просто популярный - от этого стал стандартом?

1. Раньше альтернатив не было.

2. Его пилит ISC, у них основная задача 100% следовать RFC, остальное вторично.

[GrandPr1de]

ISC, у них основная задача 100% следовать RFC, остальное вторично.

ну вот этого не знал, спасибо

[Phantasm]

Присоединюсь к советующим выкинуть NSD и поставить BIND. У меня на нём NS-ы, обслуживающие ~300к зон: никаких проблем, кроме долгой загрузки. Стартует примерно 20 минут на sata 7200 дисках, и это понятно - ему нужно кучу файлов пропарсить.

[pavel.odintsov]

А какие проблемы с NSD-то? Не парсить битый конфиг зоны - это с каких времен стало серьезной проблемой? На NSD работает 90% root-dns. И лишь от силы 10% на Бинде. По-моему, лучшего краш теста и сравнения "кто лучше и надежнее" не придумать.

 

Тот же L-root целиком и полностью NSD: http://www.dns.icann.org/index.html%3Fp=3.html тоже самое по K http://k.root-servers.org. Bind - это жуткое нагромождение крапа в коде, огромное количество совеершенно не нужных авторитативнику функций и пагубное по дизайну совмещение рекурсора и авторитативника.

[alibek]

Не нужно меня агитировать за NSD.

У меня используется оба варианта (BIND и NSD/Unbound) и связка NSD/Unbound мне нравится больше.

Но вот то, что он выкидывает зону целиком, это неудобно в моем случае.

У меня одна зона почти полностью должна повторять другую зону (за некоторыми исключениями), а из-за такой особенности я не могу использовать один файл на обе зоны.

BIND удобен для тестовых и временных схем, именно тем, что у него все в одном и все мыслимые возможности.

 

P.S. А почему authoritative называют "авторитативным"? Ведь это "авторитетный".