DNS е абревиатура от Domain Name System и в превод на български език означава система за домейн имена. Нейната роля е да преобразува домейн имената на уеб сайтовете, които изписваме в браузъра, за да достъпим даден уебсайт, в IP адреси.
Нека разгледаме следния пример: ако трябва да достъпим даден уебсайт - за нас много по-лесно би било да отворим браузъра и в адресното поле да изпишем домейн името на сайта, напр. delta.bg, вместо неговия IP адрес - 185.55.230.195.
Използването на домейн имена е удобно за нас хората, но браузърите работят с Internet Protocol (IP) адреси. За да могат браузърите да "прочетат" и "разберат" на кой IP адрес съответства дадено домейн име, е въведена системата за домейн имена, популярна с абревиатурата DNS (Domain Name System). Тя е нещо, като речник или преводач на домейн имената в IP адреси.
Как работи DNS?
Процесът на DNS преобразуването включва преобразуване на хост име (hostname) като “www.delta.bg” в удобен за компютър IP адрес като “185.55.230.195”.
IP адрес се дава на всяко устройство в интернет и този адрес е необходим, за да се намери съответното устройство - както адрес на една улица се използва за намиране на определен дом.
Когато потребител иска да зареди уеб страница, трябва да се извърши превод между това, което потребителят въвежда в своя уеб браузър (example.com) и удобния за машината адрес, необходим за намиране на уеб страницата example.com.
За да разберете процеса зад DNS преобразуването е важно да научите за различните хардуерни компоненти, между които трябва да премине една DNS заявка.
DNS сървъри, които участват в зареждането на уеб страниците
Зареждането на уеб страниците се осъществява посредством 4 DNS сървъра. Това са:
- DNS resolver (резолвер)
- Root nameserver (Главен сървър за имена)
- TLD nameserver (Top Level Domain nameserver)
- Authoritative nameserver (Авторитетен сървър за имена)
Нека разгледаме всеки от тях, за да изясним кой каква роля има в процеса.
DNS resolver (резолвер)
DNS resolver (резолвер) е основният посредник между компютър и други DNS сървъри. Целта му е да препрати заявката за достъпване на дадено устройство към други DNS сървъри и след като бъде изпълнена, да я върне обратно.
Когато DNS резолверът получи заявка, той първо ще потърси в своя кеш (запис на всички заявки, направени към DNS сървър от Вашия браузър), за да намери съответстващ IP адрес за името на домейна.
Ако IP адресът бъде намерен, заявката изпратена до DNS сървърите, свършва дотук и сайтът, който желаете да достъпите ще бъде зареден незабавно.
Въпреки това, ако не бъде намерено съвпадение в неговия кеш, DNS резолверът ще изпрати заявката до следващия DNS сървър – главния сървър за имена (root name server).
Root nameserver (Главен сървър за имена)
Root nameserver (Главен сървър за имена) е основният сървър за имена или главният DNS сървър в най-горната част на DNS йерархията.
Той не съхранява информацията, която търсите, което е IP адресът, съответстващ на домейн името, но дава указания къде може да бъде намерен.
След като главният сървър за имена получи заявка от DNS резолвер, той ще идентифицира домейна от първо ниво (top-level-domain) на домейн името. След това ще даде указания на DNS резолвера да отиде до съответния сървър за имена (TLD nameserver).
TLD nameserver
TLD nameserver е DNS сървър на домейни от първо ниво (Top Level Domain), който съхранява цялата информация за всички домейн имена, които споделят общо разширение на домейн.
Сървърът за имена на домейните с разширение .com (TLD) съдържа всички данни, свързани с всички .com домейни. Следователно, ако желаете да получите достъп до facebook.com, Вашият браузър трябва да се свърже с .com TLD сървъра.
Authoritative nameserver
Authoritative nameserver (Авторитетен сървър за имена) е последният участник в процеса на преобразиване при използване на системата за домейн имена - DNS.
Той съхранява цялата информация, свързана с домейн името, което желаете да достъпите и ще предостави на DNS резолвера IP адреса, за да може сайта, който желаете да достъпите да се зареди в браузъра на Вашия компютър, таблет или телефон.
В края на процеса, резолверът извършва DNS кеширане, като съхранява IP адресите, събрани от авторитетни сървъри за имена като временни данни.
Каква е разликата между авторитетен DNS сървър и DNS резолвер?
DNS резолверът е първият участник в просеца по DNS преобразуване на домейн име в IP адрес. При постъпила заявка, DNS резолверът първо поверява за наличен запис в своя кеш и ако не намира такова създава поредица от заявки, докато достигне до авторитетния DNS сървър за искания запис (или изтича време или връща грешка, ако не бъде намерен запис).
Authoritative DNS сървър е последният по веригата за преобразуване на домейн име в IP адрес. Той съхранява необходимата информация за домейн имената и при запитване ще отговори, за да може уеб браузъра, който прави заявката, да достигне до IP адреса, необходим за достъп до уебсайт или други уеб ресурси.
В случаите, когато заявката е за поддомейн като “blog.example.com”, допълнителен сървър за имена ще бъде добавен към последователността след авторитетния сървър, който отговаря за съхраняването на CNAME записа на поддомейна.
Какви са стъпките при DNS lookup?
В повечето ситуации системата за домейн имена - DNS се грижи името на домейна да бъде преведено в съответния IP адрес.
За проследим как работи този процес, е необходимо да разгледаме процеса на DNS lookup от браузъра и обратно. Нека да разгледаме стъпките.
Забележка: Често информацията за търсене в DNS се кешира или локално на компютъра, който извършва заявката или отдалечено в DNS инфраструктурата.
Стандартно процесът по DNS lookup включва 8 стъпки, но когато DNS информацията се кешира, част от стъпките се пропускат, което прави процесът много по-бърз. Примерът по-долу включва всички 8 стъпки, когато нищо не е кеширано.
8-те стъпки при DNS търсене:
Потребителят въвежда „example.com“ в уеб браузъра на своето устройство (лаптоп, телефон, таблет) и заявката се придвижва през интернет към DNS резолвер.
- При липса на кеш, DNS резолверът отправя запитване към DNS Root nameserver-а.
- DNS Root nameserver-ът отговаря на DNS резолвъра с адреса на съответния TLD сървър (като .com, .net), който съхранява информацията за домейните със съответното разширение. Когато търсим example.com, заявката се насочва към .com TLD.
- DNS резолвърът прави заявка към съответния TLD сървър - в случая .com TLD.
- TLD сървърът отговаря с IP адреса на домейн nameserver-а (сървърът, на който се намира домейн името) example.com.
- И накрая, DNS резолверът изпраща заявка до сървъра където се намира домейн името example.com
- IP адресът на example.com се връща към DNS резолвера
- DNS резолверът отговаря на уеб браузъра с IP адреса на заявения домейн.
След като 8-те стъпки на DNS търсенето върнат IP адреса за example.com, браузърът може да направи заявка за уеб страницата:
- Браузърът прави HTTP заявка към IP адреса.
- Сървърът на този IP адрес връща уеб страницата, която се изобразява на нашия уеб браузър.
Какви са видовете DNS заявки?
Има 3 вида DNS заявки. Две от тях видяхте на схемата. Ето повече информация за тях:
Рекурсивна DNS заявка
Рекурсивната DNS заявка ще се опита да получи резолюция на DNS име чрез свързване към рекурсивен DNS сървър. Повечето от тях се управляват от доставчици на интернет услуги (ISP) и ще бъдат стандартни за средния потребител, освен ако не бъдат променени.
След като компютърът се свърже с зададения рекурсивен сървър, той ще попита „какъв е IP адресът за този уебсайт?“
Първото нещо, което рекурсивният сървър след това ще направи, е да провери дали IP адресът за въпросния URL може да бъде локализиран в неговия локален кеш.
Такъв би бил случаят, ако сте посетили уебсайта преди, тъй като IP адресът ще бъде съхранен в локално хранилище. Ако е така, потребителят успешно ще може да зареди уебсайта.
Ако обаче това не е така и не съществува в локалния кеш, тогава рекурсивният DNS сървър ще се опита да получи IP адреса чрез други средства.
За щастие, повечето интернет доставчици обикновено предоставят рекурсивен DNS точно за тази цел, който съдържа собствена кеш система, така че потребителят не трябва да разчита на това, че е посетил уебсайта преди или на локален кеш.
Следващата стъпка в рекурсивния процес ще включва изпробване на заявката отново и отново, докато не бъде даден отговор.
Заявката се изпълнява многократно, за да се провери дали DNS заявката може да бъде попълнена от собствения й кеш или чрез запитване към други надеждни DNS сървъри.
Той се придвижва надолу в списъка си с надеждни DNS сървъри в йерархичен ред, за да гарантира, че най-важните DNS сървъри се проверяват първи.
След като този процес приключи, потребителят ще бъде върнат или с IP адрес, унифициран локатор на ресурси (URL) или съобщение за грешка, че исканият (сайт) не съществува.
Нерекурсивна DNS заявка
Нерекурсивната DNS заявка може да върне отговор незабавно, тъй като DNS резолверът вече знае как да получи отговора на заявката.
Това е така, защото DNS записът или се съхранява в локалния кеш, или е направена заявка към DNS сървър за имена, който е достоверен и определено съдържа IP адреса за името на хоста.
С други думи, отговорът незабавно се връща на клиента, тъй като за разлика от рекурсивните и итеративни заявки, няма нужда от допълнителни кръгове от заявки.
Итеративна DNS заявка
При итеративната DNS заявка работи, като позволява на клиента да комуникира директно с всеки DNS сървър, участващ в търсенето. Това е в контраст с рекурсивните DNS заявки, които използват DNS сървър за комуникация с други DNS сървъри.
След като сървърът получи итеративна заявка, той или ще върне IP адреса на исканото име на хост, или ще издаде препратка, което означава, че ще произведе адреса на DNS сървър, който трябва да знае. След това клиентът може директно да отправи итеративна заявка към този препоръчан сървър.
Какво е DNS кеширане? Къде се извършва DNS кеширането?
Целта на кеширането е временно да се съхраняват данни на място, което води до подобрения в производителността и надеждността на заявките за данни.
DNS кеширането включва съхраняване на данни по-близо до искащия клиент, така че DNS заявката да може да бъде изпълнена по-рано и допълнителните заявки по-надолу по веригата за търсене на DNS могат да бъдат избегнати, като по този начин се подобрява времето за зареждане и се намалява консумацията на честотна лента/CPU.
DNS данните могат да бъдат кеширани на различни места, всяко от които ще съхранява DNS записи за определен период от време, определен от времето за живот (TTL).
DNS кеширане в браузъра
Съвременните уеб браузъри са проектирани по подразбиране да кешират DNS записи за определен период от време. Целта тук е очевидна; колкото по-близо се случва DNS кеширането до уеб браузъра, толкова по-малко стъпки за обработка трябва да бъдат предприети, за да се провери кеша и да се направят правилните заявки към IP адрес. Когато се направи заявка за DNS запис, кешът на браузъра е първото място, което се проверява за искания запис.
В Chrome можете да видите състоянието на вашия DNS кеш, като отидете на chrome://net-internals/#dns.
DNS кеширане на ниво операционна система (ОС)
DNS резолверът на ниво операционна система е втората и последна локална спирка, преди DNS заявка да напусне Вашата машина. Процесът във Вашата операционна система, който е проектиран да обработва тази заявка, обикновено се нарича „stub resolver“ или DNS клиент.
Когато “sub resolver” получи заявка от приложение, той първо проверява собствения си кеш, за да види дали в него е съхранен записа. Ако такъв няма, той изпраща DNS заявка (със зададен рекурсивен флаг) извън локалната мрежа към DNS рекурсивен резолвер в доставчика на интернет услуги (ISP).
Когато рекурсивният резолвер в ISP получи DNS заявка, както при всички предишни стъпки, той ще провери дали исканата транслация на хост към IP адрес вече е съхранена в неговия локален слой за устойчивост “persistent layer”.
Рекурсивният резолвер има и допълнителна функционалност в зависимост от типовете записи, които има в своя кеш:
- Ако резолверът няма А записите, но има NS записите за авторитетните сървъри за имена, той ще отправи запитване към тези сървъри за имена директно, заобикаляйки няколко стъпки в DNS заявката. Този пряк път предотвратява търсенето от главния и .com сървърите на имена (в нашето търсене за example.com) и помага за по-бързото разрешаване на DNS заявката.
- Ако резолверът няма NS записи, той ще изпрати заявка до TLD сървърите (.com в нашия случай), като прескочи главния сървър.
- В редки случаи, ако резолверът няма записи, сочещи към TLD сървърите, той ще отправи запитване към основните сървъри. Това обичайно се случва, след като DNS кешът е изчистен.
Какво е DNS зона и DNS записи ?
DNS зоната служи за съхраняване на DNS записите за определен домейн. За да започнете да хоствате своя домейн, трябва да създадете DNS зона за това домейн име, след което всеки DNS запис за Ввашия домейн ще се създава в тази DNS зона.
Например домейнът „example.com“ може да съдържа няколко DNS записа, като „mail.example.com“ (за пощенски сървър) и „www.example.com“ (за уеб сайт).
DNS записите (известни още като “zone files”) са инструкции, които се намират в авторитетни DNS сървъри и предоставят информация за домейна, включително кой IP адрес е свързан с този домейн и как да се обработват заявки за този домейн.
Тези записи се състоят от поредица от текстови файлове, написани в съответния DNS синтаксис - низ от знаци, използвани като команди, които казват на DNS сървъра какво да прави.
Всички DNS записи също имат „ TTL “, което означава време за живот и показва колко често DNS сървърът ще опреснява този запис.
Кои са най-често срещаните видове DNS записи?
Нека заедно прегледаме кои са най-често използваните записи в DNS зоната:
А запис в DNS зоната
А записът съдържа IP адреса на домейна. Буквата "A“ в името на записва идва от „адрес“ и това е най-фундаменталният тип DNS запис: той показва IP адреса на даден домейн.
А записите съдържат само IPv4 адреси. Ако даден уебсайт има IPv6 адрес, той ще използва „AAAA“ запис.
Ето пример за запис A:
| example.com | тип запис: | стойност: | TTL |
| @ | А | 192.0.2.1 | 14400 |
Символът "@" в този пример показва, че това е запис за основния домейн, а стойността "14400" е TTL (време за живот), посочено в секунди. TTL по подразбиране за A записи е 14 400 секунди. Това означава, че ако запис А бъде актуализиран, са необходими 240 минути (14 400 секунди), за да влезе в сила.
По-голямата част от уебсайтовете имат само един A запис, но е възможно да има няколко. Някои уебсайтове с по-висок профил ще имат няколко различни A записа като част от техника, наречена кръгово балансиране на натоварването, която може да разпредели трафик на заявка към един от няколко IP адреса, всеки от които хоства идентично съдържание.
Кога се използват DNS A записи?
Най-честата употреба на A записи е за намиране на IP адрес: съпоставя се домейн името (като „example.com“) с IPv4 адрес.
По този начин устройството на потребителя може да се свърже и да зареди уебсайт, без потребителят да запомня и въвежда действителния IP адрес. Уеб браузърът на потребителя автоматично извършва това чрез изпращане на заявка до DNS резолвер .
DNS A записите се използват и за управление на Blackhole List (DNSBL), базиран на системата за имена на домейни. DNSBL могат да помогнат на пощенските сървъри да идентифицират и блокират имейл съобщения от известни домейни на спамери.
AAAA запис в DNS зоната
AAAA записът съдържа IPv6 адрес за домейн. DNS “AAAA“ записите са точно като DNS A записите , с изключение на това, че съхраняват IPv6 адреса на домейна вместо неговия IPv4 адрес.
IPv6 е най-новата версия на интернет протокола (IP) . Една от важните разлики между IPv6 и IPv4 е, че IPv6 адресите са по-дълги от IPv4 адресите. Интернет се изчерпва от IPv4 адреси, но IPv6 адресите предлагат много повече възможни IP адреси.
Ето пример за AAAA запис:
| example.com | тип запис: | стойност: | TTL |
| @ | АААА | 2001:0db8:85a3:0000:0000:8a2e:0370:7334 | 14400 |
Кога се използват AAAA записи?
Подобно на A записите, AAAA записите позволяват на клиентските устройства да научат IP адреса за домейн име, за да може клиентското устройство може да се свърже и да зареди уебсайта.
AAAA записите се използват само когато даден домейн има IPv6 адрес в допълнение към IPv4 адрес и когато въпросното клиентско устройство е конфигурирано да използва IPv6.
Всички домейни имат един или повече IPv4 адреси и съответно A записи, не всички домейни имат IPv6 адреси и не всички потребителски устройства са конфигурирани да използват IPv6.
IPv6 навлиза все повече. Това вероятно ще продължи да е така, тъй като броят на наличните IPv4 адреси бързо намалява, което често принуждава множество устройства да споделят IPv4 адрес. Вероятно в бъдеще всички домейни ще имат AAAA записи.
CNAME запис в DNS зоната
CNAME записът препраща един домейн или поддомейн към друг и не предоставя IP адрес.
CNAME запис се използва вместо запис A, когато домейн или поддомейн е псевдоним на друг домейн. Всички CNAME записи трябва да сочат към домейн и никога към IP адрес.
Да предположим например, че blog.example.com има CNAME запис със стойност „example.com“ (без „blog“). Това означава, че когато DNS сървър достигне DNS записите за blog.example.com, той всъщност задейства друго DNS търсене към example.com, връщайки IP адреса на example.com чрез неговия A запис. В този случай бихме казали, че example.com е истинското име на blog.example.com.
Често, когато сайтовете имат поддомейни като blog.example.com или shop.example.com, тези поддомейни ще имат CNAME записи, които сочат към основен домейн (example.com).
Така, ако IP адресът на хоста се промени, само DNS A записът за основния домейн трябва да се актуализира и всички CNAME записи ще последват заедно с всички промени, направени в корена.
Пример за CNAME запис:
| blog.example.com | тип запис: | стойност: | TTL |
| @ | CNAME | е псевдоним на example.com | 32600 |
Може ли CNAME запис да сочи към друг CNAME запис?
Насочването на CNAME запис към друг CNAME запис е неефективно, тъй като изисква множество DNS търсения, преди домейнът да може да бъде зареден — което забавя потребителското изживяване — но е възможно.
Например blog.example.com може да има CNAME запис, който сочи към CNAME запис на www.example.com, който след това сочи към A запис на example.com.
Пример със CNAME запис за blog.example.com:
| blog.example.com | тип запис: | стойност: | TTL |
| @ | CNAME | е псевдоним на www.example.com | 32600 |
Което сочи към CNAME за www.example.com:
| www.example.com | тип запис: | стойност: | TTL |
| @ | CNAME | е псевдоним на example.com | 32600 |
Тази конфигурация добавя допълнителна стъпка към процеса на DNS търсене и трябва да се избягва, ако е възможно. Вместо това CNAME записите както за blog.example.com, така и за www.example.com трябва да сочат директно към example.com.
Какви ограничения има за използването на CNAME записи?
Нека разгледаме и какви са ограниченията при използване на CNAME записи в DNS зоната:
MX запис в DNS зоната
MX записът насочва имейл към имейл сървър. MX и NS записите не могат да сочат към CNAME запис; те трябва да сочат към A запис (за IPv4) или AAAA запис (за IPv6).
- MX запис е запис за обмен на поща, който насочва имейл към пощенски сървър.
- NS запис е запис на "сървър за имена" и показва кой DNS сървър е авторитетен за този домейн.
Пример за MX запис:
| example.com | тип запис: | приоритет: | стойност: | TTL |
| @ | MX | 10 | mailhost1.example.com | 45 000 |
| @ | MX | 20 | mailhost2.example.com | 45 000 |
Числата за „приоритет“ преди домейните за тези MX записи показват предпочитание; по-ниската стойност на „приоритет“ е за предпочитане.
Сървърът винаги първо ще опита mailhost1, тъй като 10 е по-малко от 20. В резултат на неуспешно изпращане на съобщение сървърът по подразбиране ще използва mailhost2.
Услугата за електронна поща може също да конфигурира този MX запис, така че и двата сървъра да имат еднакъв приоритет и да получават еднакво количество поща:
| example.com | тип запис: | приоритет: | стойност: | TTL |
| @ | MX | 10 | mailhost1.example.com | 45 000 |
| @ | MX | 10 | mailhost2.example.com | 45 000 |
Тази конфигурация позволява на доставчика на имейл да балансира равномерно натоварването между двата сървъра.
Какъв е процесът на заявка за MX запис?
Софтуерът на агента за прехвърляне на съобщения (MTA) отговаря за запитването на MX записи. Когато потребител изпрати имейл, MTA изпраща DNS заявка, за да идентифицира пощенските сървъри за получателите на имейла.
MTA установява SMTP връзка с тези пощенски сървъри, започвайки с приоритетните домейни (в първия пример по-горе, mailhost1).
Какво е резервен MX запис?
Резервният MX запис е просто MX запис за пощенски сървър с по-висока стойност на „приоритет“ (което означава по-нисък приоритет), така че при нормални обстоятелства пощата ще отива до сървърите с по-висок приоритет.
В първия пример по-горе mailhost2 ще бъде „резервният“ сървър, тъй като имейл трафикът ще се обработва от mailhost1, докато той е готов и работи.
Могат ли MX записи да сочат към CNAME?
Записът CNAME се използва за препращане към псевдоним на домейн вместо действителното му име. CNAME записите обикновено сочат към A запис (в IPv4) или AAAA запис (в IPv6) за този домейн. Въпреки това MX записите трябва да сочат директно към A запис или AAAA запис на сървъра . Посочването на CNAME е забранено от RFC стандартите, които определят как функционират MX записите.
DNS записът за „обмен на поща“ (MX) насочва имейл към пощенски сървър. MX записът показва как имейл съобщенията трябва да бъдат маршрутизирани в съответствие с Simple Mail Transfer Protocol ( SMTP , стандартният протокол за всички имейли). Подобно на CNAME записите , MX записът трябва винаги да сочи към друг домейн.
TXT запис в DNS зоната
TXT записът позволява на администратора да съхранява текстови бележки в записа. Тези записи често се използват за сигурност на имейла.
Пример за TXT запис:
| example.com | тип запис: | стойност: | TTL |
| @ | TXT | Определено не е спам. | 32600 |
Днес две от най-важните употреби на DNS TXT записите са предотвратяването на спам по имейл и проверката на собствеността върху домейна, въпреки че първоначално TXT записите не са предназначени за тези употреби.
Какъв вид данни могат да се съдържат в TXT запис?
RFC стандарите само указват, че „текстовите низове“ влизат в полето „стойност“ на TXT запис. Това може да бъде всеки текст, който администраторът иска да свърже с домейна си.
Повечето DNS сървъри ще поставят ограничение за това колко големи могат да бъдат TXT записите и колко записи могат да съхраняват, така че администраторите не могат да използват TXT записи за големи по обем данни.
Какъв е официалният формат за съхраняване на данни в TXT запис?
През 1993 г. Internet Engineering Task Force (IETF) дефинира формат за съхраняване на атрибути и съответните им стойности в полето „стойност“ на TXT записите. Форматът беше просто атрибутът и стойността, съдържащи се в кавички (") и разделени със знак за равенство (=), като например:
"attribute=value"
RFC 1464 от 1993 г., който дефинира този формат, включва следните примери:
| host.widgets.com | тип запис: | стойност: |
| @ | TXT | "принтер=lpr5" |
| sam.widgets.com | тип запис: | стойност: |
| @ | TXT | "любима напитка=портокалов сок" |
Това определение обаче се счита за експериментално и на практика не се приема често. Някои DNS администратори следват свои собствени формати в TXT записите, ако изобщо използват TXT записи.
TXT записите могат също да бъдат форматирани по специфичен начин за определени употреби, описани по-долу — например политиките на DMARC трябва да бъдат форматирани по стандартизиран начин.
Как TXT записите помагат за предотвратяване на спам по имейл?
Спамърите често се опитват да фалшифицират или подправят домейните, от които изпращат своите имейл съобщения. TXT записите са ключов компонент на няколко различни метода за удостоверяване на имейл, които помагат на имейл сървъра да определи дали съобщението е от доверен източник.
Често срещаните методи за удостоверяване на имейли включват поща с идентифициране на ключове на домейн (DKIM), рамка за правила за изпращача (SPF) и базирано на домейн удостоверяване, отчитане и съответствие на съобщения (DMARC). Чрез конфигуриране на тези записи, домейн операторите могат да направят по-трудно за спамерите да фалшифицират техните домейни и могат да проследяват опитите за това.
SPF, DKIM и DMARC записи в DNS зоната за имейл удостоверяване
SPF записи: SPF TXT записите изброяват всички сървъри, които са упълномощени да изпращат имейл съобщения от домейн.
DKIM записи: DKIM работи чрез цифрово подписване на всеки имейл с помощта на двойка публичен-частен ключ. Това помага да се провери дали имейлът наистина е от домейна, от който се твърди, че е. Публичният ключ се хоства в TXT запис, свързан с домейна.
DMARC записи: DMARC TXT запис препраща към SPF и DKIM политиките на домейна. Трябва да се съхранява под заглавието _dmarc.example.com. с „example.com“, заменено с действителното домейн име. „Стойността“ на записа е DMARC политиката на домейна.
За повече информация, разгледайте нашата статия: Как да защитите своя бизнес от злоупотреба с фишинг, спуфинг и спам имейли с SPF, DKIM и DMARC?
Как TXT записите помагат при проверката на собствеността върху домейна?
Въпреки че проверката на собствеността върху домейна първоначално не е била функция на TXT записите, този подход е възприет от някои инструменти за уеб администратори и облачни доставчици.
Чрез качване на нов TXT запис с включена специфична информация или редактиране на текущия TXT запис, администраторът може да докаже, че контролира този домейн.
Инструментът или клауд провайдърът могат да проверят TXT записа и да видят, че той е променен, както е поискано. Това се прилага и за потвърждаване на имейл адрес, като отваряне на имейл и кликане върху връзка в имейла.
NS запис в DNS зоната
NS запис - NS в името на записа е абревиатура от nameserver и означава „сървър за имена“, а записът на сървъра за имена показва кой DNS сървър е авторитетен за този домейн (т.е. кой сървър съдържа действителните DNS записи ).
NS записите указват как да се намери IP адреса на домейна. Един домейн често има множество NS записи, които могат да посочат първичен и вторичен сървър на имена за този домейн.
Без правилно конфигурирани NS записи, потребителите няма да могат да заредят уебсайт или приложение.
Ето пример за NS запис:
| example.com | тип запис: | стойност: | TTL |
| @ | NS | ns1.exampleserver.com | 21600 |
Имайте предвид, че NS записите никога не могат да сочат към запис с канонично име (CNAME) .
Какво е неймсървър?
Сървърът за имена е вид DNS сървър. Това е сървърът, който съхранява всички DNS записи за домейн, включително A записи , MX записи или CNAME записи.
Почти всички домейни разчитат на множество сървъри за имена, за да увеличат надеждността: ако един сървър за имена се повреди или е недостъпен, DNS заявките могат да отидат до друг.
Обикновено има един първичен сървър за имена и няколко вторични сървъра за имена, които съхраняват точни копия на DNS записите в основния сървър.
Актуализирането на основния сървър за имена ще задейства актуализация и на вторичните сървъри за имена.
Кога трябва да се актуализират или променят NS записите?
Администраторите трябва да актуализират своите NS записи, когато трябва да променят сървърите за имена на своя домейн. Например, някои облачни доставчици предоставят сървъри за имена и изискват от клиентите си да сочат към тях.
Администраторите могат също да пожелаят да актуализират своите NS записи, ако предпочитат поддомейнът да използва различни сървъри за имена. В горния пример сървърът за имена за example.com е ns1.exampleserver.com.
Ако администраторът на example.com иска вместо това blog.example.com сървъра да e ns2.exampleserver.com, той може да настрои това чрез актуализиране на NS записа.
Актуализирането на NS записите може да отнеме няколко часа, докато промените бъдат репликирани в DNS.
SOA запис в DNS зоната
SOA записът съхранява администраторска информация за домейн. DNS записът „start of authority“ (SOA) съхранява важна информация за домейн или зона, като например имейл адреса на администратора, кога последно е актуализиран домейнът и колко време сървърът трябва да изчака между опресняванията.
Всички DNS зони се нуждаят от SOA запис, за да отговарят на стандартите на IETF. SOA записите също са важни за прехвърляне на зони.
Пример за SOA запис:
| name | example.com |
| record type | SOA |
| MNAME | ns.primaryserver.com |
| RNAME | admin.example.com |
| SERIAL | 1111111111 |
| REFRESH | 86400 |
| RETRY | 7200 |
| EXPIRE | 4000000 |
| TTL | 11200 |
Стойността „RNAME“ тук представлява имейл адресът на администратора, което може да бъде объркващо, тъй като липсва знакът „@“, но в SOA запис admin.example.com е еквивалент на admin@example.com.
Какво е сериен номер на зона?
DNS „зоната“ е област на контрол над домейн имена. Една зона може да включва едно име на домейн, един домейн и много поддомейни или много домейн имена. В някои случаи „зона“ по същество е еквивалентна на „домейн“, но това не винаги е вярно.
Серийният номер на зона е номер на версия за SOA записа. В примера по-горе серийният номер е посочен до „SERIAL“. Когато серийният номер се промени във файл на зона, това предупреждава вторичните сървъри на имена, че трябва да актуализират своите копия на файла на зона чрез трансфер на зона.
Какви са другите части на SOA запис?
Нека разгледаме и какви са другите елементи на SOA записа, а именно: MNAME, REFRESH, RETRY и EXPIRE
- MNAME: Това е името на основния сървър за имена за зоната. Вторичните сървъри, които поддържат дубликати на DNS записите на зоната, получават актуализации на зоната от този основен сървър.
- REFRESH: Времето (в секунди), през което вторичните сървъри трябва да изчакат, преди да поискат от първичните сървъри SOA записа, за да видят дали е актуализиран.
- RETRY: Времето, което сървърът трябва да изчака, за да поиска отново актуализация от неотговарящ първичен сървър на имена.
- EXPIRE: Ако вторичен сървър не получи отговор от основния сървър за този период от време, той трябва да спре да отговаря на заявки за зоната.
Какво е зонов трансфер?
Прехвърлянето на DNS зона е процес на изпращане на данни за DNS запис от първичен сървър за имена към вторичен сървър за имена. Първо се прехвърля SOA записът. Серийният номер казва на вторичния сървър дали неговата версия трябва да се актуализира. Прехвърлянето на зони се извършва по TCP протокола .
SRV запис в DNS зоната
SRV записът указва порт за конкретни услуги. Записът на DNS „ услуга“ (SRV) указва хост и порт за конкретни услуги, като глас през IP (VoIP) , незабавни съобщения и т.н. Повечето други DNS записи указват само сървър или IP адрес, но SRV записите включват и порт на този IP адрес. Някои интернет протоколи изискват използването на SRV записи, за да функционират.
Какво съдържа SRV записът?
| service | XMPP |
| protocol | TCP |
| domain name | example.com |
| TTL | 86400 |
| class | IN |
| type | SRV |
| priority | 10 |
| weight | 5 |
| port | 5223 |
| target | server.example.com |
Но SRV записите всъщност са форматирани по следния начин:
_service._proto.name. TTL class type of record priority weight port target.
Така че нашият примерен SRV запис всъщност ще изглежда така:
_xmpp._tcp.example.com. 86400 IN SRV 10 5 5223 server.example.com.
В горния пример "_xmpp" показва типа услуга (протоколът XMPP), а "_tcp" показва транспортния протокол TCP , докато "example.com" е хостът или името на домейна. „Server.example.com“ е целевият сървър и „5223“ показва порта в този сървър.
SRV записите трябва да сочат към A запис (в IPv4) или AAAA запис (в IPv6). Името на сървъра, което изброяват, не може да бъде CNAME . Така че "server.example.com" трябва да води директно до A или AAAA запис под това име.
Каква е разликата между приоритета и тежестта в SRV записите?
SRV записите показват "приоритета" и "тежестта" на различните сървъри, които изброяват. Стойността "приоритет" в SRV запис, позволява на администраторите да приоритизират един сървър, който поддържа дадената услуга, пред друг.
Сървър с по-ниска стойност на приоритет ще получи повече трафик от други сървъри. Стойността на „тежестта“ обаче е подобна: сървър с по-висока тежест ще получи повече трафик от други сървъри със същия приоритет.
Основната разлика между тях е, че първо се гледа приоритетът. Ако има три сървъра, сървър A, сървър B и сървър C и те имат съответни приоритети 10, 20 и 30, тогава тяхната „тежест“ няма значение. Услугата винаги първо ще отправя запитване към сървър A.
Но да предположим, че всички сървъри A, B и C имат приоритет 10 — как услугата ще избира между тях? Това е мястото, където тежестта става фактор: ако сървър A има стойност на "тежест" 5 и сървъри B и C имат стойност на "тежест" 3 и 2, сървър A ще получи най-много трафик, сървър B ще получи втория- най-голям трафик, а сървър C третият по големина.
PTR запис в DNS зоната
PTR записът предоставя име на домейн при обратни търсения (reverse-lookups). Системата за имена на домейни, или DNS , свързва имената на домейни с IP адресите . Запис на DNS указател (накратко PTR) предоставя името на домейна, свързано с IP адрес. DNS PTR записът е точно обратното на записа „A“ , който предоставя IP адреса, свързан с име на домейн.
DNS PTR записите се използват при обратни DNS търсения . Когато потребител се опита да достигне име на домейн в браузъра си, се извършва DNS търсене, което съвпада името на домейна с IP адреса. Обратното DNS търсене е обратното на този процес: това е заявка, която започва с IP адреса и търси името на домейна.
Как се съхраняват DNS PTR записите?
DNS PTR записите в IPv4:
Докато DNS A записите се съхраняват под даденото име на домейн, DNS PTR записите се съхраняват под IP адреса — обърнат и с добавен „.in-addr.arpa“. Например PTR записът за IP адрес 192.0.2.255 ще се съхранява под „255.2.0.192.in-addr.arpa“.
„in-addr.arpa“ трябва да се добави, защото PTR записите се съхраняват в домейна от първо ниво в DNS. “.arpa” е домейн, използван най-вече за управление на мрежова инфраструктура, и това беше първото име на домейн от първо ниво, дефинирано за Интернет.
in-addr.arpa е пространството от имена в .arpa за обратни DNS търсения в IPv4.
DNS PTR записите в IPv6:
IPv6 адресите са конструирани по различен начин от IPv4 адресите и IPv6 PTR записите съществуват в различно пространство от имена в .arpa. IPv6 PTR записите се съхраняват под IPv6 адреса, обърнати и преобразувани в четири-битови секции (за разлика от 8-битовите секции, както в IPv4), плюс ".ip6.arpa".
Какви са някои от основните приложения на PTR записите?
PTR записите се използват при обратни DNS търсения за антиспам цели и регисртиране:
Антиспам приложение на PTR записите
Антиспам: някои имейл филтри против спам използват обратен DNS, за да проверят имената на домейни на имейл адресите и да видят дали има вероятност свързаните IP адреси да се използват от легитимни имейл сървъри.
Отстраняване на проблеми с доставянето на имейл: Тъй като филтрите за защита от нежелана поща извършват тези проверки, проблемите с доставката на имейл могат да възникнат в резултат на неправилно конфигуриран или липсващ PTR запис. Ако даден домейн няма PTR запис или ако PTR записът съдържа грешен домейн, имейл услугите може да блокират всички имейли от този домейн.
Използване на PTR записите за регистриране:
Регистриране: системните логове, обикновено записват само IP адреси; обратното DNS търсене може да преобразува тези IP адреси в домейн имена, и ги запише в логове които са във вариант четими за човека.
Надяваме се нашият пътеводител в DNS зоната да Ви е полезен и да отговаря на основните Ви въпроси!
