DNS протокол
Комуникацията на DNS преминава предимно по UDP протокола. Това гарантира възможно най-малко забавяне на отговорите. Правило е че UDP DNS заявките не трябва да бъдат по-големи от 512 байта, като се има впредвид, че и най-зле конфигурираните рутери ще пропускат UDP пакети с големина 512 байта. Когато отговорът надвиши тази големина, се преминава към TCP - протокола, а това е по-бавният вариант за обмяна на DNS информация.
Връзката между клиент и сървър се осъществява чрез запитване (query) и отговор (answer).
Запитването се състои от "запитване за запис на ресурс" или Resource Record query (или за по-кратко RR query) и съответно - отговор с данните за ресурса, ако е открит, или отрицателен отговор NXDOMAIN (non-existent domain).
пример
# host -v -t ns google.bg ns1.google.com
Trying "google.bg"
Using domain server:
Name: ns1.google.com
Address: 216.239.32.10#53
Aliases:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63087
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4
;; QUESTION SECTION:
;google.bg. IN NS
;; ANSWER SECTION:
google.bg. 345600 IN NS ns1.google.com.
google.bg. 345600 IN NS ns2.google.com.
google.bg. 345600 IN NS ns4.google.com.
google.bg. 345600 IN NS ns3.google.com.
;; ADDITIONAL SECTION:
ns1.google.com. 345600 IN A 216.239.32.10
ns2.google.com. 345600 IN A 216.239.34.10
ns4.google.com. 345600 IN A 216.239.38.10
ns3.google.com. 345600 IN A 216.239.36.10
Received 173 bytes from 216.239.32.10#53 in 48 ms
В случая правим запитване за RR - тип NS, тоест "кои DNS - сървъри обслужват зоната google.bg?". Отговорът както се вижда, са 4 DNS сървъра и техния TTL (time to live, или колко време да се "кешират" записите от DNS cache сървърите). Списъкът на типа запитвания за RR не е малък, но по-голямата част рядко се ползва. Ще изброя най-често използваните RR queries, придружени с кратко описание.
SOA - Start of authority или "достоверен източник", от където със сигурност ще разберем кой "master dns" обслужва дадения домейн.
NS - "кои DNS сървъри обслужват дадения домейн?"
A - най-често се използва за свързване на hostname към IP адрес. A записът www към домейна linux-bg.org отговаря на IP адрес 212.50.10.155 (www.linux-bg.org).
MX - "кои мейл сървъри обслужват пощата за дадения домейн?"
TXT - може да се използва за всичко, ако искате може да си напишете "This is my DNS" и при RR тип TXT ще получите точно това. Принципно се използва за SPF anti-spam записи.
CNAME - това е псевдоним към друг hostname, например www.google.bg е псевдоним (alias) към www.l.google.com.
PTR - "на кой hostname отговаря дадения IP адрес?", или това е обратното на A запис.
AAAA - същото като A запис, но за IPv6 адреси.
ANY - всички записи, касаещи дадения домейн.
Топология на DNS
Структурата на DNS е йерархична, като в основата се намират сървърите от root hints файла. Те обслужват root домейна . (точка), както е видно и от следния пример:
# host -t soa . c.root-servers.netТези dns root сървъри са authoritative само за . домейна. За всички останали, те имат препратки, към които евентуално могат да знаят къде се намира SOA записът на даден домейн.
Using domain server:
Name: c.root-servers.net
Address: 192.33.4.12#53
Aliases:
. has SOA record a.root-servers.net. nstld.verisign-grs.com. 2012091300 1800 900 604800 86400
# dnsq soa .com a.root-servers.net
6 com:
509 bytes, 1+0+13+15 records, response, noerror
query: 6 com
authority: com 172800 NS a.gtld-servers.net
authority: com 172800 NS b.gtld-servers.net
authority: com 172800 NS c.gtld-servers.net
authority: com 172800 NS d.gtld-servers.net
authority: com 172800 NS e.gtld-servers.net
authority: com 172800 NS f.gtld-servers.net
authority: com 172800 NS g.gtld-servers.net
authority: com 172800 NS h.gtld-servers.net
authority: com 172800 NS i.gtld-servers.net
authority: com 172800 NS j.gtld-servers.net
authority: com 172800 NS k.gtld-servers.net
authority: com 172800 NS l.gtld-servers.net
authority: com 172800 NS m.gtld-servers.net
additional: a.gtld-servers.net 172800 A 192.5.6.30
additional: b.gtld-servers.net 172800 A 192.33.14.30
additional: c.gtld-servers.net 172800 A 192.26.92.30
additional: d.gtld-servers.net 172800 A 192.31.80.30
additional: e.gtld-servers.net 172800 A 192.12.94.30
additional: f.gtld-servers.net 172800 A 192.35.51.30
additional: g.gtld-servers.net 172800 A 192.42.93.30
additional: h.gtld-servers.net 172800 A 192.54.112.30
additional: i.gtld-servers.net 172800 A 192.43.172.30
additional: j.gtld-servers.net 172800 A 192.48.79.30
additional: k.gtld-servers.net 172800 A 192.52.178.30
additional: l.gtld-servers.net 172800 A 192.41.162.30
additional: m.gtld-servers.net 172800 A 192.55.83.30
Както е видно, за TLD има 13 сървъра, които са именувани по подобие на root сървърите, а те са [a-m].gtld-servers.net.
Домейните от типа .com, .net, .org се наричат Top-level Domains (TLD), като специфичните домейни на държави като .bg, .de и т.н. се наричат Country Code Top-Level Domains (ccTLD).
GLUE записи
Когато authoritative DNS сървърите на дадена зона (example.com) са в самата зона (ns1.example.com, ns2.example.com,...), се получава проблем с откриването на IP адресите им.
За това е нужно, при регистрацията на домейн, да се зададат така наречените GLUE записи (допълнителен A запис), които са допълнителни записи с IP адресите на authoritative dns сървърите за даденния домейн, по следния начин:
ns1.example.com 123.123.123.1GLUE - записите могат да се диагностицират чрез някои от достъпните по мрежата DNS инструменти като http://www.webdnstools.com/dnstools/domain_check , или чрез програмките dnstrace, dnstracesort от пакета djbdns. Dnstrace започва от root сървърите и следва всички препратки за дадения домейн. Изходът на програмата е доста обемист, за това ще покажем само малка част от него:
ns2.example.com 123.222.123.2
# dnstrace ns google.com b.root-servers.net | dnstracesort > google.com.txt
# ls -la google.com.txt
-rw-r--r-- 1 root wheel 726714 Sep 14 10:54 google.com
забележка: DNS сървърите на google.com са от мрежата 216.239.3хх.ххх за това правя извадка само на тези IP-та от dnstrace.
# cat google.com.txt|grep 216.239.3
- [cut ] -
1 ns1.google.com 216.239.32.10 345600 A 216.239.32.10
1 ns2.google.com 216.239.32.10 345600 A 216.239.34.10
1 ns3.google.com 216.239.32.10 345600 A 216.239.36.10
1 ns4.google.com 216.239.38.10 345600 A 216.239.38.10
...
glue google.com 216.239.32.10 NS ns1.google.com
glue google.com 216.239.32.10 NS ns2.google.com
glue google.com 216.239.32.10 NS ns3.google.com
glue google.com 216.239.32.10 NS ns4.google.com
...
glue ns1.google.com 192.12.94.30 A 216.239.32.10
glue ns1.google.com 192.26.92.30 A 216.239.32.10
glue ns1.google.com 192.31.80.30 A 216.239.32.10
glue ns1.google.com 192.33.14.30 A 216.239.32.10
glue ns1.google.com 192.35.51.30 A 216.239.32.10
glue ns1.google.com 192.41.162.30 A 216.239.32.10
glue ns1.google.com 192.42.93.30 A 216.239.32.10
glue ns1.google.com 192.43.172.30 A 216.239.32.10
glue ns1.google.com 192.48.79.30 A 216.239.32.10
glue ns1.google.com 192.5.6.30 A 216.239.32.10
glue ns1.google.com 192.52.178.30 A 216.239.32.10
glue ns1.google.com 192.54.112.30 A 216.239.32.10
glue ns1.google.com 192.55.83.30 A 216.239.32.10
glue ns1.google.com 216.239.32.10 A 216.239.32.10
glue ns1.google.com 216.239.34.10 A 216.239.32.10
glue ns1.google.com 216.239.36.10 A 216.239.32.10
glue ns1.google.com 216.239.38.10 A 216.239.32.10
...
- [ cut ] -
Както се вижда този ред "glue ns1.google.com 192.12.94.30 A 216.239.32.10" dns сървърът 192.12.94.30 има допълнителен A (glue) запис за ns1.google.com който е 216.239.32.10. IP адреса 192.12.94.30 всъщност е един от global TLD сървърите:
# host 192.12.94.30
30.94.12.192.in-addr.arpa domain name pointer e.gtld-servers.net.
Повече информация за GLUE записите: http://tools.ietf.org/html/draft-koch-dns-glue-clarifications-04
Reverse DNS (PTR записи)
Това е така нареченият "обратен resolving", на кой hostname отговаря даденият IP адрес. Това на практика е един специален домейн, който се нарича in-addr.arpa.
# dnsq soa arpa f.root-servers.net
6 arpa:
508 bytes, 1+1+12+13 records, response, authoritative, noerror
query: 6 arpa
answer: arpa 86400 SOA a.root-servers.net nstld.verisign-grs.com 2012091400 1800 900 604800 86400
authority: arpa 518400 NS c.root-servers.net
authority: arpa 518400 NS d.root-servers.net
authority: arpa 518400 NS m.root-servers.net
authority: arpa 518400 NS i.root-servers.net
authority: arpa 518400 NS f.root-servers.net
authority: arpa 518400 NS l.root-servers.net
authority: arpa 518400 NS h.root-servers.net
authority: arpa 518400 NS k.root-servers.net
authority: arpa 518400 NS g.root-servers.net
authority: arpa 518400 NS b.root-servers.net
authority: arpa 518400 NS e.root-servers.net
authority: arpa 518400 NS a.root-servers.net
- [ cut ] -
За Top-Level домейна ARPA authritative dns сървъри са root dns сървърите
# dnsq soa in-addr.arpa f.root-servers.net
6 in-addr.arpa:
406 bytes, 1+0+6+12 records, response, noerror
query: 6 in-addr.arpa
authority: in-addr.arpa 172800 NS e.in-addr-servers.arpa
authority: in-addr.arpa 172800 NS c.in-addr-servers.arpa
authority: in-addr.arpa 172800 NS f.in-addr-servers.arpa
authority: in-addr.arpa 172800 NS b.in-addr-servers.arpa
authority: in-addr.arpa 172800 NS a.in-addr-servers.arpa
authority: in-addr.arpa 172800 NS d.in-addr-servers.arpa
additional: a.in-addr-servers.arpa 172800 A 199.212.0.73
additional: b.in-addr-servers.arpa 172800 A 199.253.183.183
additional: c.in-addr-servers.arpa 172800 A 196.216.169.10
additional: d.in-addr-servers.arpa 172800 A 200.10.60.53
additional: e.in-addr-servers.arpa 172800 A 203.119.86.101
additional: f.in-addr-servers.arpa 172800 A 193.0.9.1
За домейна in-addr.arpa dns сървърите са [a-f].in-addr.servers.arpa както и glue записите към тях.
# dnsq ns in-addr.arpa e.in-addr-servers.arpa
2 in-addr.arpa:
142 bytes, 1+6+0+0 records, response, authoritative, noerror
query: 2 in-addr.arpa
answer: in-addr.arpa 86400 NS d.in-addr-servers.arpa
answer: in-addr.arpa 86400 NS f.in-addr-servers.arpa
answer: in-addr.arpa 86400 NS a.in-addr-servers.arpa
answer: in-addr.arpa 86400 NS b.in-addr-servers.arpa
answer: in-addr.arpa 86400 NS e.in-addr-servers.arpa
answer: in-addr.arpa 86400 NS c.in-addr-servers.arpa
Тук вече получихме достоверна информация за in-addr.arpa dns сървърите.
Зоните в домейна in-addr.arpa се състоят от IP адресите на мрежите на които ще се правят PTR записи. Разликата е че мрежите се пишат в обратен ред. Пример за мрежата 216.239.32.0/24:
# dnsq soa 32.239.216.in-addr.arpa a.in-addr-servers.arpaКакто се вижда по-горе, зоната за мрежата 216.239.32.х (32.239.216.in-addr.arpa) е делегирана към ns1.google.com.
6 32.239.216.in-addr.arpa:
177 bytes, 1+0+8+0 records, response, noerror
query: 6 32.239.216.in-addr.arpa
authority: 216.in-addr.arpa 86400 NS u.arin.net
authority: 216.in-addr.arpa 86400 NS w.arin.net
authority: 216.in-addr.arpa 86400 NS t.arin.net
authority: 216.in-addr.arpa 86400 NS v.arin.net
authority: 216.in-addr.arpa 86400 NS z.arin.net
authority: 216.in-addr.arpa 86400 NS y.arin.net
authority: 216.in-addr.arpa 86400 NS r.arin.net
authority: 216.in-addr.arpa 86400 NS x.arin.net
# dnsq soa 32.239.216.in-addr.arpa u.arin.net
6 32.239.216.in-addr.arpa:
123 bytes, 1+0+4+0 records, response, noerror
query: 6 32.239.216.in-addr.arpa
authority: 32.239.216.in-addr.arpa 86400 NS ns4.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns2.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns3.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns1.google.com
# dnsq soa 32.239.216.in-addr.arpa ns1.google.com
6 32.239.216.in-addr.arpa:
233 bytes, 1+1+4+4 records, response, authoritative, weird rd, noerror
query: 6 32.239.216.in-addr.arpa
answer: 32.239.216.in-addr.arpa 86400 SOA ns1.google.com dns-admin.google.com 2012082800 21600 3600 1209600 10800
authority: 32.239.216.in-addr.arpa 86400 NS ns1.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns2.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns4.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns3.google.com
additional: ns1.google.com 345600 A 216.239.32.10
additional: ns2.google.com 345600 A 216.239.34.10
additional: ns4.google.com 345600 A 216.239.38.10
additional: ns3.google.com 345600 A 216.239.36.10
За повече информация можете да прочетете RFC2317 - Classless in-addr.arpa delegaion.
Authoritative DNS сървър
Authoritative DNS сървър е сървър, който е конфигуриран да отговаря на запитвания за дадени домейни. Той не изпълнява recursive dns запитвания, и е строго ограничен само до отговори за предварително конфигурираните домейни.
Тук трябва да се отбележи объркването и смесването на понятията "dns cache" и "authoritative dns сървър", дължащо се на най-разпространата имплементация на dns сървър - BIND.
Добрите практики за сигурност показват, че authoritative dns и dns cache сървърите трябва да са отделни програми, стартирани като отделни процеси, слушащи на отделни IP адреси. При BIND, двата сървъра са в един процес. Чак от BIND 10 тези сървъри ще бъдат отделни процеси.
Ето пример за отговори:
питаме dns cache сървър (10.1.42.1) за два dns записа - www.google.com и www.linux-bg.org
# host www.google.com 10.1.42.1питаме authoritative dns сървър (в случая ns1.google.com за зоната google.com) за www.google.com и www.linux-bg.org.
Using domain server:
Name: 10.1.42.1
Address: 10.1.42.1#53
Aliases:
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 173.194.35.144
www.l.google.com has address 173.194.35.148
www.l.google.com has address 173.194.35.147
www.l.google.com has address 173.194.35.145
www.l.google.com has address 173.194.35.146
# host www.linux-bg.org 10.1.42.1
Using domain server:
Name: 10.1.42.1
Address: 10.1.42.1#53
Aliases:
www.linux-bg.org has address 212.50.10.155
# host www.google.com ns1.google.com
Using domain server:
Name: ns1.google.com
Address: 216.239.32.10#53
Aliases:
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 173.194.35.148
www.l.google.com has address 173.194.35.147
www.l.google.com has address 173.194.35.145
www.l.google.com has address 173.194.35.144
www.l.google.com has address 173.194.35.146
# host www.linux-bg.org ns1.google.com
Using domain server:
Name: ns1.google.com
Address: 216.239.32.10#53
Aliases:
Host www.linux-bg.org not found: 5(REFUSED)
Видно е, че при второто запитване отговорът е REFUSED. Това показва, че ns1.google.com не изпълнява recursive запитвания и отговаря само за google.com зоната (както и за други зони за които е конфигуриран да е authoritative).
Препоръки за authoritative dns
Тъй като dns е много чувствителен от към бързината на достъп, има няколко изисквания, преди да си инсталираме authoritative dns сървър за обслужване на личен домейн.
* препоръчително е да имате 2 IP адреса от различни мрежи, свързани с различни доставчици;
* скоростта трябва да е гарантирана до известна степен в двете посоки;
* прекъсванията на интернета да бъдат възможно най-малки.
Ако не можете да осигурите тези изисквания, Ви препоръчвам да използвате за dns hosting сървърите на фирмата, от която сте закупили дадения домейн, освен ако не сте ентусиаст и искате да се научите.
Конфигурационният файл на един authoritative dns сървър се състои от отделни "зони", които на практика представляват списък с Resource Records за даден домейн. Всяка зона трябва да съдържа:
* SOA - запис - master.dns.domain.com, email.za.kontakti.domain.com, сериен номер, refresh, retry, expire, min TTL.
master dns - основен dns сървър.
email - емейл за контакти при проблеми с този домейн.
serial - сериен номер чрез който се разбира по данните на домейна има промени. Препоръчително да текущата дата на промените във формат: DDMMYYYYX, където X e брой промени за деня.
refresh - след колко секунди slave dns сървъра ще се опита да обнови данните си от master dns.
retry - при проблем, след колко секунди slave dns сървъра ще се опита отново да опресни данните от master dns.
expire - при проблем с обновлението, след колко секунди slave dns сървъра ще спре да отговаря на запитвания за дадения домейн, тъй като данните ще бъдат смятани за остарели.
* NS - запис - минимун един, от типа ns1.domain.com
* A - запис - A запис за ns1 към domain.com
ако домейна ще получава поща, е нужен и поне един:
* MX - запис - hostname, където ще се намира мейл сървърите обслужващи domain.com, например mail.domain.com. Може да имате повече от един mx запис, като приоритета им се указва чрез число, при което колкото е по-ниска стойността, е с по-голям приоритет. Пример:
# dnsq mx google.com ns1.google.com
15 google.com:
216 bytes, 1+5+0+5 records, response, authoritative, weird rd, noerror
query: 15 google.com
answer: google.com 600 MX 20 alt1.aspmx.l.google.com
answer: google.com 600 MX 10 aspmx.l.google.com
answer: google.com 600 MX 50 alt4.aspmx.l.google.com
answer: google.com 600 MX 30 alt2.aspmx.l.google.com
answer: google.com 600 MX 40 alt3.aspmx.l.google.com
Както се вижда от примера по-горе, с най-голям приоритет от тези мейл сървъри е aspmx.l.google.com, който е с най-ниска стойност (10), а с най-нисък приоритет е alt4.aspmx.l.google.com (50).
* A - запис - за mail.domain.com към кое IP сочи
ако домейна ще бъде достъпен през web сървър е нужен запис:
* A - запис - А запис за www към домейна domain.com, тоест на кое IP отговаря www.domain.com.
* TXT - препоръчително е да се използва за SPF запис, когато има конфигурирани MX записи (www.openspf.org).
* Празен A - запис - това не нужно, за да работи web сървъра (примерно www.domain.com), когато потребителите не пишат www.domain.com, а само domain.com
Пример за това как изглежда една стандартно конфигурирана зона:
Зона example.com ns1.example.com. hostmaster.example.com. 2012010601 3600 600 120960 3600 3600
NS запис ns1.example.com 3600
NS запис ns2.example.com 3600
MX запис mail1.example.com 10 86400
MX запис mail2.example.com 100 86400
А запис ns1.example.com 193.22.103.226 3600
А запис ns2.example.com 193.22.103.2 3600
А запис example.com 195.177.249.170 3600
А запис mail1.example.com 195.177.249.170 3600
А запис mail2.example.com 195.177.249.170 3600
А запис archive.example.com 195.177.249.170 3600
А запис blog.example.com 195.177.249.170 3600
А запис www.example.com 195.177.249.170 86400
TXT запис за SPF "v=spf1 mx a:mail1.example.com a:mail2.example.com -all"
За да имаме собствени DNS сървъри като за начало е нужно да си закупим домейн. Това става от съответната фирма, предлагаща тази услга. Това което трябва да направите при регистрацията, е да добавите 2 DNS сървъра, както и GLUE записите към тях.
Ако сме закупили домейна example.com, трябва да въведем и DNS сървърите, които ще обслужват този домейн заедно с техните IP адреси в административния панел за DNS на сайта, от който сме купили домейна. Например:
ns1.example.com 193.32.12.1От тук нататък трябва да имаме инсталирани DNS сървъри на тези IP адреси като те трябва да бъдат конфигурирани да обслужват домейна example.com (да са authoritative за example.com).
ns2.example.com 193.52.50.1
Примерни инсталация и конфигурация на тези сървъри ще бъде разгледано в третата част на тази поредица от статии за DNS.
Lame nameservers
Това са DNS сървъри, които са посочени за authoritative dns за даден домейн, но не са конфигурирани да отговарят на запитвания за този домейн. С други думи, те връщат отговор от типа - refused. Ето пример за lame nameserver:
Кои са dns сървърите, обслужващи зоната cnsys.bg?
# host -t ns cnsys.bg
cnsys.bg name server ns.btc-net.bg.
cnsys.bg name server ns2.atlantis.bg.
cnsys.bg name server clio.cnsys.bg.
Нека попитаме за mx - запис към домейна cnsys.bg. Първо питаме ns.btc-net.bg.
# host -t mx cnsys.bg ns.btc-net.bg.
Using domain server:
Name: ns.btc-net.bg.
Address: 212.39.90.73#53
Aliases:
cnsys.bg mail is handled by 10 clio.cnsys.bg.
Да попитаме вторият DNS сървър (ns2.atlantis.bg) за същото:
# host -t mx cnsys.bg ns2.atlantis.bg.Както се вижда, въпреки, че ns2.atlantis.bg е в списъка с dns сървъри обслужващи cnsys.bg, при запитване към него за mx запис отговорът е REFUSED, тоест конфигурацията е неправилна, и ns2.atlantis.bg не отговаря на запитвания за зоната cnsys.bg, въреки, че фирурира в списъка като authoritative. В този случай този dns сървър се води lame за зоната cnsys.bg.
Using domain server:
Name: ns2.atlantis.bg.
Address: 193.108.24.4#53
Aliases:
Host cnsys.bg not found: 5(REFUSED)
Как да инсталираме и конфигурираме authoritative dns сървър ще разгледаме в следващата част на тази поредица статии.
Статията е публикувана в http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=450185369
