Второго дня в версии 6.47 ветки stable завезли поддержку DoH (DNS over HTTPS). До этого оно было только в ветке с beta и использовать ее не очень хотелось в виду отсутствия стабильности. Почему это так важно? Дело в том, что DNS без каких-либо дополнений дает возможность вышестоящему провайдеру смотреть и подменять dns-запросы. Не видно причин, зачем ему давать такое делать. А также есть некая простота в том, что теперь свои dns-запросы не нужно заворачивать в тот же VPN.

DNS поверх HTTPS (DoH) — протокол для выполнения разрешения DNS по протоколу HTTPS. Целью этого метода >является повышение конфиденциальности и безопасности пользователей путём предотвращения перехвата и >манипулирования данными DNS с помощью атак типа «Атака посредника».

Первым делом нужно обновиться до 6.47 в ветке stable (или воспользовать beta). В случае с long-term стоит либо потерпеть и подождать или переключиться на stable.

Далее идем в IP -> DNS. Сразу же стоит обратить внимание, что вы можете получать DNS динамически (вышестоящий провайдер или настройки APN) и надо бы убрать автоматику. Чаще всего выглядит это как-то так:

Теперь нужно провести небольшую артподготовку, а именно скачать и импортировать список корневых сертификатов. Делается это двумя командами:

/tool fetch url=https://erza.ru/cert/cacert.pem
/certificate import file-name=cacert.pem passphrase=""

Также список корневых сертификатов можно взять на сайте haxx.se или же с DigiCert

После чего удалим лишние dns-серверы и впишем свои. В итоге у нас все выглядит вот так:

Провести проверку можно с помощью torch или в connection tracker:

Список DoH серверов — смотреть тут, но самые популярные скорее всего будут Google ( https://8.8.8.8/dns-query ) и Cloudflare ( https://1.1.1.1/dns-query ).

Тестируем и проверяем на сайте Cloudflare

На всякий случай привожу листинг команд:

/tool fetch url=https://erza.ru/cert/cacert.pem
/certificate import file-name=cacert.pem passphrase=""
/ip dns set use-doh-server=https://1.1.1.1/dns-query
/ip dns set verify-doh-cert=yes
/ip dns set servers=""

UPDATE: Никита Тарикин набросал еще более интересную штуку со скриптом и поворотами — MikroTik DNS-over-HTTPS CloudFlare :)

В далеком 2011 году впервые озаботился вопросом выбора DNS хостинга, чтобы был понадежнее да поудобнее. С тех пор обращался к теме поиска несколько раз, но ничего идеального так и нет. Основная претензия к такого рода услугам — она либо дорогая, либо неудобная, либо все вместе. Складывается ощущение, что те, кто занимается разработкой или руководит внедрением, не имеют у себя с десяток доменов или в DNS им нужно поменять что-то такое специфическое один раз, к одному домену и происходит это раз в сто лет и можно немного потерпеть. Не скажу, что сам меняю что-то каждый день, но некоторая частота все-таки есть. Еще один случай из клинических — переезд. Сменить одну А-запись для одного домена не долго, а вот когда там еще TXT и для доменов 3-его и 4-ого уровня? Довольно продолжительно по времени получается.

Помнится, был сначала YPDNS, более всего близок по первоначальным требованиям, но просуществовал недолго и закрылся. Если не изменяет память, то у создателя не оставалось времени и мотивации на продолжение ведения этого дела. Пришлось по большей части смигрировать на PDD от Яндекс, однако после миграции всего в Connect я начинаю думать, что Яндекс тоже идет по какому-то своему пути и интересы у нас немного разные.

Чего бы сейчас хотелось от DNS хостинга:

1. если сервис платный, то стоимость поддержки не должна быть астрономически высокой;
2. серверы в нескольких гео-распределенных датацентрах поближе к магистральным каналам (на данный момент не самый критичный пункт, хотя несколько лет назад для меня это было важно — достаточно чтобы физически не в одном ДЦ);
3. «быстрый» пинг (желательно до 10 мс, в идеале 1-5 мс);
4. оперативная синхронизация между серверами;
5. поддержка NS, A, AAAA, CNAME, MX, TXT, PTR и SRV;
6. возможность изменения TTL по записям;
7. возможность изменения SOA по домену;
8. желательна поддержка DNSSEC;
9. поддержка Round Robin желательна;
10. возможность использования темплейтов (наличие инструмента или шаблона для создания — т. е. мы создаем шаблон с нужными записями и применяем его к домену);
11. возможность массовой правки записей по домену (к примеру мы выделили несколько записей и хотим из удалить или мы выделили несколько записей одного типа — А-запись к примеру и хотим поменять там значение IP)
12. возможность массовой правки записей по нескольким доменам (похоже для записи выше, здесь по большей части нас интересуют поля А-записей, TXT, SOA);
13. и конечно стабильная работа, высокий аптайм как всегда.

Сегодня где-то в половине шестого начались странные проблемы с интернетом. По цепочке проверили все, что только можно, пока не уперлись в dns от Google. Порядка трех часов из сети Ростелекома, с М9 и из сети Билайн было не получить ответа. Фокус в том, что пинги проходили нормально (потери были, но небольшие и непостоянные), а вот ответ не отдавался или отдавался с большими потерями. Забавное в том, что началось все с основного 8.8.8.8. Резервный адрес 8.8.4.4 работал нормально, правда потом начал хандрить и он.

Что это такое было не ясно, но больше всего сообщений мной было найдено из РФ. В англоязычном части интернета авария прошла незаметно (впрочем может её там и не было). Никаких официальных ответов или сведений об этом инциденте нет.

Проверять можно следующим образом:

nslookup google.com 8.8.8.8

dig @8.8.8.8 google.com

В качестве резерва есть днс серверы от Яндекса:

77.88.8.8
77.88.8.1

UPDATE, 22:00 — подборка новостей по теме:

• Тостер, 19:15
• Twitter, 19:23
• Хабрахабр, 19:51
• Тостер, 19:57
• ЖЖ m0z9s, 20:12
• Тостер, 20:45
• Roem, 21:17

• КАЗАХТЕЛЕКОМ заблокировал DNS 8.8.8.8