Debug Environment
$ export SDNS_DEBUGNS=true && export SDNS_PPROF=true && ./sdns
SDNS_DEBUGNS enviroment useful when you want to check authoritive servers RTT times.
Usage: send HINFO query for zones with chaos class.
Example Output:
$ dig chaos hinfo example.com ; <<>> DiG 9.17.1 <<>> chaos hinfo example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29636 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: f27dbb995df5ac79e4fa37c07d131b5bd03aa1c5f802047a7c02fb228a886cb281ecc319323dea81 (good) ;; QUESTION SECTION: ;example.com. CH HINFO ;; AUTHORITY SECTION: example.com. 0 CH HINFO "Host" "IPv4:199.43.135.53:53 rtt:142ms health:" example.com. 0 CH HINFO "Host" "IPv4:199.43.133.53:53 rtt:145ms health:" example.com. 0 CH HINFO "Host" "IPv6::53 rtt:147ms health:" example.com. 0 CH HINFO "Host" "IPv6::53 rtt:148ms health:"
Configuration (v1.1.0)
| Key | Desc |
|---|---|
| version | Config version |
| blocklists | List of remote blocklists address list. All lists will be download to blocklist folder. |
| blocklistdir | List of locations to recursively read blocklists from (warning, every file found is assumed to be a hosts-file or domain list) |
| loglevel | What kind of information should be logged, Log verbosity level crit,error,warn,info,debug |
| accesslog | The location of access log file, left blank for disabled. SDNS uses Common Log Format by default. |
| bind | Address to bind to for the DNS server. Default :53 |
| bindtls | Address to bind to for the DNS-over-TLS server. Default :853 |
| binddoh | Address to bind to for the DNS-over-HTTPS server. Default :8053 |
| tlscertificate | TLS certificate file path |
| tlsprivatekey | TLS private key file path |
| outboundips | Outbound ipv4 addresses, if you set multiple, sdns can use random outbound ipv4 address by request based |
| outboundip6s | Outbound ipv6 addresses, if you set multiple, sdns can use random outbound ipv6 address by request based |
| rootservers | DNS Root IPv4 servers |
| root6servers | DNS Root IPv6 servers |
| rootkeys | Trusted anchors for DNSSEC |
| fallbackservers | Failover resolver ipv4 or ipv6 addresses with port, left blank for disabled: Example: «8.8.8.8:53» |
| forwarderservers | Forwarder resolver ipv4 or ipv6 addresses with port, left blank for disabled: Example: «8.8.8.8:53» |
| api | Address to bind to for the http API server, left blank for disabled |
| nullroute | IPv4 address to forward blocked queries to |
| nullroutev6 | IPv6 address to forward blocked queries to |
| accesslist | Which clients allowed to make queries |
| timeout | Network timeout for each dns lookups in duration Default: 2s |
| hostsfile | Enables serving zone data from a hosts file, left blank for disabled |
| expire | Default error cache TTL for in seconds Default: 600 |
| cachesize | Cache size (total records in cache) Default: 256000 |
| maxdepth | Maximum iteration depth for a query Default: 30 |
| ratelimit | Query based ratelimit per second, 0 for disabled. Default: 0 |
| clientratelimit | Client ip address based ratelimit per minute, 0 for disable. if client support edns cookie no limit. Default: 0 |
| blocklist | Manual blocklist entries |
| whitelist | Manual whitelist entries |
| cookiesecret | DNS cookie secret (RFC 7873), if no cookiesecret set, it will be generate automatically |
| nsid | DNS server identifier (RFC 5001), it’s useful while operating multiple sdns. left blank for disabled |
| chaos | Enable to answer version.server, version.bind, hostname.bind and id.server chaos txt queries. |
| qname_min_level | Qname minimize level.If higher, it can be more complex and impact the response performance. If set 0, qname min will be disable |
| emptyzones |
Как настроить dnscrypt-proxy
Настройка dnscrypt-proxy выполняется с помощью файла dnscrypt-proxy.toml. В Windows этот файл расположен по пути C:\dnscrypt-proxy\dnscrypt-proxy.toml, а в Linux это файл /etc/dnscrypt-proxy/dnscrypt-proxy.toml. Независимо от операционной системы, настройка делается одинаково.
Откройте этот файл любым текстовым редактором, например, в Linux:
sudo gedit /etc/dnscrypt-proxy/dnscrypt-proxy.toml
Содержимое этого файла зависит от вашего дистрибутива: иногда там полный дефолтный файл, иногда уже настроенный сопровождающими пакета.
Чтобы после редактирования файла dnscrypt-proxy.toml изменения вступили в силу, выполните следующую команду.
Для Windows:
C:\dnscrypt-proxy\dnscrypt-proxy -service restart
Для Linux:
sudo systemctl restart dnscrypt-proxy.service
Чтобы понять, что настраивать, немного информации о том, как работает dnscrypt-proxy. Для преобразования имён в IP адреса dnscrypt-proxy скачивает большой список DNS серверов и в фоне проверяет их доступность и скорость отклика. Запросы делаются к разным DNS серверам в зависимости от скорости отклика и алгоритмов балансировки нагрузки. Это можно изменить — например, можно выбрать определённое имя или несколько имён и указать его (или их) в директиве server_names. Если директива server_names пустая, то будут использоваться все сервера. Если в директиве server_names указано одно или более имён DNS серверов, то будут использоваться только эти сервера.
К примеру, я предпочитаю DNS сервер Google, тогда значение моей директивы:
server_names =
Если хотите сразу несколько DNS серверов, то укажите их используя следующий синтаксис:
server_names =
Чтобы узнать, какие сервера выбраны для использования, выполните команду.
В Windows:
C:\dnscrypt-proxy\dnscrypt-proxy -list
В Kali Linux:
/usr/sbin/dnscrypt-proxy -list -config /etc/dnscrypt-proxy/dnscrypt-proxy.toml
В Arch Linux, BlackArch:
dnscrypt-proxy -list -config /etc/dnscrypt-proxy/dnscrypt-proxy.toml
Директива listen_addresses устанавливает порт и IP адрес для прослушивания. Обычно, нет необходимости здесь что-то менять. Для работы с сокетами устанавливается следующее значение:
listen_addresses = []
Установите fallback_resolvers на
fallback_resolvers =
Если вам зачем-то нужно вести журнал сделанных запросов, то найдите и раскомментируйте следующие строки:
file = '/var/log/dnscrypt-proxy/query.log'
Как добавить DNS сервер в исключение
Предположим, вы хотите использовать полный список DNS серверов, но хотите исключить некоторые из них. К примеру, как написали в комментарии, в данный момент у сервера rdns.faelix.net просрочен сертификат, что приводит к выводу предупреждений от антивирусного ПО. По этой причине мы хотим исключить данный сервер из списка используемых.
Это можно сделать с помощью директивы disabled_server_names, в качестве её значения нужно перечислить имена серверов, которые нужно избегать даже если они удовлетворяют всем критериям.
В первую очередь нам нужно знать имя проблемного DNS сервера. Для этого перейдите на страницу https://dnscrypt.info/public-servers
Внизу найдите выпадающий список «Rows per page» (Строк на страницу) и выберите там «All» (Все).
Нажмите в веб-браузере Ctrl+f для поиска по странице. Мы знаем, что проблемный адрес rdns.faelix.net, попробуем поискать по части имени «faelix»:
Итак, имена IPv4 DNS серверов это faelix-ch-ipv4 и faelix-uk-ipv4.
В файле настроек найдите disabled_server_names и добавьте имена туда:
disabled_server_names =
Если вы используете IPv6 подключение, то также добавьте в список исключений и IPv6 имена.
Сохраните файл настроек и перезапустите службу dnscrypt-proxy.
Документация по настройке dnscrypt-proxy на русском
На странице карточки программы размещён пример конфигурационного файла dnscrypt-proxy с объяснением всех опций и переводом комментариев на русский язык: https://kali.tools/?p=5964
Features
- Linux/BSD/Darwin/Windows supported
- DNS RFC compatibility
- DNS lookups within listed ipv4 and ipv6 auth servers
- DNS caching
- DNSSEC validation
- DNS over TLS support (DoT)
- DNS over HTTPS support (DoH)
- Outbound IP selection
- Middleware Support, you can add, your own middleware
- RTT priority within listed servers
- Failover forwarders while returning failured responses
- Forwarder support
- EDNS Cookie Support (client<->server)
- EDNS NSID Support
- Full IPv6 support (client<->server, server<->server)
- Query based ratelimit
- IP based ratelimit
- Access list
- Access log
- Prometheus basic query metrics
- Black-hole for malware responses
- HTTP API support
- Cache Purge API and query support
- Answer chaos txt queries for version.bind and hostname.bind
- Empty zones support described at RFC 1918
- External plugins supported
Способы включения DNS через HTTPS (DoH)
Можно включить зашифрованные DNS запросы двумя способами — на уровне веб-браузеров и на уровне операционной системы. Каждый из этих способов имеет свои преимущества.
Включение безопасного DNS на уровне веб-браузеров выполняется очень просто, достаточно поставить галочку в настройках. Более того, в Google Chrome эта настройка уже включена по умолчанию. Недостаток этого метода в том, что все другие приложения, использующие Интернет-подключение, не смогут использовать DNS через HTTPS. Такими приложениями могут быть программы для скачивания файлов, мессенджеры, службы обновления программ и операционной системы и так далее.
Включение DoH на уровне системы делает так, что все программы будут делать DNS запросы исключительно по зашифрованному каналу. Но это требует установки программы — кэширующего DNS сервера. На самом деле, установка очень простая и программа будет потреблять минимум ресурсов. При этом собственный DNS будет кэшировать полученные данные благодаря чему немного увеличит скорость работы сети.
Какой вариант выбрать — исключительно на ваше усмотрение. В этой инструкции будут рассмотрены оба способа и вы увидите, насколько всё просто при выборе любого метода шифрования DNS запросов.
Global DNS Checker — How to check DNS propagation
whatsmydns.net is a free online tool that lets you quickly and easily perform a DNS lookup to check DNS propagation and see information of any domain from DNS servers located in many countries all around the world.
Many operating systems include DNS tools to check DNS records manually for diagnosing problems. However, using these tools can be complicated and difficult to understand for non-technical people which is why the whatsmydns.net DNS checker was created to help with quickly checking DNS propagation.
whatsmydns.net makes the process of performing global DNS checks easy by maintaining a range of DNS servers to perform lookups with. These results are then parsed and displayed on a map so that results are easier to understand at a glance. Individual lookup results can be seen in detail by selecting a server location from the list or clicking on the map markers once a search has been completed.
Настройка dnscrypt-proxy для использования с IPv6
Во-первых, измените файл /etc/resolv.conf
sudo gedit /etc/resolv.conf
там должны быть строки
nameserver 127.0.2.1 nameserver ::1 options edns0 single-request-reopen EDNSPayloadSize 4096
В файле dnscrypt-proxy.toml
sudo gedit /etc/dnscrypt-proxy/dnscrypt-proxy.toml
Нужно установить прослушивание IPv6 интерфейса:
listen_addresses = :53'])
Замените
ipv6_servers = false
на
ipv6_servers = true
Помните, что сервер это IPv4 сервер, а google-ipv6 это IPv6 сервер. Поэтому если вы установили значение server_names, то не забудьте туда вписать и IPv6 сервера, например:
server_names =
What server types are used in a DNS check?
There are 4 different types of DNS servers involved when performing a DNS check. Each has a different role and may not be needed at all depending on the situation, having all these different server types is what contributes to DNS propagation issues.
Recursive Resolver — The DNS server your device communicates with is called the recursive resolver and is issued to you automatically by your ISP, but can be also configured on your router or individual devices. These DNS severs are ideally located in close geographical proximity to return results as fast as possible. These servers will cache a copy of the DNS results to speed up future DNS lookup requests.
Root Name Server — This type of DNS server is responsible for returning the IP address of the TLD (Top Level Domain) nameserver. For instance, if it is trying to resolve example.com, the root name server returns the IP of the TLD name server that runs .com domains.
TLD Name Server — This name server returns the authoritative name servers for each domain under the Top Level Domain it’s responsible for. The .com TLD name server will return results for example.com but not example.org.
Authoritative Name Server — This stores DNS servers’ configuration data for specific domain names.
Как включить DNS через HTTPS (DoH) в веб-браузерах
Google Chrome
В Google Chrome в Windows уже включена опция DNS через HTTPS. Вы можете её проверить перейдя в «Настройки» → «Конфиденциальность и безопасность» → «Безопасность» → «Дополнительные» → «Использовать безопасный DNS сервер». Чтобы быстро найти эту настройку, введите в адресную строку «chrome://settings/security/» и пролистните в самый низ.
Вы можете выбрать из списка любой DNS сервер с поддержкой DoH или указать свой собственный.
На момент написания, в Google Chrome в Linux данная опция недоступна.
Firefox
Перейдите в Настройки → Основные. Пролистните в самый низ, чтобы найти кнопку «Параметры сети, Настроить».
Поставьте галочку «Включить DNS через HTTPS» и выберите провайдера из списка или введите свой IP адрес:
Opera
Перейдите в настройки (шестерёнка внизу левого сайдбара или кнопка «Простые настройки» → «Открыть все настройки браузера»).
Затем перейдите в «Дополнительно» → «Система».
Включите галочку «Использовать DNS поверх HTTPS вместо системных настроек DNS» и выберите желаемый DNS сервер.
Microsoft Edge
На момент написания предустановленный по умолчанию Internet Explorer (Microsoft Edge) вовсе не знает про DNS через HTTPS. Если скачать последнюю версию Microsoft Edge, то там эту настройку можно включить с помощью флага.
Введите в адресную строку edge://flags#dns-over-https
Включите экспериментальный флаг и перезапустите веб-браузер.
Эммм… вроде как нужно бы ещё ввести настройки DNS сервера, но я не нашёл, где это сделать в Microsoft Edge. Да и кому дело до Microsoft Edge — кто им вообще пользуется?!
Which DNS record types can be checked?
You can check DNS propagation for common record types including:
- A — The most common DNS record, used to point a domain to an IP address.
- CNAME — Also known as alias records, they point to other DNS records. Sometimes used for subdomains like www.
- MX — Mail Exchanger records are used set email servers and their priority.
- NS — Name Server records store the authoritative nameserver.
- TXT — Text records are commonly used for configuration settings such as SPF and DKIM records.
Additional types that can be checked which are usually used in more advanced configurations include:
AAAA,
CAA,
PTR,
SOA and
SRV.
Проверка работы dnscrypt-proxy
Я уже упоминал, что благодаря кэшированию, повторные DNS запросы обрабатываются быстрее. Для проверки можно выполнить два раза подряд команду:
time dig kali.tools +short
Первый ответ получен через 0,047s, а второй всего через 0,006s. Конечно, это только доли секунды, но всё равно хорошо. К тому же, вы реже будете сталкиваться с ситуацией, когда браузер «задумался» во время запроса из-за того, что по какой-то причине некоторые DNS ответы идут слишком долго или вовсе потеряны.
Можно проверить, сколько идёт запрос «напрямую», без DoH:
time dig kali.tools +short @8.8.8.8
В моём случае это 0,058s-0,094s с периодическими таймаутами, видимо, задержка на СОРМ. Видимо, зашифрованный трафик пропускается «как есть», а незашифрованный проходит какую-то обработку, вроде как проверку доменов/IP по реестру запрещённых сайтов и т. п. Больше шифрования — больше скорости!
Запустите Wireshark и начните захват трафика. Через некоторое время проверьте с использованием фильтра
dns
Там должно быть пусто, совсем.
Также с помощью фильтра посмотрим на пакеты, которые уходят к DNS серверу и возвращаются от него:
ip.addr == 8.8.8.8
Как можно увидеть на скриншоте, всё зашифровано, теперь у Интернет-провайдера и других посредников нет никакой возможности узнать или изменить содержимое DNS запросов и ответов.
Configuration (v1.1.0)
| Key | Desc |
|---|---|
| version | Config version |
| blocklists | List of remote blocklists address list. All lists will be download to blocklist folder. |
| blocklistdir | List of locations to recursively read blocklists from (warning, every file found is assumed to be a hosts-file or domain list) |
| loglevel | What kind of information should be logged, Log verbosity level crit,error,warn,info,debug |
| accesslog | The location of access log file, left blank for disabled. SDNS uses Common Log Format by default. |
| bind | Address to bind to for the DNS server. Default :53 |
| bindtls | Address to bind to for the DNS-over-TLS server. Default :853 |
| binddoh | Address to bind to for the DNS-over-HTTPS server. Default :8053 |
| tlscertificate | TLS certificate file path |
| tlsprivatekey | TLS private key file path |
| outboundips | Outbound ipv4 addresses, if you set multiple, sdns can use random outbound ipv4 address by request based |
| outboundip6s | Outbound ipv6 addresses, if you set multiple, sdns can use random outbound ipv6 address by request based |
| rootservers | DNS Root IPv4 servers |
| root6servers | DNS Root IPv6 servers |
| rootkeys | Trusted anchors for DNSSEC |
| fallbackservers | Failover resolver ipv4 or ipv6 addresses with port, left blank for disabled: Example: “8.8.8.8:53” |
| forwarderservers | Forwarder resolver ipv4 or ipv6 addresses with port, left blank for disabled: Example: “8.8.8.8:53” |
| api | Address to bind to for the http API server, left blank for disabled |
| nullroute | IPv4 address to forward blocked queries to |
| nullroutev6 | IPv6 address to forward blocked queries to |
| accesslist | Which clients allowed to make queries |
| timeout | Network timeout for each dns lookups in duration Default: 2s |
| hostsfile | Enables serving zone data from a hosts file, left blank for disabled |
| expire | Default error cache TTL for in seconds Default: 600 |
| cachesize | Cache size (total records in cache) Default: 256000 |
| maxdepth | Maximum iteration depth for a query Default: 30 |
| ratelimit | Query based ratelimit per second, 0 for disabled. Default: 0 |
| clientratelimit | Client ip address based ratelimit per minute, 0 for disable. if client support edns cookie no limit. Default: 0 |
| blocklist | Manual blocklist entries |
| whitelist | Manual whitelist entries |
| cookiesecret | DNS cookie secret (RFC 7873), if no cookiesecret set, it will be generate automatically |
| nsid | DNS server identifier (RFC 5001), it’s useful while operating multiple sdns. left blank for disabled |
| chaos | Enable to answer version.server, version.bind, hostname.bind and id.server chaos txt queries. |
| qname_min_level | Qname minimize level.If higher, it can be more complex and impact the response performance. If set 0, qname min will be disable |
| emptyzones | Empty zones return answer for RFC 1918 zones. Please see http://as112.net/ for details. |
Что такое DNS через HTTPS (DoH)?
Интернет стремится, чтобы по умолчанию шифрование присутствовало везде. На данный момент большинство веб-сайтов, к которым вы обращаетесь, вероятно, используют шифрование HTTPS. Современные веб-браузеры, такие как Chrome, теперь помечают любые сайты, использующие стандартный HTTP, как «небезопасные». HTTP/3, новая версия протокола HTTP, имеет встроенное шифрование.
Это шифрование гарантирует, что никто не сможет вмешаться в работу веб-страницы, пока вы её просматриваете, или следить за тем, что вы делаете в Интернете. Например, если вы подключаетесь к Wikipedia.org, оператор сети — будь то общедоступная точка доступа Wi-Fi компании или ваш Интернет-провайдер — может видеть только то, что вы подключены к wikipedia.org. Они не видят, какую статью вы читаете, и не могут изменять статью Википедии пока она идёт до вашего компьютера.
Но в стремлении к шифрованию DNS остался позади. Система доменных имён делает так, что мы можем подключаться к веб-сайтам через их доменные имена, а не с помощью числовых IP-адресов. Вы вводите доменное имя, например google.com, и ваша система свяжется с DNS-сервером, который указан в настройках системы, чтобы получить IP-адрес, связанный с google.com. Затем ваш компьютер или телефон подключится к этому IP-адресу.
До сих пор эти запросы DNS не были зашифрованы. Когда вы подключаетесь к веб-сайту, ваша система отправляет запрос о том, что вы ищете IP-адрес, связанный с определённым доменом. Любой посредник передачи данных — возможно, ваш интернет-провайдер, но, возможно, также просто общедоступная точка доступа Wi-Fi, записывающая трафик, — могут регистрировать, к каким доменам вы подключаетесь. Из-за этого возможны атаки и сбор информации, описанные в статье «Применение фальшивого DNS».
DNS через HTTPS делает этот надзор невозможным. При использовании DNS через HTTPS ваша система установит безопасное зашифрованное соединение с вашим DNS-сервером и будет передавать запрос и ответ через это соединение. Все, кто находится между ними, не смогут увидеть, какие доменные имена вы ищете, или вмешаться в присланный ответ.
Сегодня большинство людей используют DNS-серверы, предоставленные их интернет-провайдером. Однако существует множество сторонних DNS-серверов, таких как Google Public DNS, Cloudflare и OpenDNS. Эти сторонние поставщики одними из первых включили поддержку DNS через HTTPS на стороне сервера. Чтобы использовать DNS через HTTPS, вам потребуется как DNS-сервер, так и клиент (например, веб-браузер или операционная система), который его поддерживает.
Features
- Linux/BSD/Darwin/Windows supported
- DNS RFC compatibility
- DNS lookups within listed ipv4 and ipv6 auth servers
- DNS caching
- DNSSEC validation
- DNS over TLS support (DoT)
- DNS over HTTPS support (DoH)
- Outbound IP selection
- Middleware Support, you can add, your own middleware
- RTT priority within listed servers
- Failover forwarders while returning failured responses
- Forwarder support
- EDNS Cookie Support (client<->server)
- EDNS NSID Support
- Full IPv6 support (client<->server, server<->server)
- Query based ratelimit
- IP based ratelimit
- Access list
- Access log
- Prometheus basic query metrics
- Black-hole for malware responses
- HTTP API support
- Cache Purge API and query support
- Answer chaos txt queries for version.bind and hostname.bind
- Empty zones support described at RFC 1918
- External plugins supported
Публичные сервера имён с поддержкой DNS через HTTPS
Чтобы использовать DNS через HTTPS сервер имён должен поддерживать эту технологию. В настоящее время публичные самые популярные DNS серверы её поддерживают. Их адреса для DoH или обычных DNS запросов одинаковые.
| Провайдер | IP-адреса | Блокирование | Особенности |
|---|---|---|---|
| Cloudflare |
1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001 |
нет | Конечная точка DNS поверх HTTPS. |
| Google Public DNS |
8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844 |
нет | Конечная точка DNS поверх HTTPS. |
| CleanBrowsing |
185.228.168.168 185.228.169.168 2a0d:2a00:1:: 2a0d:2a00:2:: |
Взрослый контент. | Конечная точка DNS поверх HTTPS. |
| Adguard |
176.103.130.130 176.103.130.131 2a00:5a60::ad1:0ff 2a00:5a60::ad2:0ff |
Рекламный контент. | Конечная точка DNS поверх HTTPS. |
| Quad9 |
9.9.9.9 149.112.112.112 2620:fe::fe 2620:fe::9 |
Вредоносный контент. | |
| OpenDNS |
208.67.222.222 208.67.220.220 2620:119:35::35 2620:119:53::53 |
нет |
Независимо от того, включаете вы DoH в браузерах или для всей системы, вы можете использовать любой DNS сервер из этого списка. Лично я предпочитаю DNS сервера от Google.
What is DNS and how does it work?
The Domain Name System (known as DNS) is a system used to convert a name (like ) into an IP address (like ). These addresses are used by computers to communicate with each other on the internet. Most people find remembering names much easier than numbers, so DNS makes this process easy.
When you visit a website, your computer, phone or tablet will first check your local DNS cache for the corresponding IP address. If your device has not recently looked up this website, then it will need to ask your configured DNS server which will forward the request on to the DNS server responsible for managing the records. This process is known as a DNS lookup request.
Once the IP address is known, it is stored locally for a set period of time known as the Time To Live (TTL) and used to speed up future requests. Updated records will not be returned until this time has expired, this can often be the cause of why DNS changes do not appear to be working right away.
What happens when a DNS request is made?
Below demonstrates the flow of events when a user requests to visit in their web browser for the first time and does not yet have cached results. As you can see, each step introduces the possibility of a DNS propagation delay.
- → You type into your web browser.
- → Your device sends a request to your configured recursive resolver.
- → The recursive resolver asks the root nameserver for the IP address of the TLD nameserver responsible for domains.
- ← The root nameserver returns the IP address of the .com TLD nameserver to the recursive resolver.
- → The recursive resolver asks the .com TLD nameserver for the address of the authoritative nameserver responsible for .
- ← The .com TLD nameserver returns the IP address of the authoritative nameserver to the recursive resolver.
- → The recursive resolver asks the authoritative nameserver for the IP address of .
- ← The authoritative nameserver returns the IP address of to the recursive resolver.
- ← The recursive resolver returns IP address of to the browser.
- → Your browser makes a web request directly to the resolved IP address.
What is DNS propagation?
DNS propagation is the term commonly used to check the current state of DNS results globally and is often asked about when changes made to DNS zones do not appear to be working as expected. This process can take from only a few minutes, but often takes up to 48-72 hours and sometimes longer.
While technically DNS does not propagate, this is the term that people have become familiar with. DNS requests are recursively forwarded and looked up from the locally used resolver to the authoritative name server on demand and then cached to speed up future lookup requests. For this reason, commonly used DNS servers of large network providers located around the world have been selected when performing DNS checks.
For popular websites, DNS results may be cached for people in different parts of the world using many different recursive DNS resolvers. If you have recently made changes to your configuration, and the TTL has not yet expired, then some people may be receiving out of date results which could mean that they see an older version of your website.
How long does DNS propagation take?
How long DNS propagation takes usually depends on your records TTL setting. This can be anywhere from several minutes up to 48-72 hours or longer. However, there are sometimes other reasons for a long propagation time.
The main issues as to why DNS propagation can take so long are:
DNS Cache — The Time to Live (TTL) is the duration in which DNS data is allowed to ‘live’ in the cache of a local device or DNS resolver. When this duration expires, the local device or server removes existing DNS information and carries out another DNS lookup to fetch new information. Higher TTL settings can often cause a delay in DNS propagation.
Internet Service Providers — Your ISP also caches DNS results, which allows for many users to access sites faster. For every website requested, they will ask the DNS server responsible only once but return the same result for many users. Some ISPs also overlook TTL rules, keeping a cached DNS record even if the TTL has expired. This can make DNS propagation take longer than it should.
Other DNS Servers — You may not be using your ISPs DNS server, if this is the case then the same issues that may be causing delays can still apply.
Domain Name Registrar — When changing web hosting or DNS providers for your domain, it is often also required to update your authoritative name servers. These changes will need to be reflected in the corresponding TLD nameserver for your domain name. For example, if you were to change the NS records for example.com, then the .com TLD nameserver would also need to update which can cause delays in DNS propagation.
How do you speed up DNS propagation?
A technique used to speed up DNS propagation and prevent a delay is to lower your DNS records TTL a few days in advance of making any changes so that when the change is made any old records expire more quickly. Unfortunately, most people who are having issues and trying to speed up DNS propagation only find this out after making changes and are wondering why they’re not seeing instant results.
If you have checked DNS globally, and are seeing different results locally then you may consider flushing your DNS cache, or using another DNS server. As a last resort, manually overriding your local DNS entries in your systems hosts file can also be done but should be considered a temporary measure and only works for certain record types.
