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

Max Tulyev maxtul at netassist.kiev.ua
Sun Dec 11 22:31:56 EET 2022


DNSSEC тут был бы очень в тему ;)

08.12.22 12:18, 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-
> _______________________________________________
> uanog mailing list
> uanog at uanog.kiev.ua
> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog


More information about the uanog mailing list