Pages

Thursday, October 18, 2012

Как работи DNS, част 2 - Топология, Authoritative servers

Преди да започнете да четете статията е добре да се запознаете с първата част Как работи DNS, част 1 - Resolvers и Cache сървъри.


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
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
Тези dns root сървъри са authoritative само за . домейна. За всички останали, те имат препратки, към които евентуално могат да знаят къде се намира SOA записът на даден домейн.

# 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.1
ns2.example.com 123.222.123.2
GLUE - записите могат да се диагностицират чрез някои от достъпните по мрежата DNS  инструменти като http://www.webdnstools.com/dnstools/domain_check , или чрез програмките dnstrace, dnstracesort от пакета djbdns. Dnstrace започва от root сървърите и следва всички препратки за дадения домейн. Изходът на програмата е доста обемист, за това ще покажем само малка част от него:
# 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
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
Както се вижда по-горе, зоната за мрежата 216.239.32.х (32.239.216.in-addr.arpa) е делегирана към ns1.google.com.

За повече информация можете да прочетете 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
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
питаме authoritative dns сървър (в случая ns1.google.com за зоната google.com) за www.google.com и www.linux-bg.org.

# 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
ns2.example.com 193.52.50.1
От тук нататък трябва да имаме инсталирани DNS сървъри на тези IP адреси като те трябва да бъдат конфигурирани да обслужват домейна example.com (да са authoritative за example.com).
Примерни инсталация и конфигурация на тези сървъри ще бъде разгледано в третата част на тази поредица от статии за 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.
Using domain server:
Name: ns2.atlantis.bg.
Address: 193.108.24.4#53
Aliases:

Host cnsys.bg not found: 5(REFUSED)
Както се вижда, въпреки, че ns2.atlantis.bg е в списъка с dns сървъри обслужващи cnsys.bg, при запитване към него за mx запис отговорът е REFUSED, тоест конфигурацията е неправилна, и ns2.atlantis.bg не отговаря на запитвания за зоната cnsys.bg, въреки, че фирурира в списъка като authoritative. В този случай този dns сървър се води lame за зоната cnsys.bg.

Как да инсталираме и конфигурираме authoritative dns сървър ще разгледаме в следващата част на тази поредица статии.

Статията е публикувана в http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=450185369

Monday, October 8, 2012

DNS софтуер изследване за България

Просто от скука реших да направя едно проучване за това какъв DNS софтуер се използва в Бълария.

Оказа се малко трудно да се намерят в момента всичките български IP мрежи тъй като така нареченият bg peering вече се е превърнал в нещо като eu peering. Данните за това изследване са базирани на мрежите извадени от този сайт: http://bgp.he.net/country/BG. Използвани помощни програмки - curl и shell script. Ето ги и самите мрежи: http://debian.gabrovo.com/all-bg-networks-october-2012.txt. Не претендирам, че данните са 100% верни особенно дали това наистина са абсолютно всички български мрежи.

Всички тези мрежи бяха сканирани за отворен порт 53/tcp просто защото udp сканирането не би ни свършило работа. Както следва:

#!/bin/bash
for a in `cat all-bg-neтworks-october-2012.txt`;
do
echo -n "scanning $a network ..."
b=`echo $a|cut -d/ -f 1`
nmap --host-timeout 2s -n -p 53 $a -oG $b.log > /dev/null 2>&1
echo "done"
done

Сканирането отне около един ден. Резултатът беше 24911 IP адреса на които има отворен 53ти порт. Трябва да се отбележи, че не всички от тези IP адреси имат инсталиран DNS софтуер. За това следващата стъпка е да сканираме за версията на DNS софтуера. Програмката която ползвам се казва fpdns (fingerprint dns) и я има на пакет в Debian Squeeze (apt-get install fpdns).

#!/bin/bash
for a in `cat ip-dns-port-53.txt`;
do
fpdns -t 1 -f $a|tee -a dns-scan-oct-2012.txt
done
Бележка: tee програмката записва във файл и едновременно с това показва какво е записано и на stdout.

Fingerprint сканирането отне един weekend. Резултатите са както следва:

ISC BIND 9.2.3rc1 -- 9.6.1-P1 9978
ISC BIND 9.2.3rc1 -- 9.6.1-P1 [recursion enabled] 2705
Mikrotik dsl/cable 2529
No match found 782
vermicelli totd 291
ISC BIND 8.3.0-RC1 -- 8.4.4 [recursion enabled] 41
DJ Bernstein TinyDNS 1.05 40
ISC BIND 9.2.0rc7 -- 9.2.2-P3 [recursion enabled] 40
Raiden DNSD 20
bboy MyDNS 19
Max Feoktistov small HTTP server [recursion enabled] 12
ISC BIND 9.2.0rc7 -- 9.2.2-P3 9
Microsoft Windows DNS 2000 9
ISC BIND 9.1.0 -- 9.1.3 [recursion enabled] 8
ISC BIND 8.1-REL -- 8.2.1-T4B [recursion enabled] 8
PowerDNS PowerDNS 2.9.4 -- 2.9.11 7
ISC BIND 9.2.0a1 -- 9.2.2-P3 [recursion enabled] 7
ISC BIND 8.3.0-RC1 -- 8.4.4 [recursion local] 6
NLnetLabs NSD 1.0 alpha (uncertain) 5
JHSOFT simple DNS plus [recursion enabled] 4
Microsoft Windows DNS NT4 2
ISC BIND 9.2.0rc4 -- 9.2.2-P3 2
ISC BIND 9.2.0rc7 -- 9.2.2-P3 [recursion local] 2
Microsoft ? 1
ISC BIND 9.0.0b5 -- 9.0.1 [recursion enabled] 1
robtex Viking DNS module 1
VeriSign ATLAS 1
ISC BIND 8.4.1-p1 1
Total Result 16531

Както се вижда най-използваният DNS софтуер е ISC BIND. Другото което прави впечатление е големият брой DNS сървъри които изпълняват рекурсивни заявки (тоест можете да си ги сложите в настройките за DNS и да ги ползвате без проблем или с други думи казано - в повечето случаи default install).

Ето и какви са версиите на DNS софтуера при запитване за версия:

ID което се връща при заявка за версия брой
id: unavailable (NOTIMP) 2546
id: "9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.... 1498
id: unavailable (REFUSED) 989
id: "dnsmasq-2.40" 941
id: "INVALID QUERY" 834
id: "9.7.2-P2" 760
id: "9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6... 758
id: "9.6.-ESV-R7-P1" 641
id: "9.7.3" 604
id: "9.9.1-P3" 417
id: "none" 401
id: "9.9.1-P1" 274
id: "9.8.1-P1" 268
id: "9.3.6-P1-RedHat-9.3.6-20.P1.el5" 207
id: "9.4.2" 207
id: "9.6-ESV-R1" 180
id: "9.4.3-P3" 177
id: "9.7.3-P3-RedHat-9.7.3-8.P3.el6_2.2... 165
id: "9.9.0" 158
id: "9.2.4" 118
id: "9.3.6-P1-RedHat-9.3.6-16.P1.el5_7.... 115
id: "9.4.3-P4" 105
id: "9.5.1-P3" 104
id: "9.3.6-P1-RedHat-9.3.6-16.P1.el5" 103
id: "9.8.0-P2" 98
id: "9.6-ESV-R4" 98
id: "Yes hack me" 92
id: "9.7.0-P1" 85
id unavailable (NOERROR) 83
id: "9.4.1" 81
id: "9.7.2-P3" 79
id: " " 76
id: "9.4.1-P1" 75
id: "9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2... 71
id: "Go away!" 69
id: "9.4.2-P2" 68
id: "9.3.4-P1" 67
id: "9.3.2-P1" 63
id: "9.3.4" 60
id: "9.7.1-P2" 58
id: "9.3.1" 51
id: "9.6.1-P2" 48
id: "9.4.2-P1" 45
id: "9.3.4-P1.1" 45
id: "9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3... 43
id unavailable (FORMERR) 40
id: "9.3.6-P1" 38
id: "9.5.0-P2" 37
id: "dnsmasq-2.55" 34
id: "9.6.1-P1" 33
id: "9.8.0-P4" 32
id: "dnsmasq-2.47" 32
id: "9.9.1-P2" 30
id: "dnsmasq-2.45" 30
id: "ZOMG EPIX!" 29
id: "9.6-ESV-R3" 28
id: "9.3.3" 26
id: "dnsmasq-2.59" 26
id: "9.6.-ESV-R3" 25
id: "9.4.3-P5" 25
id: "9.6.2-P2" 23
id: "9.5.1-P2" 23
id: "9.3.4-P1.2" 23
id: "9.4.2-P2.1" 23
id: "9.4.3-P2" 22
id: "not available" 22
id: "9.6.-ESV-R5-P1" 21
id: "9.3.2" 21
... кръц ... (стана много дълго...) n/a

Върнатият отговор при запитване за версия не е гаранция за това дали софтуера е със сигурност този, тъй като тази стойност може да се променя от администратора (както се забелязва - ZOMG EPIX!).

No match found - предполага се, че това са Windows DNS сървъри. Направих проба с фирмения DNS сървър който е на Windows 2003 сървър и даде точно това - No match found.

Тъй като DNS по дизайн е публична информация ето списък с всички отворени за цял свят рекурсивни DNS cache сървъри в България (2825 броя): http://debian.gabrovo.com/bg-dns-open-recursive.txt.

Ако някои иска да погледне данните в неформатиран (и пълен) вид от това изследване нека ми пише коментар.