{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Skurudo Blog(post): заметки с тегом DNS", "_rss_description": "DNS (англ. Domain Name System — система доменных имён) — компьютерная распределённая система для получения информации о доменах", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/www.skurudo.ru\/tags\/dns\/", "feed_url": "https:\/\/www.skurudo.ru\/tags\/dns\/json\/", "icon": "https:\/\/www.skurudo.ru\/pictures\/userpic\/userpic@2x.jpg?1691593083", "authors": [ { "name": "Pavel Galkin", "url": "https:\/\/www.skurudo.ru\/", "avatar": "https:\/\/www.skurudo.ru\/pictures\/userpic\/userpic@2x.jpg?1691593083" } ], "items": [ { "id": "225", "url": "https:\/\/www.skurudo.ru\/all\/dns-over-https-on-mikrotik\/", "title": "Настройка DoH в Mikrotik", "content_html": "

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

\n

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

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

\n\"\"\n<\/div>\n

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

\n\"\"\n<\/div>\n

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

\/tool fetch url=https:\/\/erza.ru\/cert\/cacert.pem\r\n\/certificate import file-name=cacert.pem passphrase=""<\/code><\/pre>
Также список корневых сертификатов можно взять на сайте haxx.se<\/a> или же с DigiCert<\/a><\/p>\n
После чего удалим лишние dns-серверы и впишем свои. В итоге у нас все выглядит вот так:<\/p>\n
\n\"\"\n<\/div>\n
Провести проверку можно с помощью torch или в connection tracker:<\/p>\n
\n\"\"\n<\/div>\n
Список DoH серверов — смотреть тут<\/a>, но самые популярные скорее всего будут Google ( https:\/\/8.8.8.8\/dns-query<\/a> ) и Cloudflare (  https:\/\/1.1.1.1\/dns-query<\/a> ).<\/p>\n
Тестируем и проверяем на сайте Cloudflare<\/a><\/p>\n
\n\"\"\n<\/div>\n
На всякий случай привожу листинг команд:<\/p>\n
\/tool fetch url=https:\/\/erza.ru\/cert\/cacert.pem\r\n\/certificate import file-name=cacert.pem passphrase=""\r\n\/ip dns set use-doh-server=https:\/\/1.1.1.1\/dns-query\r\n\/ip dns set verify-doh-cert=yes\r\n\/ip dns set servers=""<\/code><\/pre>
UPDATE: <\/b> Никита Тарикин набросал еще более интересную штуку со скриптом и поворотами — MikroTik DNS-over-HTTPS CloudFlare<\/a> :)<\/p>\n",
            "date_published": "2020-06-03T07:59:59+03:00",
            "date_modified": "2020-06-03T09:31:41+03:00",
            "tags": [
                "Cloudflare",
                "DNS",
                "DoH",
                "Google",
                "https",
                "Mikrotik",
                "VPN"
            ],
            "image": "https:\/\/www.skurudo.ru\/pictures\/doh-05.png",
            "_date_published_rfc2822": "Wed, 03 Jun 2020 07:59:59 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "225",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": [
                    "https:\/\/www.skurudo.ru\/pictures\/doh-05.png",
                    "https:\/\/www.skurudo.ru\/pictures\/doh-01.png",
                    "https:\/\/www.skurudo.ru\/pictures\/doh-02.png",
                    "https:\/\/www.skurudo.ru\/pictures\/doh-03.png",
                    "https:\/\/www.skurudo.ru\/pictures\/doh-06.png",
                    "https:\/\/www.skurudo.ru\/pictures\/doh-04.png"
                ]
            }
        },
        {
            "id": "199",
            "url": "https:\/\/www.skurudo.ru\/all\/looking-for-dns-hosting\/",
            "title": "В поисках хостинга DNS",
            "content_html": "
В далеком 2011 году впервые озаботился вопросом выбора DNS хостинга, чтобы был понадежнее да поудобнее. С тех пор обращался к теме поиска несколько раз, но ничего идеального так и нет. Основная претензия к такого рода услугам — она либо дорогая, либо неудобная, либо все вместе. Складывается ощущение, что те, кто занимается разработкой или руководит внедрением, не имеют у себя с десяток доменов или в DNS им нужно поменять что-то такое специфическое один раз, к одному домену и происходит это раз в сто лет и можно немного потерпеть. Не скажу, что сам меняю что-то каждый день, но некоторая частота все-таки есть. Еще один случай из клинических — переезд. Сменить одну А-запись для одного домена не долго, а вот когда там еще TXT и для доменов 3-его и 4-ого уровня? Довольно продолжительно по времени получается.<\/p>\n
Помнится, был сначала YPDNS, более всего близок по первоначальным требованиям<\/a>, но просуществовал недолго и закрылся. Если не изменяет память, то у создателя не оставалось времени и мотивации на продолжение ведения этого дела. Пришлось по большей части смигрировать на PDD от Яндекс, однако после миграции всего в Connect я начинаю думать, что Яндекс тоже идет по какому-то своему пути и интересы у нас немного разные.<\/p>\n
Чего бы сейчас хотелось от DNS хостинга:<\/p>\n
    \n
  1. если сервис платный, то стоимость поддержки не должна быть астрономически высокой;<\/li>\n
  2. серверы в нескольких гео-распределенных датацентрах поближе к магистральным каналам (на данный момент не самый критичный пункт, хотя несколько лет назад для меня это было важно — достаточно чтобы физически не в одном ДЦ);<\/li>\n
  3. «быстрый» пинг (желательно до 10 мс, в идеале 1-5 мс);<\/li>\n
  4. оперативная синхронизация между серверами;<\/li>\n
  5. поддержка NS, A, AAAA, CNAME, MX, TXT, PTR и SRV;<\/li>\n
  6. возможность изменения TTL по записям;<\/li>\n
  7. возможность изменения SOA по домену;<\/li>\n
  8. желательна поддержка DNSSEC;<\/li>\n
  9. поддержка Round Robin желательна;<\/li>\n
  10. возможность использования темплейтов (наличие инструмента или шаблона для создания — т. е. мы создаем шаблон с нужными записями и применяем его к домену);<\/li>\n
  11. возможность массовой правки записей по домену (к примеру мы выделили несколько записей и хотим из удалить или мы выделили несколько записей одного типа — А-запись к примеру и хотим поменять там значение IP)<\/li>\n
  12. возможность массовой правки записей по нескольким доменам (похоже для записи выше, здесь по большей части нас интересуют поля А-записей, TXT, SOA);<\/li>\n
  13. и конечно стабильная работа, высокий аптайм как всегда.<\/li>\n<\/ol>\n",
            "date_published": "2019-03-27T15:37:01+03:00",
            "date_modified": "2019-03-27T15:40:40+03:00",
            "tags": [
                "DNS",
                "Яндекс"
            ],
            "_date_published_rfc2822": "Wed, 27 Mar 2019 15:37:01 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "199",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "136",
            "url": "https:\/\/www.skurudo.ru\/all\/strange-problems-with-google-dns\/",
            "title": "Странные проблемы с Google DNS",
            "content_html": "
    Сегодня где-то в половине шестого начались странные проблемы с интернетом. По цепочке проверили все, что только можно, пока не уперлись в dns от Google. Порядка трех часов из сети Ростелекома, с М9 и из сети Билайн было не получить ответа. Фокус в том, что пинги проходили нормально (потери были, но небольшие и непостоянные), а вот ответ не отдавался или отдавался с большими потерями. Забавное в том, что началось все с основного 8.8.8.8. Резервный адрес 8.8.4.4 работал нормально, правда потом начал хандрить и он.<\/p>\n
    Что это такое было не ясно, но больше всего сообщений мной было найдено из РФ. В англоязычном части интернета авария прошла незаметно (впрочем может её там и не было). Никаких официальных ответов или сведений об этом инциденте нет.<\/p>\n
    Проверять можно следующим образом:<\/p>\n
    nslookup google.com 8.8.8.8<\/code><\/pre>
    dig @8.8.8.8 google.com<\/code><\/pre>
    В качестве резерва есть днс серверы от Яндекса:<\/p>\n
    77.88.8.8\r\n77.88.8.1<\/code><\/pre>
    UPDATE, 22:00 — подборка новостей по теме<\/b>:<\/p>\n