DNS зонов файл и ресурсни записи

Авторитетните неймсървъри съхраняват информацията за домейните в зонови файлове.

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

$ORIGIN е параметър по подразбиране, равен на най-високото ниво на авторитета на зоната.

Например, в зонов файл за конфигуриране на example.com. домейн, $ORIGIN ще има стойност example.com. .

$ORIGIN example.com.

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

По същия начин $TTL конфигурира времето за живот (time-to-live, TTL) на информацията, която предоставя.

$TTL 12h

Параметърът работи като таймер. Кеширащият неймсървър използва предварително записаните резултати, за да отговаря на запитвания, докато не изтече посоченият в TTL период от време.

Типове записи в DNS зонов файл

В рамките на зоновия файл може да има много различни видове записи. В статията ще разгледаме някои от по-често срещаните (или задължителни) типове записи.

SOA запис

Записът SOA (Start of Authority) е задължителен във всички зонови файлове. Той трябва да е първият реален запис в даден файл (въпреки че спецификациите $ORIGIN или $TTL може да се запишат преди него).

SOA секцията изглежда по следния начин:

$TTL 12h
$ORIGIN example.com. 
example.com.  IN  SOA  ns1.example.com. hostmaster.example.com. ( 
              2021011600 ; se = serial 
              3h         ; ref = refresh 
              15m        ; ret = update 
              3w         ; ex = expiry 
              2h20m      ; min = minimum 
              ) 

Нека обясним за какво е предназначена всяка част:

example.com. : посочва root домейна на зоната. Записът показва, че зоновият файл дефинира зоната на домейна example.com. . Често домейн името се замества с @, което е просто заместващ символ за съдържанието на променливата $ORIGIN, за която писахме малко по-горе.

IN SOA: посочва класа на зоната и може да приеме следните нечувствителни към регистъра (малки/главни букви) стойности – IN=Internet, CH=CHAOS (MIT LAN протокол) или HS=Hesiod (информационна услуга, използвана в MIT). Последните два класа се споменават главно поради исторически интерес, частично приложение има CHAOS като параметър в командата dig. IN SOA индикира, че това е запис в Start of Authority секцията на зонов файл.

ns1.example.com. : показва главния (primary, master) неймсървър за този домейн. Неймсървърът може да е главен (master) или вторичен (slave), а ако е конфигуриран динамичен DNS, един неймсървър трябва да бъде посочен като главен с този запис. Ако не е конфигуриран динамичен DNS, това е само запис за един от авторитетните неймсървъри.

hostmaster.example.com. : Това е имейл адресът на администратора на зоната. @ се заменя с точка в имейл адреса. Ако името в имейл адреса съдържа точка, тя се заменя (escape) с обратно наклонена черта \ в тази част (your.name@domain.com трябва да се въведе като your\name@domain.com).

serial 2021011600: Това е серийният номер на зоновия файл. Всеки път, когато редактирате зонов файл, трябва да увеличите това число, за да може зоновият файл да се разпространява правилно. Вторичните неймсървъри проверяват дали серийният номер на главния сървър за дадена зона е по-голям от този, който те имат в системата си. Ако е така, те изискват обновяване на зоновия файл, ако не, продължават да отговарят с информация от текущия зонов файл.

Стандартът RFC 1035 в частта за зоновите файлове определя времевите периоди в секунди, което води до много големи числа. В предходния фрагмент стойностите 3h, 15m, 3w и 2h20m използват BIND-специфична кратка форма за стойности от време в секунди. Необходимите кратки заместителни форми са m=минути, h=часове, d=дни и w=седмици. Редица алтернативни DNS приложения са възприели формата BIND като фактически стандарт без да се отменя стандартния синтаксис.

refresh 3h: интервал на опресняване на зоната. Това е времето, което вторичният неймсъвър изчаква, преди да се свърже с главния неймсъвър, за да провери дали има промяна в зоновия файл и ако има, да опресни своя кеш.

update 15m: интервал за повторение. Ако вторичният неймсъвър не може да се свърже с главния, когато изтече периода refresh, той ще изчака посочения update период от време и ще опита да се свърже отново.

expiry 3w: Това е периодът на изтичане. Ако вторичният неймсъвър не е успял да се свърже с главния за указания период от време, той спира да връща отговори като авторитетен неймсъвър за тази зона.

minimum 2h20m: Това е времето, през което неймсървър ще кешира съобщения за грешка (негативно кеширане) ако не може да открие търсения запис в този зонов файл.

Информацията в Start of Authority RR секцията от примера може да бъде записана на един ред:

@ IN SOA ns1.example.com. hostmaster.example.com. 2021011600 3h 15m 3w 3h

A и AAAA записи

Двата записа свързват хост име съответно с IPv4 или IPv6 адрес. Общият формат на тези записи е следният:

host IN A IPv4_address

host IN AAAA IPv6_address

Тъй като SOA записът посочва ns1.example.com като главен неймсървър, трябва да създадете А запис (glue) към IP адрес, тъй като ns1.example.com е дефиниран в зоната example.com.

Записът може да изглежда по следния начин:

ns1 IN A 11.22.11.22

Забележете, че не трябва да въвеждате пълното домейн име. Може просто да дадете хост, без FQDN и DNS сървърът ще запълни останалата част със стойността $ORIGIN.

Ако държите да бъдете семантично изрядни, може да ползвате FQDN (след домейна има точка, която представлява root зоната на DNS) и същият запис ще изглежда така:

ns1.example.com. IN А 11.22.11.22

В зоновия файл се дефинира IP адресът на домейна:

example.com. IN A 22.22.22.22

@ IN A 22.22.22.22

както и пълната форма на домейна www (домейн без www понякога се нарича гол):

www IN A 22.22.22.22

Също така, може да насочите всички хостове на домейна, за които няма конкретен запис, към същия сървър със символа wildcard * :

* IN A 22.22.22.22

dev IN A 33.33.33.33

Въпреки wildcard записа, поддомейнът dev.example.com ще се насочи към сървър с IP адреса в конкретния запис – 33.33.33.33.

Абсолютно по същия начин работят записите AAAA за IPv6 адресите.

CNAME записи

CNAME записите посочват псевдоними за каноничното име на сървъра (дефинирано от А/AAAA запис ).

Например, бихте могли да имате запис на име, определящ хоста server1 и след това да използвате www като псевдоним на този хост:

server1 IN A 11.11.11.11

www IN CNAME server1

Имайте предвид, че тези псевдоними идват с известни загуби от производителност, защото те изискват допълнителна заявка към сървъра. Същият резултат може да бъде постигнат чрез използване на допълнителни А/AAAA записи. Един от случаите, в които се препоръчва CNAME, е предоставяне на псевдоним за ресурс извън текущата зона.

MX записи

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

За разлика от другите типове записи, MX обикновено не свързват хост с IP адрес, защото те се отнасят за цялата зона. Като такива, те обикновено изглеждат така:

N MX 10 mail.example.com.

Имайте предвид, че в началото на реда няма хост име.

Обърнете внимание на цифрата преди хост името – 10. Тя посочва приоритета, когато има дефинирани множество мейл сървъри. По-ниските цифри посочват сървърите с по-висок приоритет.

Записът MX обикновено трябва да сочи към хост име, дефинирано с A/AAAA запис, а не към хост име, дефинирано с псевдоним (CNAME).

Ако имате два пощенски сървъра, записите може да изглеждат така:

        IN MX 10 mail1.example.com.
        IN MX 50 mail2.example.com.
mail1   IN A 11.11.11.11
mail2   IN A 22.22.22.22

В този пример mail1 е мейл сървърът с по-висок приоритет и той ще обработва пощите на домейна, mail2 ще се използва само ако mail1 е недостъпен.

Горният запис може да се запише и по този начин:

         IN MX 10 mail1
         IN MX 50 mail2
mail1    IN A 11.11.11.11
mail2    IN A 22.22.22.22

NS записи

Този тип записи определя неймсървърите, които се използват за тази зона. Подобно на MX записите, NS записите са параметри, обхващащи цялата зона, така че те също не получават хостове:

IN NS ns1.example.com.
IN NS ns2.example.com.

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

За да работят записите в примера, трябва да създадете glue записи, тъй като хост имената на неймсървърите са поддомейни на главния домейн на зоната:

        IN NS ns1.example.com.
        IN NS ns2.example.com.
ns1     IN A 11.22.33.44
ns2     IN A 22.33.44.55

Ако неймсървърите ползват различни хост имена няма нужда от glue записи:

IN NS dns1.test.net.
IN NS dns2.test.net.

Обратни PTR записи

PTR записите се използват за дефиниране на име, свързано с IP адрес. Записите за PTR са обратното на запис А или АААА. Записите за PTR са уникални по това, че ползват домейн in-addr.arpa и са делегирани на собствениците на IP адресите.

Ето един пример за PTR запис – IP 11.22.33.44 отговаря на хост име host.example.com:

44.33.22.11.in-addr.arpa. 33692 IN PTR host.example.com.

За наличие на PTR запис се проверява с командата dig. Опцията +short се добавя, за да се намали изходната информация за хост името:

dig -х 8.8.4.4 +short

Резултатът за горната команда ще бъде хост името в PTR записа за IP адрес 8.8.4.4:

google-public-dns-b.google.com.

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

Забележка: Важно е FQDN в PTR записа да има съответен съвпадащ А/АААА запис:

44.33.22.11.in-addr.arpa. 33692 IN PTR host.example.com.

host.example.com. 33692 IN А 11.22.33.44

CAA записи

Certification Authority Authorization (CAA) записите се използват, за да посочат кои Сертифициращи органи ( Certificate Authorities, CA) имат право да издават SSL/TLS сертификати за домейна. От 8 септември 2017 г. всички CA трябва да проверят тези записи преди да издадат сертификат. Ако не е налице запис, всеки CA може да издаде сертификат. В противен случай само посочените CA могат да издават сертификати. Записите на CAA могат да се прилагат към отделни хостове или цели домейни.

Пример за CAA запис:

example.com. IN CAA 0 issue "digicert.com"

Типът хост (IN) и записът (CAA) са общи DNS полета. Специфичната информация за CAA по-горе е в края на записа и се състои от три части: флаг (0), таг (issue) и стойност („digicert.com“):

• Флаговете са цяло число, което показва как един CA издател трябва да се справя с маркери, които не разбира. Ако флагът е 0, записът ще бъде пренебрегнат. Ако е 1, CA трябва да откаже да издаде сертификата.
• Таговете са низове, които обозначават целта на CAA записа. Понастоящем те могат да бъдат issue, за да упълномощите CA да създаде сертификат за конкретно хост име, issuewild за издаване на wildcard сертификати или iodef за определяне на URL адрес, в който CA могат да подават сигнал за нарушения.
• Стойностите са низ, свързан с тага на записа. За issue и issuewild това обикновено е домейнът, за който давате разрешение на CA. За iodef това може да е URL адрес на формуляр за връзка или мейл за обратна връзка.

SRV запис

SRV записът има за цел да предостави информация за наличните системни услуги, най-често използвани при конфигуриране на SIP.

SRV записите имат уникален синтаксис:

_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.

Какво означават отделните полета в един SRV запис?

_service._proto.name. TTL class SRV priority weight port target

• service: символичното име на услугата;
• proto: транспортният протокол на услугата – обикновено е TCP или UDP;
• name: домейн името във FQDN формат (да завършва с точка);
• TTL: стандартният параметър time-to-live;
• class: стандартно поле за DNS клас (това винаги е IN);
• priority: приоритетът на хоста, както при MX записите по-ниската стойност означава по-висок приоритет;
• weight: относителна тежест за записи с един и същ приоритет, по-висока стойност означава по-висок приоритет;
• port: TCP или UDP портът, на който работи услугата;
• target: каноничното име на хоста, предоставящ услугата, във FQDN формат (да завършва с точка).

TXT записи

TXT записите могат да съдържат свободен текст от всякакъв вид. Пълно квалифицираното домейн име може да има много TXT записи. Най-често използваните TXT записи са Sender Policy Framework (SPF), DomainKeys (DK), DomainKeys Identified E-mail (DKIM) и Domain-based Message Authentication, Reporting & Conformance (DMARC). TXT записите са били използвани също за публикуване на информация за сървър, дата център, мрежа, данни и др.

SPF запис:

v=spf1 mx include:_spf.google.com -all

DKIM запис:

selector1._domainkey.example.com TXT k=rsa;p=J8eTBu224i086iK

DMARC запис:

_dmarc.example.com TXT v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com