На днях внимательная коллега (спасибо, Лена) зарепортила странный баг — сервер нормально ставил куку в браузере, но обратно она не прилетала. Днём ранее всё работало, теперь же кука выставлялась, но спустя несколько секунд магическим образом пропадала (хотя должна держаться сутки). Воспроизводилось это всего у нескольких человек в команде и только в новом Chrome 80, но у остальных в Chrome точно такой же версии всё было в порядке. В других браузерах всё работало как часы. Мистика. Начали разбираться, и спустя какое-то время в консоли Chrome заметили предупреждение для заголовка ответа, устанавливающего куки:

A cookie associated with a cross-site resource at _your_domain_ was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`.

Начали изучать что это такое, и постепенно стало понятно, как ошибка возникла и почему проявлялась не у всех. Поскольку наш сервис должен обрабатывать запросы с разных доменов, то SameSite — как раз наш случай. Добавили SameSite=None; Secure, и проблема для нас решилась.

Почему так?

Понесло пакет по кочкам в дальний лес за DNS…
Л. Каганов "Гамлет на дне"

При разработке сетевого приложения иногда возникает необходимость запустить его локально, но обращаться к нему по реальному доменному имени. Стандартное проверенное решение — прописать домен в файле hosts. Минус подхода в том, что hosts требует чёткого соответствия доменных имён, т.е. не поддерживает звёздочки. Т.е. если есть домены вида:

dom1.example.com,
dom2.example.com,
dom3.example.com,
................
domN.example.com,

то в hosts нужно прописать их все. В отдельных случаях, домен третьего уровня не известен заранее. Возникает желание (пишу за себя, кто-то, возможно, скажет, что и так нормально) обойтись строкой вида:

*.example.com

Решением проблемы может стать использование собственного DNS-сервера, который будет обрабатывать запросы в соответствии с заданной логикой. Такие сервера есть, и вполне бесплатные, и с удобным графическим интерфейсом, например CoreDNS. Так же, можно менять DNS-записи на роутере. Наконец, воспользоваться сервисом наподобие xip.io, это не совсем полноценный DNS-сервер, но для некоторых задач отлично подойдёт. Словом, готовые решения существуют, можно использовать и не заморачиваться.

Но в этой статье описан другой путь — написание собственного велосипеда, стартовая точка для создания инструмента наподобие перечисленных выше. Мы напишем свой DNS-прокси, который будет слушать входящие DNS-запросы, и если запрашиваемое доменное имя есть в списке, вернёт заданный IP, а если нет — запросит вышестоящий DNS-сервер, и переправит полученный ответ без изменений запрашивающей программе.