Как стать автором
Обновить

Комментарии 17

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

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

Вот есть у нас DNS, он "просто работает". ААА, ужос - несекурно же! Ок, запилили "DNS secure" - пользуйтесь. Фи, сложно... Мы ща сами запилим безопасность! Получите ещё и HTTPS или TLS на выбор, теперь у вас уже целых три "безопасных" протокола: всё инклюзивно, как сейчас модно! Ну а что админы вешаются - да кому это интересно, главное что очередной гугл продвинул свой собственный "стандартик": ставьте Хром и будет вам счастье.

FTP? Он то же слишком простой, давайте его обезопасим! Вжух - и теперь у вас есть ещё и FTPS и SFTP на выбор, радуйтесь! Что, ничего не работает? Ну так это вы устарели, фу таким быть. Ставьте хром пользуйтесь вот этой одной программой, и всё будет хорошо!

А, ещё получите HTTPS. Что значит "не просили"?! Мы лучше знаем, что вам надо - не спорьте. А противный слишком простой HTTP мы запретим, во имя светлого будущего! Да, и не забудьте поставить Хром - только в нём "всё работает хорошо быстро" © (не является публичной офертой).

Как-то так )))

Я не мастак в хихишечки, поэтому пройдусь по матчасти:


Вот есть у нас DNS, он "просто работает".

Черта с два он просто работает. Провайдеры типа "Дом.ру" не позволят вам пульнуть DNS-запрос на произвольный сервер. Они принудительно перехватывают его и отвечают вам сами. И если этот запрос про домен, доступа к которому, по мнению надзорного органа, вы иметь не должны, вместо адреса домена вы получите адрес заглушки провайдера с текстом "Не рыпайся, не положено".


Ух, как классно работает!


Ок, запилили "DNS secure" — пользуйтесь. Фи, сложно… Мы ща сами запилим безопасность! Получите ещё и HTTPS или TLS на выбор, теперь у вас уже целых три "безопасных" протокола: всё инклюзивно, как сейчас модно!

Сложность тут не при чём. DoH/DoT были созданы, потому что DNSSEC решает лишь задачу "обеспечить защиту от подделки", но не скрывает содержимое запросов. Он такого не умеет в принципе, потому что создавался в гораздо более травоядные времена, чем сейчас.


FTP? Он то же слишком простой, давайте его обезопасим! Вжух — и теперь у вас есть ещё и FTPS и SFTP на выбор, радуйтесь!

SFTP не имеет никакого отношения к FTP.


А, ещё получите HTTPS. Что значит "не просили"?!

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

Про "хихишечки" напомнило мем про "когда прошло уже 15 минут, а ты не сказал никому ни разу, что ты веган". Ах да, вы же не мастак в этом - сорян ;)

Черта с два он просто работает. Провайдеры типа "Дом.ру" не позволят вам пульнуть DNS-запрос на произвольный сервер <...>

Какое отношение к простоте работы протокола DNS имеют действия вашего провайдаре по злонамеренному искажению/изменению его функционала?

С таким же успехом блокировку доступа к сайту целиком по его IP-адресу со стороны Роскомнадщора можно объявить недостатком протокола HTTPS. Ну а что? Ну или если свич сгорел, и "интернета нету" - это то же из-за того, что DNS "не работает", правильно? Ведь не работает же DNS?

SFTP не имеет никакого отношения к FTP

Ой, ну да ладно... Он для передачи файлов? Для передачи. В названии есть *FTP*? Есть. Значит имеет отношение.

А то следуя вашей логике - то и DNS over HTTPS/TLS то же никакого отношения к DNS не имеет. Ибо только решает аналогичную задачу разрешения имени в IP, а под капотом - там вообще всё другое.

Другие порты, протоколы - всё. Но DNS жеж? То то.

Остальные криптоужасы про "кровавую гебню"... Если вы любите воблу - то либо любите её молча, либо любите её в другом месте, либо - если любовь горит в груди, и нет сил молчать (я серьёзно, без хихишечек) - то будьте готовы принять все последствия публичной любви к вобле в мире пусть и виртуальном, но уже - в реальном (это про последствия). Увы, ни HTTPS, ни DoH/DoT вас от последствий не оградят никак.

Жизнь такая, реальность. Да и какой прок будет для воблы, если вы объяснитесь в любви к ней стыдливо-анонимно через три VPN-на? Никакого проку не будет, самообман один. Протухнет ваша вобла от любви такой анонимной.

Это я не к тому, что вобла плохая - норм рыба, хотя мне больше тарань по душе. А к тому, что иллюзия безопасности - сильно хуже пусть и опасности, но которую знаешь и к которой готов.

Ставьте Хром Всем пис ;)

Ну что поделаешь - фактически все core network protocols в чистом виде категорически неадекватны современным реалиям - DNS, SMTP, HTTP, LDAP, FTP (Мхва-ха-ха!) - без десятков костылей и сотен мотков изоленты - кромешный ужас с, подчас, почти исчерпанным потенциалом для улучшения.

Попытки "сделать с нуля и правильно" конечно предпринимаются (См. тот же http2 или doh) - но понятие "правильно" у нас с вами и FAANG могут категорически не сходиться ).

dig @8.8.8.8 domain.name +trace прекрасно помогает определить источник проблемы, и дальше уже точечно её решать

Собственно, читая статью, я и ожидал увидеть этот флаг. Добавляешь его и видишь всю цепочку... Один флаг и вот ответ.

… если ты не пользуешься пчелайном.
у меня уже было, что с +trace ответ есть, а напрямую — NXDOMAIN или SERVFAIL, не помню.


и вот аналогичная проблема у народа была, например https://vc.ru/u/1161799-pleomaxtor/450901-bilayn-i-oshibka-dns

Так и правильно. +trace покажет правильность конфигурации резолва минуя точки кеширования. То что провайдеры могут излишне кешировать - это не победить, к сожалению. Только ждать. Кстати, в приведенной заметке галочка про трассировку не установлена (на скринах).

ну в таком случае у еблайна перманентное кеширование местами, тк проблема идет неделями-месяцами-годами.

Я тоже ждал этот флаг, но тут два варианта, либо аФФторка о нём не узнала ща 5ть лет, либо проблема о которой она написала значительно глубже и данный флаг "припёздывает". В моей практике были случаи, когда по трэйсу всё норм, а по факту где то не ходит.

В коньоре где сейчас работаю ЗАКРЫТ UDP, только 53 tcp открыт - dig без флагов НЕ работает, нужно принудительно +tcp указывать. А добиться работы bind даже с опциями приоритета tcp не получилось - чего нет по udp, того не существует ?

Сложно изучать по причине отсутствия вменяемой документации и нормальных учебников. То, что есть, оно либо безнадёжно устарело, либо слишком поверхностно.
Описывается "сферический DNS в вакууме" вместо конкретных наиболее распространённых нюансов его реализации и основных практик, используемых наиболее крупными провайдерами/хостерами. В итоге под 80% всей информации приходится собирать по крупицам, часто путём экспериментов.

А есть ли способ узнать какие поддомены есть у конкретного домена?

Когда пытался найти ответ на этот вопрос, ничего не обнаружил

Нет. Можно только найти в поисковиках те, которые засветились там.
Физически протокол для получения всех поддоменов есть, но используется только для синхронизации зон между ns серверами, отвечающими за конкретный домен. Пользователям он недоступен.

Чисто технически в редких случаях, когда зона подписана DNSSEC без использования NSEC3, можно, зная один субдомен, произвести zone-walking и спарсить все субдомены.

К сожалению, данная заметка Юлии чересчур поверхностная и может вводить в заблуждение.

Например, про вызов getaddrinfo(). Из "заметок на полях":

  • Если на запрашивающем хосте запущен nscd, все ответы кэшируются на 60с и
    подставляются в запросы "getaddrinfo()" через перехват стандартной
    функции. А этот глюкодром до сих пор стартует "искаропки" на моей любимой openSUSE. Но нет худа без добра: в 2016 году nscd помешал кой-чего проэксплуатировать. В том самом getaddrinfo() из тогдашней glibc. …Понятно что при этом RR ломается.

  • Сам getaddrinfo() таки делает RR. Но вот сюрприз: какой-то шибко-вумный программист разбил возвращаемые записи по "классам". Как я помню (сейчас лень искать), там как-то считается "удалённость" адресов и RR выполняется для "равноудалённых".

Вообще, касающиеся DNS RFC достаточно конкретные, но да, чересчур обширные. И продолжают выходить новые правки. И это весьма стимулирует "юных DNS-писателей" (сам такой, было дело) забивать на "ненужные" подробности. Как пример, яндексовские резолверы. (По-русски их принято писа́ть через "з", по аналогии с "резолюцией.) Кто-то когда-то написал как понимал, а потом видимо пошёл заниматься ещё чем-то. И теперь некому найти/исправить "вечный кэш" для glue-записей. (Моя контора посылала им разбор, но в итоге была послана обратно.)

Oops… Про RR держал в уме ещё вот эту заметку той же Юлии. Это там она жаловалась что "round robin DNS doesn’t work with getaddrinfo".

На днс РР никогда не работал, сейчас потихоньку двигаются к исправлению этого, но только идиоты пытаются сделать РР на днс сегодня.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории