Wire format выбрали vs JSON (рассматривался как вариант).
Google внедрил JSON в 2016 до того как DoH был стандартизирован. В данный момент «выключать» его они пока не собираются, но это вполне возможно. developers.google.com/speed/public-dns/docs/doh/migration
Wire format имеет преимущество, так как в случае с DoT может использоваться для трансфера DNS зон. DoH к сожалению для трансфера зон не может использоваться из-за ограничений по длине HTTP-пакета.
30мс — это уровень комфортного использования (хотя чем быстрее, тем лучше). Больше 50мс уже нежелательно. Вот интересное исследование (хотя уже и немного устаревшее) на сравнение протоколов и влияние на загрузку web в зависимости от условий.
Насколько я знаю стандарта DoH over QUIC/HTTTP/3 еще не приняли.
Наиболее простой способ для реализации на уровне DNS сервера использовать готовые библиотеки (TLS, HTTPS и т.д.), так как DNS пакет (с минимальными изменениями) просто «завернуть» в другой протокол вместо UDP/TCP.
Ping это утилита, которая в данном случает измеряет сетевую задержу с помощью ICMP пакетов. ICMP показывает только приблизительно насколько «далеко» находится сервер. Но так как это другой тип пакета (в большинстве случаев имеет наименьший приоритет — почитайте по QoS), другой размер, то результаты на загруженных сетях могут значительно отличатся. + естественно никак не измеряется задержка на самом сервисе DNS (один может отвечать из кэша с 5нс, а другому будет требоваться из-за нагрузки 50мс).
2. Реализовать проверку достаточно просто:
— интеграция DNS с их страницей проверки
— выдавать различные IP/CNAME в зависимости как тот же самый запрос ресолвится (хотя если посмотреть активность даже в developer tools видно, что используют разные адреса).
После этого на странице проверки достаточно выполнить несколько GET запросов для «скачивания» удаленного объекта.
Не все приложения хорошо это переваривают в результате чего страдает пользователь.
Например, при соединении с хабром ресолвится 9 доменов. Ну других сайтах доменом может быть гораздо больше.
Проблемы будут у всех.
И у тех, кто пытается защитить корпоративные сети (как пример — в день когда Mozilla официально запустила DoH в США, был обнаружен вирус, который использует DoH).
У «товарища майора», который будет известным способом пытаться решить эту проблему.
А так же естественно у пользователей, которые хотят защитить свою последнюю милю.
Статья называется «Как идет внедрение», но тема нифига не раскрыта. Это не в плане, как установить свой DoH прокси, а именно, сколько процентов пользователей уже
перешли на DoH (добровольно или принудительно).
Приведена информация о поддержке браузерами и т.д. и т.п. Какой процент пользователей перешел на DoH — ничего, какие провайдеры тестируют — ничего, кто уже предлагает (кроме Cloudflare и Google) — тоже ничего. Поэтому я и написал, что пост ни о чем…
У «пол страны» нет микротиков + заниматься этим будут только те, кто понимает, что это такое. Ну и в любом случае если используешь публичные DoH сервера ты свои запросы сливаешь «большому брату», так как пока нет авторитативных серверов поддерживающих DoT/DoH. В этом смысле DNS какого-нибудь маленького провайдера может более приватным, чем гугловский DoH. Самое оптимальное иметь свой DNS где-нибудь в удаленном Cloud (например бесплатная VM от Oracle вполне подойдет).
+ Реализация DoH на маршрутизаторе (без фильтрации трафика) тебя не спасет от устройств/приложений/вирусов которым вдруг вздумается напрямую общаться с другим DoH.
Я на своем DNS (open source проект) я реализовал DoT почти 1.5 года назад, а DoH чуть меньше года назад. Сложного в этом ничего нет.
Если по теме, то есть большое сомнение, что Mozilla будет активно пихать это решение в РФ. Судя по тому как они просто отказались от внедрения DoH в UK можно судить, что в других странах, кому это не нужно, (например РФ) произойдет тоже самое.
В данный момент Mozilla пушит DoH только в США (правда доля рынка FF мала), скорее всего Mozilla и Cloudflare (они активно пропихивали RFC — приняли где-то за год или полтора) просто захотели получить как минимум американский рынок DNS, где полученные данные можно хорошо монетизировать.
Это противоречит RFC (стандарту). Хочешь изобретать велосипед — изобретай, тебя никто не ограничивает, но применимость решения будет крайне ограниченным.
Стоимость решения DPI на весь провайдерский трафик с учетом внедрения 5g будет неподъемным.
Проблемы начинаются, когда какой-нибудь начнет смешивать остальной контент с DoH. Например, google.com будет отвечать на DNS запросы + закриптованный SNI. Такой трафик можно профайлить, но блокировать будет сложно.
За русскоязычными стартапами — звоните в Сколково :)
Тут официально не могут нанимать только по знание какого-то языка, если это не требуется в работе (это ещё бывает доказать нужно) — поэтому знание английского в любом случае нужно.
снимаем 700sqft аппратмент 3200/m (вместе с комуналками и интернетом)
Имхо немного переплачиваете. Хотя если это напротив Wholefoods, чтобы пешком 5 минут в офис может и имеет смысл.
BTW читал до этого, что glassdoor сильно занижает, а paysa более адекватна, но бывает завышает.
Та же самая позиция на glassdoor — среднее гораздо меньше. www.glassdoor.com/Salary/Applied-Materials-Software-Engineer-San-Jose-Salaries-EJI_IE1139.0,17_KO18,35_IL.36,44_IM761.htm
Сервера *.dns.ripn.net - частично не отвечают
Google внедрил JSON в 2016 до того как DoH был стандартизирован. В данный момент «выключать» его они пока не собираются, но это вполне возможно.
developers.google.com/speed/public-dns/docs/doh/migration
Wire format имеет преимущество, так как в случае с DoT может использоваться для трансфера DNS зон. DoH к сожалению для трансфера зон не может использоваться из-за ограничений по длине HTTP-пакета.
Вот интересное исследование (хотя уже и немного устаревшее) на сравнение протоколов и влияние на загрузку web в зависимости от условий.
Наиболее простой способ для реализации на уровне DNS сервера использовать готовые библиотеки (TLS, HTTPS и т.д.), так как DNS пакет (с минимальными изменениями) просто «завернуть» в другой протокол вместо UDP/TCP.
— интеграция DNS с их страницей проверки
— выдавать различные IP/CNAME в зависимости как тот же самый запрос ресолвится (хотя если посмотреть активность даже в developer tools видно, что используют разные адреса).
После этого на странице проверки достаточно выполнить несколько GET запросов для «скачивания» удаленного объекта.
Например, при соединении с хабром ресолвится 9 доменов. Ну других сайтах доменом может быть гораздо больше.
И у тех, кто пытается защитить корпоративные сети (как пример — в день когда Mozilla официально запустила DoH в США, был обнаружен вирус, который использует DoH).
У «товарища майора», который будет известным способом пытаться решить эту проблему.
А так же естественно у пользователей, которые хотят защитить свою последнюю милю.
перешли на DoH (добровольно или принудительно).
Приведена информация о поддержке браузерами и т.д. и т.п. Какой процент пользователей перешел на DoH — ничего, какие провайдеры тестируют — ничего, кто уже предлагает (кроме Cloudflare и Google) — тоже ничего. Поэтому я и написал, что пост ни о чем…
У «пол страны» нет микротиков + заниматься этим будут только те, кто понимает, что это такое. Ну и в любом случае если используешь публичные DoH сервера ты свои запросы сливаешь «большому брату», так как пока нет авторитативных серверов поддерживающих DoT/DoH. В этом смысле DNS какого-нибудь маленького провайдера может более приватным, чем гугловский DoH. Самое оптимальное иметь свой DNS где-нибудь в удаленном Cloud (например бесплатная VM от Oracle вполне подойдет).
+ Реализация DoH на маршрутизаторе (без фильтрации трафика) тебя не спасет от устройств/приложений/вирусов которым вдруг вздумается напрямую общаться с другим DoH.
Я на своем DNS (open source проект) я реализовал DoT почти 1.5 года назад, а DoH чуть меньше года назад. Сложного в этом ничего нет.
Если по теме, то есть большое сомнение, что Mozilla будет активно пихать это решение в РФ. Судя по тому как они просто отказались от внедрения DoH в UK можно судить, что в других странах, кому это не нужно, (например РФ) произойдет тоже самое.
В данный момент Mozilla пушит DoH только в США (правда доля рынка FF мала), скорее всего Mozilla и Cloudflare (они активно пропихивали RFC — приняли где-то за год или полтора) просто захотели получить как минимум американский рынок DNS, где полученные данные можно хорошо монетизировать.
Стоимость решения DPI на весь провайдерский трафик с учетом внедрения 5g будет неподъемным.
Тут официально не могут нанимать только по знание какого-то языка, если это не требуется в работе (это ещё бывает доказать нужно) — поэтому знание английского в любом случае нужно.
Имхо немного переплачиваете. Хотя если это напротив Wholefoods, чтобы пешком 5 минут в офис может и имеет смысл.
BTW читал до этого, что glassdoor сильно занижает, а paysa более адекватна, но бывает завышает.
Та же самая позиция на glassdoor — среднее гораздо меньше.
www.glassdoor.com/Salary/Applied-Materials-Software-Engineer-San-Jose-Salaries-EJI_IE1139.0,17_KO18,35_IL.36,44_IM761.htm