[uanog] Странности современного резолвинга и как их понимать и диагностировать

[Valentin Nechayev]

hi all,
столкнулся с такой ситуацией. Имена/IPs не секрет, но замаскированы чтобы
не влезать в лишние в общем случае подробности, если надо - открою.
Есть домены buka.kiev.ua и zuka.kiev.ua. Из авторитетных
серверов kiev.ua выбираю для определённости nn.ns.ua (не думаю, что
есть существенная разница, поправьте, если что).

$ dig @nn.ns.ua buka.kiev.ua a

;; AUTHORITY SECTION:
buka.kiev.ua.       28800   IN      NS      ns11.zuka.kiev.ua.
buka.kiev.ua.       28800   IN      NS      ns22.zuka.kiev.ua.

;; ADDITIONAL SECTION:
ns11.zuka.kiev.ua.         28800   IN      A       10.1.0.1
ns22.zuka.kiev.ua.         28800   IN      A       10.2.0.2 <-- ???

Повторный запрос показывает точно такой же TTL - значит, сервер отдаёт
то, что считает авторитетным данным. Как я подозреваю, это идёт из
какой-то glue record.

В то же время, если делать прямой запрос ns22.zuka.kiev.ua, nn.ns.ua
редиректит:

;; AUTHORITY SECTION:
zuka.kiev.ua.              28800   IN      NS      ns1.the-registrar.ua.
zuka.kiev.ua.              28800   IN      NS      ns2.the-registrar.ua.

И уже эти NSʼы отвечают другим IP, который и ожидается:

;; ANSWER SECTION:
ns22.zuka.kiev.ua.         3600    IN      A       10.3.0.3 <-- OK

Вот тут "меня начинают терзать смутные сомнения". Отдача записи glue в
additional - норма начиная со времён где-то ISC BIND 9.4, когда начали вполне
справедливо параноить на тему кэша и опасных записей в нём. Но почему
эта запись вообще появляется тут? Клеевые записи должны применяться,
по новым положениям, только для резолвинга того домена, к которым они
относятся, не так ли? То есть, если рекурсор пошёл резолвить
buka.kiev.ua, он должен добраться до того, кто авторитетно (не из
glue) отвечает IP для ns22.zuka.kiev.ua, и уже получив эти данные идти
резолвить что-то из buka.kiev.ua? А промежуточные авторитетные
отдатчики зон не должны отвечать записями, которые не относятся к их
компетенции?

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

И следующий технический вопрос тогда к Хостмастеру. Вы фильтруете
подаваемое от регистраторов на предмет чужих glue (не относящихся к
управляемому домену)?
Если да, какой механизм возникновения описанной выше ситуации?
Если нет, то почему?


-netch-