Comments 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 серверами, отвечающими за конкретный домен. Пользователям он недоступен.
К сожалению, данная заметка Юлии чересчур поверхностная и может вводить в заблуждение.
Например, про вызов 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".
Почему DNS по-прежнему сложно изучать?