Комментарии 23
Вставлять xkcd-комикс и не писать alt-сообщение — нехорошо, не надо так.
The less popular 8.8.4.4 is slated for discontinuation
А за статью — спасибо, ни разу не слышал про Chaosnet.
Ещё помню какую-то пасхалку, в которой при tracert до определнного ip icmp-пакеты шли сквозь кучу виртуальных коммутаторов, чьи доменные имена печатали звёздновойнную A long long time ago in a galaxy far far away.
Пасхалка для недругов (c нецензурщиной)
➜ ~ dig A eblan.us +noall +answer
eblan.us. 21539 IN A 127.0.0.1Домен зарегистрирован с 2004-го года и регулярно продлевается. Спасибо регистратору за удобный алиас для локалхоста.
Интересная идея использовать ДНС для передачи данных, и реализовать не так сложно. Правда не совсем понятно кто будет это использовать. (Кроме как в шутку)
Подобные протоколы взаимодействия реализованы и в СМС и в каждой сим карте можно заказать смс с курсом, балансом или анекдотом. Подозреваю, что мало кто этим пользуется.
Я взял на заметку. выглядит так, как будто очень просто скриптом получить данные по погоде\курсу а потом их распарсить.
И да и нет. Думаю, что какой-нибудь апи Яндекс-погоды или Гисметео сможет помочь вам значительно лучше, а главное благодаря большой распространенности вы не столкнетесь с необходимостью переделывать ваш скрипт ночью в воскресенье, потому что авторы решат отключить интерфейс .
Я не программист. Но периодически маленькие программки для себя пишу.
Так вот, если я в своей программке начинаю использовать незнакомое API то как правило больше половины времени я затрачиваю на то, чтобы понять как с этим API работать. За того-же телеграм бота я не брался до тех пор пока не нашёл сторонний код, которому парсит ответ боту и возвращает собственно написанное сообщение.
P.S. Это для home use. поэтому ночью в воскресенье переделывать точно не буду.
Ну, с этим не поспоришь. Хотя есть у меня пара аргументов.
Специализированные сервисы зачастую дают более актуальную информацию.
У распространенных сервисов есть уже написанные парсеры и готовые программы обработчики, а это удобно. Залез в код, подкорректировал под себя, да еще и подучился у автора.
Я ведь тоже не программист.
Вот пример : https://www.gismeteo.ru/api/
Там ответ похоже стандартный жсон, который уже практически стандарт и работает даже в утюгах.
Единственное что нужно получить, токен, который для домашнего использования скорее всего бесплатный.
А если днс сервис станет очень распространенным, то и там эта байда с токенами появится...
>Правда не совсем понятно кто будет это использовать. (Кроме как в шутку)
Ну есть например туннель через DNS, о нём и на хабре писали - https://habr.com/ru/post/129097/
Скоростей там впечатляющих ждать, понятное дело, не стоит
Офигенная статья, спасибо. Я с прочтения текущей думал можно ли организовать нечто подобное и в рассуждениях утыкался в текстовую природу данных. Т.е. очевидно, что любой канал передачи данных можно задействовать для передачи трафика интернет. (Даже голубиную почту). Я помню в 90е годы были провайдеры, которые предоставляли dialup к своим почтовым серверам. И тогда периодически появлялись протоколы проксирования http через почтовые запросы. Но о DNS всегда думаешь в режиме TTL 3600 ну или на крайний случай TTL 1800. А тут похоже что TTL 1.
Правда скептически отношусь к подобной затее. По факту ДНС вместо работы в качестве очень быстрого конвертера имени сервера в IP превращается в proxy и его скоростные характеристики для всех пользователей падают.
А ограничения скорости на самом деле практически нет, так как с днс можно открывать массу соединений.
DNS очень удобная штука.
В свое время делал реализацию для авторизации в админку сайта по хешу, который действовал в течение суток и проверялся как раз через технический поддомен в DNS, при использовании недокументированного URL.
Особенно это давало хороший рычаг, ставить на место клиентов, которые любят не оплачивать за выполненные работы. Пару раз пришлось прибегнуть к этому методу для реализации ранее достигнутых договоренностей.
Не очень понял какое преимущество дает в этом вопросе именно DNS.
Вы с тем же успехом могли бы использовать любой другой протокол передачи данных и, подозреваю, чем более стандартный метод вы бы использовали тем легче было бы поддерживать работоспособность подобной системы.
вы кладете в dns ключ с привязкой к конкретному сайту/домену, и не имея доступа к сайту и его базе, авторизуетесь через dns
С таким же успехом ваш ключ может лежать на любом сервере авторизации и быть привязан к любому набору данных.
в этом и прелесть, что он живет в днс, который нельзя заблокировать фаерволом
Как я понимаю ваша задача - короткий поводок для пользователя, гарантирующий оплату.
Звучит это приблизительно так же грустно как и использование нестандартного метода авторизации.
Оба эти факта признаки серьезных недостатков в процессе взаимодействия с пользователем и самой структуры вашего продукта.
Когда вы пишете "ваши боевые сервера" вы не замечаете что милитаризация сознания зашла слишком далеко?
Пасхалки в DNS