DNS отказоустойчивост при хостинг инфраструктура: как да изградим архитектура без единична точка на отказ

DNS е една от онези услуги, които обикновено остават незабелязани, докато не спрат да работят. Един уеб сървър може да бъде напълно изправен, уеб услугата да работи, базата данни да е активна и мрежата да е достъпна — но ако DNS инфраструктурата е недостъпна, за крайния потребител сайтът на практика може да се окаже недостъпен.

Затова при изграждането на професионална хостинг инфраструктура DNS не трябва да се разглежда просто като набор от A, MX и TXT записи. Той е отделен инфраструктурен слой, който трябва да има собствена стратегия за отказоустойчивост, синхронизация, мониторинг и възстановяване.

В тази статия ще разгледаме как се изгражда такава архитектура, каква е ролята на authoritative DNS сървърите, какво представляват glue records, защо два nameserver-а невинаги означават реална отказоустойчивост и как правилно да разделим понятията High Availability и Disaster Recovery.

Какво всъщност се случва, когато отворим един сайт?

Когато потребител въведе например:

example.com

браузърът не знае автоматично на кой IP адрес се намира сайтът. Той разчита на DNS инфраструктурата.

Опростено процесът изглежда така:

Потребител
    ↓
Recursive DNS resolver
    ↓
Root DNS
    ↓
TLD DNS (.com, .bg, .eu и т.н.)
    ↓
Authoritative nameserver
    ↓
A / AAAA запис
    ↓
Уеб сървър

Това означава, че достъпността на сайта зависи не само от самия уеб сървър, но и от authoritative DNS сървърите, които обслужват домейна.

Ако те не могат да бъдат достигнати и необходимата информация вече не съществува в DNS кешовете, resolver-ът няма откъде да научи IP адреса на сайта.

Два nameserver-а не означават непременно отказоустойчив DNS

Често срещана конфигурация е:

ns1.example.net
ns2.example.net

На пръв поглед изглежда, че разполагаме с два DNS сървъра.

Но ако:

ns1.example.net → 192.0.2.10
ns2.example.net → 192.0.2.11

и двата IP адреса се обслужват от един и същ физически или виртуален сървър, тогава реално продължаваме да имаме единична точка на отказ.

При проблем като:

kernel panic;
хардуерна повреда;
повреда на storage или RAID масив;
мрежов проблем в datacenter-а;
неправилна firewall конфигурация;
неуспешен OS update;
срив на BIND или друга DNS услуга;
пълно отпадане на хост машината;

и двата nameserver-а могат да станат недостъпни едновременно.

Броят на DNS имената не определя отказоустойчивостта. Физическата и мрежовата независимост на authoritative DNS сървърите я определя.

По-добрата архитектура: authoritative DNS на независими сървъри

По-сериозната инфраструктура може да изглежда например така:

                    DNS зона
                       │
            ┌──────────┴──────────┐
            │                     │
       DNS Server A          DNS Server B
        ns1 / ns2             ns3 / ns4
            │                     │
      Infrastructure A      Infrastructure B

Самият инфраструктурен домейн може да има:

example.net. NS ns1.example.net.
example.net. NS ns2.example.net.
example.net. NS ns3.example.net.
example.net. NS ns4.example.net.

Когато DNS Server A е недостъпен, recursive resolver-ът може да използва DNS Server B.

При правилна конфигурация:

Server A DOWN

ns1 → timeout
ns2 → timeout

ns3 → authoritative answer
ns4 → authoritative answer

DNS зоната продължава да бъде достъпна.

Това е реалната стойност на използването на множество authoritative DNS сървъри.

Каква е ролята на glue records?

Нека разгледаме домейн:

example.net

който използва:

ns1.example.net
ns2.example.net

Тук възниква важен DNS казус.

За да намерим example.net, трябва да достигнем до ns1.example.net.

Но за да намерим IP адреса на ns1.example.net, трябва да получим DNS информация за example.net.

Това създава потенциална циклична зависимост.

Точно тук се използват glue records.

Parent зоната — например .net — може да предостави директно адресите на nameserver-ите:

example.net NS ns1.example.net.
example.net NS ns2.example.net.

ns1.example.net A 192.0.2.10
ns2.example.net A 192.0.2.11

Така resolver-ът получава необходимия IP адрес още от parent DNS инфраструктурата и може директно да достигне authoritative nameserver-а.

При инфраструктура с повече от един физически DNS сървър можем да имаме например:

ns1.example.net → Server A
ns2.example.net → Server A

ns3.example.net → Server B
ns4.example.net → Server B

а parent registry да делегира зоната към всичките четири nameserver-а.

Това позволява Server B да бъде открит директно от DNS йерархията дори ако Server A е напълно недостъпен.

Child zone и parent delegation трябва да бъдат съгласувани

Това е една от най-важните части при изграждането на надеждна DNS архитектура.

Authoritative зоната може да съдържа:

example.net. NS ns1.example.net.
example.net. NS ns2.example.net.
example.net. NS ns3.example.net.
example.net. NS ns4.example.net.

Но ако registry-то на TLD все още делегира само:

example.net NS ns1.example.net.
example.net NS ns2.example.net.

пълната отказоустойчивост все още не е постигната.

Правилната конфигурация трябва да съществува на две нива:

Parent zone
      ↓
ns1 / ns2 / ns3 / ns4
      ↓
Authoritative child zone
      ↓
ns1 / ns2 / ns3 / ns4

Това е и причината промени по nameserver инфраструктурата да трябва да се извършват внимателно и последователно.

Добрата практика е първо новият authoritative DNS сървър да бъде напълно подготвен, синхронизиран и тестван и едва след това да бъде добавен към parent delegation.

DNS синхронизация между сървърите

Ако една зона се обслужва от няколко authoritative DNS сървъра, те трябва да предоставят еднаква информация.

Например:

Server A:

example.net A 192.0.2.100
www         A 192.0.2.100
mail        A 192.0.2.200

Server B трябва да разполага със същите записи.

Ако единият сървър отговаря:

www → 192.0.2.100

а другият:

www → 192.0.2.150

поведението за потребителите може да се различава според това кой authoritative nameserver е бил избран от recursive resolver-а.

Затова DNS зоните трябва да бъдат синхронизирани надеждно.

При hosting control panel инфраструктури това често се реализира чрез модел от типа:

DNS master / source
        ↓
      sync
        ↓
DNS replica

Един source of truth е по-безопасен от двупосочна синхронизация

На пръв поглед изглежда логично да направим:

Server A ↔ Server B

Но при административното управление на DNS това невинаги е най-добрият модел.

При двупосочна синхронизация неизбежно възниква въпросът:

Кой сървър е източникът на истината?

Ако една и съща зона бъде редактирана на две места, могат да възникнат конфликти, неочаквано презаписване или разпространение на грешна конфигурация.

По-предвидим модел е:

            SOURCE OF TRUTH
                 Server A
                    │
                    │ DNS sync
                    ▼
                 Server B
                  replica

Публично двата сървъра могат да бъдат напълно равноправни authoritative DNS сървъри.

Административно обаче съществува един ясно определен source of truth.

Това е съществена разлика:

Administrative architecture:

Server A → Server B


DNS query architecture:

Server A = Server B

За recursive resolver-а няма значение кой сървър е административният master. Важното е и двата да предоставят валидни authoritative отговори.

SOA serial — един от най-важните показатели за синхронизация

Всяка DNS зона съдържа SOA запис.

Пример:

example.net. IN SOA ns1.example.net. hostmaster.example.net. (
    2026081101
    3600
    3600
    1209600
    1800
)

Стойността:

2026081101

е serial номерът на зоната.

При промяна той трябва да бъде увеличаван.

Когато проверяваме DNS cluster, едно от най-важните неща е всички authoritative сървъри да връщат една и съща актуална версия на зоната.

Например:

Server A → 2026081101
Server B → 2026081101
Server C → 2026081101

Ако един от тях показва:

2026081004

това е сериозна индикация, че този DNS сървър обслужва по-стара версия на зоната.

DNS redundancy и backup са две различни неща

Това е една от най-често бърканите концепции.

Да имаме backup на DNS зоната е изключително важно.

Но backup-ът не е High Availability.

Например:

DNS Server
    ↓
DNS zones
    ↓
Daily backup

Ако DNS сървърът се повреди, backup-ът позволява зоните да бъдат възстановени.

Но между момента на повредата и момента на възстановяването DNS услугата може да бъде недостъпна.

Това е:

Disaster Recovery

За разлика от:

DNS Server A
      +
DNS Server B

където при отпадане на Server A, Server B продължава да отговаря.

Това е:

High Availability

Най-добрата инфраструктура комбинира и двете:

              DNS SOURCE
                  │
          ┌───────┴───────┐
          │               │
     DNS Server A    DNS Server B
          │               │
          └───────┬───────┘
                  │
                Backup

По този начин получаваме едновременно:

High Availability + Disaster Recovery.

А какво става с клиентските домейни?

Тук има още една важна подробност.

Да предположим, че hosting server използва:

ns3.example.net
ns4.example.net

и двата nameserver-а се обслужват от един и същ физически hosting server.

Ако инфраструктурният домейн example.net има redundant DNS архитектура, имената ns3.example.net и ns4.example.net ще могат да бъдат резолвани.

Но ако самият hosting server е напълно недостъпен, той няма да може да отговаря authoritative за клиентските DNS зони, които съществуват само върху него.

Тоест:

Redundant infrastructure DNS
≠
Redundant DNS за всяка клиентска зона

За пълна DNS High Availability на клиентски домейн неговата зона също трябва да се обслужва от независими authoritative DNS системи.

Например:

client.com
    ↓
ns1.example.net → DNS Server A
ns3.example.net → DNS Server B

или чрез отделен managed DNS cluster.

Това вече представлява по-високо ниво на DNS High Availability.

Можем ли да имаме повече hosting nodes?

Да.

Добре проектираната DNS инфраструктура позволява постепенно добавяне на нови hosting сървъри.

Например:

Server A → ns1 / ns2
Server B → ns3 / ns4
Server C → ns5 / ns6
Server D → ns7 / ns8

Не е задължително обаче всички тези nameserver-и да бъдат authoritative за самия инфраструктурен домейн.

Възможно е основният DNS слой да остане:

example.net:

ns1
ns2
ns3
ns4

а вътре в зоната просто да съществуват:

ns5 A Server-C-IP1
ns6 A Server-C-IP2

ns7 A Server-D-IP1
ns8 A Server-D-IP2

Така инфраструктурата остава по-проста, по-лесна за наблюдение и по-предвидима.

Как безопасно се внедрява нов authoritative DNS сървър?

При production инфраструктура редът на действията е изключително важен.

Не е добра практика първо да обявим нов nameserver пред registry-то и след това тепърва да започнем да го конфигурираме.

По-безопасният подход е:

Новият DNS сървър се конфигурира напълно.
Необходимите DNS зони се синхронизират към него.
Проверява се конфигурацията на DNS услугата.
Проверява се достъпността през UDP/53 и TCP/53.
Сравняват се SOA serial стойностите.
Правят се директни dig заявки към новия DNS сървър.
Новият NS се добавя в child зоната.
Отново се проверяват синхронизацията и authoritative отговорите.
Едва тогава nameserver-ът се добавя към parent delegation при регистратора.

Този подход може да бъде разглеждан като additive migration.

Нищо работещо не се премахва предварително.

Например от:

ns1
ns2

преминаваме към:

ns1
ns2
ns3
ns4

а не първо да премахнем старите nameserver-и и едва след това да започнем добавянето на новите.

При additive подход resolver-и със стара информация продължават да използват вече работещата DNS инфраструктура, докато новата постепенно влиза в употреба.

UDP порт 53 не е достатъчен

DNS традиционно се свързва с UDP порт 53.

Това обаче не означава, че е достатъчно да бъде разрешен само:

UDP/53

Authoritative DNS трябва да бъде достъпен и през:

TCP/53

TCP се използва в редица случаи — например при по-големи DNS отговори, fallback след truncated UDP response, някои DNSSEC сценарии и други операции.

Затова firewall конфигурацията трябва да позволява:

UDP 53
TCP 53

както за IPv4, така и за IPv6, когато DNS сървърът е публикуван и през IPv6.

DNSSEC изисква още повече внимание

При DNSSEC parent зоната може да съдържа DS запис, който криптографски свързва parent зоната с DNSKEY записите на child зоната.

Тогава архитектурата изглежда концептуално така:

Parent DS
     ↓
Child DNSKEY
     ↓
Signed DNS zone

Промяната на authoritative DNS инфраструктура при активен DNSSEC трябва да отчита тази верига.

Грешна DNSSEC конфигурация може да бъде значително по-сериозна от обикновен грешен A запис.

При наличен DS запис и невалидна DNSSEC верига validating resolver-и могат изцяло да откажат резолването на домейна.

Затова проверката за активен DNSSEC трябва да бъде част от предварителния checklist при всяка значима промяна на authoritative DNS инфраструктурата.

Как трябва да изглежда един DNS health check?

При сериозна инфраструктура проверката не трябва да се свежда до:

ping ns1.example.net

Това почти нищо не доказва за DNS услугата.

Една качествена проверка трябва да установи поне:

Authoritative response: YES
UDP/53: YES
TCP/53: YES
SOA serial: синхронизиран
NS records: коректни
A/AAAA адреси: коректни
Glue records: коректни
Parent delegation: коректна
DNSSEC chain: валидна, ако се използва
Zones: синхронизирани
Firewall: позволява public DNS

Полезни инструменти при BIND инфраструктура са:

dig
named-checkzone
named-checkconf
rndc zonestatus

А при проверка на цялата DNS delegation верига:

dig +trace example.net

е един от най-полезните инструменти.

TTL и DNS propagation

DNS промените не се появяват навсякъде едновременно.

Ако определена DNS информация има TTL:

това означава:

86400 секунди = 24 часа

Resolver, който вече е кеширал старата информация, може да продължи да я използва до изтичането на съответния TTL.

Това не означава непременно, че има проблем.

При additive промяна:

преди:

ns1
ns2


след:

ns1
ns2
ns3
ns4

resolver със стар кеш продължава да използва валидните ns1 и ns2.

Resolver, който вече е получил новата delegation информация, може да използва и ns3 и ns4.

Именно затова additive DNS промяната е значително по-безопасна от директната подмяна на вече работещите nameserver-и.

Какво не трябва да правим при production DNS?

Няколко грешки са особено рискови:

да променяме едновременно child зоната, glue records, firewall и DNS софтуера;
да премахваме старите nameserver-и преди новите да са напълно проверени;
да приемаме, че два NS hostname-а означават два независими DNS сървъра;
да разчитаме само на backup като средство за High Availability;
да редактираме ръчно zone файлове, когато control panel управлява същите файлове;
да изграждаме двупосочна административна синхронизация без ясно определен source of truth;
да проверяваме DNS само от самия сървър;
да проверяваме само UDP/53 и да забравяме TCP/53;
да правим DNSSEC промени без предварителна проверка на DS и DNSKEY;
да извършваме няколко критични инфраструктурни промени едновременно.

При DNS инфраструктурата простотата и ясната последователност почти винаги са предимство.

DNS инфраструктурата трябва да се разглежда като отделна система

Една зряла hosting архитектура не трябва да мисли:

„Имаме два nameserver-а, следователно сме защитени.“

По-правилният въпрос е:

„Какво ще се случи, ако целият физически сървър, на който се намира тази DNS услуга, изчезне в този момент?“

Следващият въпрос е още по-важен:

„Може ли Internet resolver, който няма нищо кеширано, все още да открие останалата работеща инфраструктура?“

Това е много по-близо до реален DNS failover тест.

Не е достатъчно даден домейн да продължава да се отваря през браузъра на администратор, който може да разполага с валиден DNS кеш.

Истинският тест е дали чист recursive resolver може да премине през DNS йерархията и да достигне до работещ authoritative DNS сървър без зависимост от вече отпадналия компонент.

High Availability не означава непременно High Availability на самия сайт

Това разграничение също е важно.

Можем да изградим напълно отказоустойчива DNS инфраструктура и въпреки това самият уебсайт да работи само на един hosting server.

В такъв случай:

DNS Server A DOWN
→ DNS Server B продължава да работи
→ домейнът продължава да се резолва


Web Server DOWN
→ DNS продължава да работи
→ но самият сайт е недостъпен

DNS High Availability решава конкретно проблема с достъпността и откриваемостта на DNS информацията.

За пълен application failover са необходими допълнителни механизми — репликация на данни, load balancing, storage replication, database clustering, health checks и други технологии според конкретната инфраструктура.

Затова DNS redundancy не трябва да се представя като автоматична гаранция за пълна отказоустойчивост на цялата hosting услуга.

Заключение

Надеждният DNS не се изгражда просто чрез добавянето на още един NS запис.

Той изисква правилна комбинация от:

независими authoritative DNS сървъри;
коректна parent delegation;
правилни glue records;
синхронизирани DNS зони;
ясно определен административен source of truth;
достъпност през UDP и TCP порт 53;
правилно управляван TTL;
DNSSEC контрол, когато технологията се използва;
мониторинг;
backup;
контролирана процедура за промени.

Най-добрият модел съчетава live redundancy и disaster recovery.

Live redundancy гарантира, че DNS услугата може да продължи да работи при отпадане на определен инфраструктурен компонент.

Backup-ът гарантира, че DNS конфигурацията може да бъде възстановена при човешка грешка, повредена зона, неволно изтриване или пълна загуба на система.

Двете технологии се допълват, но не се заменят.

Основният принцип при изграждането на DNS инфраструктура за production hosting среда може да бъде формулиран сравнително просто:

Не трябва да съществува един инфраструктурен компонент, чието отпадане да направи останалата напълно работеща инфраструктура недостъпна само заради DNS.

Благодарим ви за вниманието!

Още полезни материали: