Как работи DNS, част 3 - инсталация на DNS cache сървър.

Преди да прочетете тази статия, би било добре първо да се запознаете със статията: "Как работи DNS, част 1 - Resolvers и Cache сървъри" - линк към блога ми или линк към linux-bg.org.

Преди инсталацията, трябва да решим кой dns сървър да инсталираме. Ето кратък списък с най-разпространените dns сървъри: BIND, djbdns, PowerDNS, MaraDNS, Windows DNS  (Изследване за DNS софтуера ползван в България).

В примерите ще използвам паралелно инсталация и конфигурация на  най-разпространеният dns сървър - BIND, както и този, който използвам и препоръчвам аз - djbdns под Debian.

Инсталация на BIND като cache сървър

В Debian stable (6.x, squeeze в момента) BIND го има на пакет. Инсталираме го:

# apt-get install bind9

Конфигурацията на bind се намира в /etc/bind/ - директорията, като файла се казва named.conf. В Debian този файл е разделен на няколко файла, като във всеки от тях се конфигурират отделни неща. Ето:

# cat named.conf
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

Както се вижда, настройките се правят в няколко отделни файла. Тъй като ние искаме да конфигурираме само cache сървър, файлът който ни интересува е named.conf.options.

# cat /etc/bind/named.conf.options
options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        // forwarders {
        //      0.0.0.0;
        // };

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };

    allow-recursion { 172.20.20.0/24; 172.20.30.3; };

};

С този ред разрешяваме recursive запитвания към dns cache сървъра от мрежата 172.20.20.0/255.255.255.0 както и от IP адреса 172.20.30.3. Съответно - променяте ги на ip/мрежите които ще го ползват като dns cache сървър.

# /etc/init.d/bind9 restart

Вече имате работещ BIND dns cache сървър.

Инсталация на djbdns cache сървър

В Debian stable (6.x, squeeze в момента) djbdns не е включен, но го има в testing/unstable. Ако искате, можете да си направите пакет (http://geroyblog.blogspot.com/2012/09/how-to-install-djbdns-in-debian-squeeze.html), или да го инсталирате от http://cr.yp.to/djbdns.html. Ще разгледаме втория вариант. За целта е нужно да имате следните пакети инсталирани - daemontools (как се инсталира), ucspi-tcp. Следваме инструкциите за инсталация на djb:

# wget http://cr.yp.to/djbdns/djbdns-1.05.tar.gz
# zcat djbdns-1.05.tar.gz|tar xvf -
# cd djbdns-1.05
# echo gcc -O2 -include /usr/include/errno.h > conf-cc
# make
# make setup check

Djbdns пакета съдържа няколко програми, като всяка от която върши определена работа:

tinydns - authoritative dns сървър - udp
axfrdns - authoritative dns сървър - tcp
dnscache - dns cache сървър
както и няколко други които в случая няма да бъдат разяснявани.

Тъй като ще инсталираме dns cache сървър, ще разгледаме dnscache и програмата за конфигуриране, която върви към него - dnscache-conf. Синтаксиса на програмата е следния:

dnscache-conf: usage: dnscache-conf acct logacct /dnscache [ myip ]

където:
acct - нужен е да се създаде потребителски акаунт, с който ще се стартира dnscache;
logacct - нужен е да се създаде потребителски акаунт, с който ще се стартира multilog, който ще записва log - файловете на dnscache;
/directory - в коя директория да бъдат създадени стартиращите/log - файлове на dnscache
myip - на кое IP ще "слуша" dnscache.

# useradd dnscache
# useradd dnslog
# dnscache-conf dnscache dnslog /etc/dnscache 172.20.20.1

Остава да укажем от кои ip/мрежи е разрешен да се ползва dns cache сървърът. Това се прави в директорията /etc/dnscache/root/ip/, като в нея се създават празни файлове с имената на мрежи/ip адреси от които може да се ползва сървъра.

# touch /etc/dnscache/root/ip/127.0.0.1
# touch /etc/dnscache/root/ip/172.20.20

Както следва, dnscache може да се използва от 127.0.0.1 ip адреса и от мрежата 172.20.20.0/24
Остава само да стартираме dnscache. Това става, като направим symbolic link към /etc/services директорията:

# ln -s /etc/dnscache /etc/service/dnscache

# svstat /etc/service/dnscache /etc/service/dnscache/log
/etc/service/dnscache: up (pid 1273) 3 seconds
/etc/service/dnscache/log: up (pid 1277) 3 seconds

Конфигурационната директория на djbdns се намира в /etc/dnscache/env, като всички променливи са в отделни файлове.

# ls -l /etc/dnscache/env/
-rw-r--r-- 1 root root    8 Sep  9  2008 CACHESIZE
-rw-r--r-- 1 root root    8 Sep  9  2008 DATALIMIT
-rw-r--r-- 1 root root   15 Sep  9  2008 IP
-rw-r--r-- 1 root root    8 Sep  9  2008 IPSEND
-rw-r--r-- 1 root root   23 Sep  9  2008 ROOT

По подразбиране CACHESIZE е 1000000 байта, което е твърде малко и трябва да бъде променено на по-голяма стойност в зависимост от свободната памет с която разполагате.
DATALIMIT се използва от програмата softlimit, която ограничава dnscache да използва определен ресурс памет. DATASIZE трябва да е по-голям от CACHESIZE.
ROOT указва в коя директория се намират dns root hints.
IP указва на кой IP адрес ще отговаря dnscache при запитвания.
IPSEND указва от кой адрес да се изпращат рекурсивните заявки.

# echo 134217728 > /etc/dnscache/env/CACHESIZE
# echo 154000000 > /etc/dnscache/env/DATALIMIT

Тези стойности указват 128mb за cache на dns запитванията и 154mb като цяло заделена памет за програмата dnscache. Ако по някакви причини самата програма се опита да заеме повече от тази памет, програмата softlimit ще върне грешка "out of memory".

Остава да конфигурирате PC-то си да използва този DNS, и това е всичко. Вече имаме работещ dns cache сървър.

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

Ако искате dnscache сървъра ви да поддържа DNSCurve протокола (предложен от Dan Bernstein), използвайте ето този patch и инструкциите към него: http://shinobi.dempsky.org/~matthew/patches/djbdns-dnscurve-20090602.patch

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.

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

How to install djbdns in Debian Squeeze as deb package

Djbdns deb package is missing from latest Debian release (squeeze). There is a discussion regarding rapid dns cache poisoning attack which prevented djbdns package to be included in Debian squeeze release. There are two packages for djbdns in debian - djbdns which is original package of djbdns + 3 minor patches fixing some problems and dbndns which is debian fork of djbdns + ipv6 support patch. If you need ipv6 support in your dns install dbndns, if you don't need it i suggest you to install djbdns package.

Here is how can you install it on Debian squeeze as a deb package.

Add this line to /etc/apt/sources.list

deb-src http://ftp.bg.debian.org/debian/ sid main non-free contrib

You can choose another debian mirror if you like.

# apt-get update
# apt-get source djbdns

This will download source of the package and unpack it in your current directory. We need build-essential meta package installed so we can build some custom packages.

# apt-get install build-essential

Now all we need is to enter the directory of the unpacked djbdns package and run:

# dpkg-buildpackage -uc -rfakeroot

If there is no error the result of the above command will produce djbdns_1.05-8_i386.deb package which contains tinydns, dnscache, axfrdns ... etc. and dnscache-run_1.05-8_all.deb which contains run scripts for daemontools. All you need is to install them as follow:

# dpkg -i djbdns_1.05-8_i386.deb dnscache-run_1.05-8_all.deb 

Just to be sure that nothing goes wrong after upgrade we need to 'hold' these packages

# echo djbdns hold | dpkg --set-selections
# echo dnscache-run hold | dpkg --set-selections

Make sure to check this readme  /usr/share/doc/djbdns/README.Debian

Note: /service directory is moved under /etc/service to match debian configuration standarts.

That is all, now you have working djbdns (or dbndns) as a Debian package in squeeze

Как работи DNS, част 1 - Resolvers и Cache сървъри.

DNS е видимата за потребителя "основа" на Интернет. Компютрите си комуникират чрез IP адреси, но всички комуникации между потребителите в Интернет започват с DNS - заявка. За да си провери пощата в gmail.com (примерно), потребителят изписва в полето на браузъра "www.gmail.com". Тъй като компютрите работят с IP - адреси, операционната система се обръща към конфигурирания предварително DNS - сървър, за да разбере на кой IP - адрес отговаря "www.gmail.com", и в последвствие да установи връзка и достави на потребителя началната страница на www.gmail.com.

DNS - сървърите са два вида. Authoritative - сървъри, който отговарят на заявки за дадена зона и Cache -  сървъри, които отговарят на всички потребителски заявки, извършвайки транслацията от име на домейн към IP адрес.

Resolvers - клиентската част, която отговаря за първоначалните dns запитвания. Те биват два вида:

stub resolver - клиентска част, която сама по себе си не може да изпълни всичките заявки до намирането на желаната информация. Те зависят от recursive dns cache resolvers. Те не могат да изпълняват recursive dns- запитвания. Заявката е от типа - на кое IP отговаря "www.gmail.com", като очаква конфигурирания dns cache - сървър да извърши всичко необходимо до намирането на IP адреса.

recursive dns cache resolver - наричани за по-кратко dns cache - сървъри. Те изпълняват recursive - запитвания като се грижат да изпълнят допълнителните запитвания до достигане на желания резултат. Пример:

web browser -> www.gmail.com
stub resolver -> кое е ip-то на www.gmail.com -> dns cache server (конфигурирания dns сървър)
dns cache сървър -> recursive заявка
dns cache сървър -> кой са authoritative dns сървърите отговарящи за gmail.com
(същото като)

# host -t ns gmail.com
gmail.com name server ns2.google.com.
gmail.com name server ns1.google.com.
gmail.com name server ns3.google.com.
gmail.com name server ns4.google.com.

dns cache сървър -> ок, кое е IP-то на един от тези сървъри, за да мога да го питам за www.gmail.com

(същото като)

# host ns3.google.com.
ns3.google.com has address 216.239.36.10

dns cache сървър -> питам 216.239.36.10 на кое IP отговаря www.gmail.com

(същото като)
# host www.gmail.com 216.239.36.10
Using domain server:
Name: 216.239.36.10
Address: 216.239.36.10#53
Aliases:

www.gmail.com is an alias for mail.google.com.
mail.google.com is an alias for googlemail.l.google.com.
googlemail.l.google.com has address 209.85.148.17
googlemail.l.google.com has address 209.85.148.19
googlemail.l.google.com has address 209.85.148.18
googlemail.l.google.com has address 209.85.148.83
googlemail.l.google.com has IPv6 address 2a00:1450:4001:c01::11

dns cache сървър -> www.gmail.com е псевдоним към googlemail.l.google.com, който има няколко IP адреса.

dns cache сървър -> отговор към stub resolver-a www.gmail.com -> 209.85.148.17, 209.85.148.18, 209.85.148.19, 209.85.148.83
dns cache сървър -> отговорът се "кешира".

Клиентска конфигурация на DNS.

Типичната конфигурация на едно потребителско PC с операционна система, който е конфигуриран да има достъп до интернет, включва настройка за DNS - сървър.
На UNIX - подобните операционни системи тази конфигурация се прави във файла /etc/resolv.conf (пример от NetBSD):

# cat /etc/resolv.conf
# Created by dhclient from vr0
nameserver 10.1.42.1

При Windows това се намира в Control Panel -> Network -> Local Area Connection -> Properties -> TCP/IP Settings. Можем да видим текущите DNS настройки и с командата: ipconfig /all

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : horizon9.org
   Description . . . . . . . . . . . : Marvell Yukon 88E8056 PCI-E Gigabit Ethernet Controller
   Physical Address. . . . . . . . . : 00-1A-4D-9A-BF-00
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.1.42.137(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 22 юли 2012 г. 08:43:33 ч.
   Lease Expires . . . . . . . . . . : 24 юли 2012 г. 08:43:37 ч.
   Default Gateway . . . . . . . . . : 10.1.42.1
   DHCP Server . . . . . . . . . . . : 10.1.42.1
   DNS Servers . . . . . . . . . . . : 10.1.42.1
   Primary WINS Server . . . . . . . : 10.1.42.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

В горепосочения пример конфигурирания DNS cache - сървър е 10.1.42.1.
Операционните системи имат и локален файл, в който може статично да се описват dns - адреси да отговарят на дадени IP - адреси. Файлът се нарича "hosts" и се намира, както следва:

При UNIX - подобните операционни системи това е:

# cat /etc/hosts
#   $NetBSD: hosts,v 1.7 2004/08/29 13:26:17 chs Exp $
#
# Host Database
# This file should contain the addresses and aliases
# for local hosts that share this file.
# It is used only for "ifconfig" and other operations
# before the nameserver is started.
#
#
::1                     localhost localhost.
127.0.0.1               localhost localhost.
10.1.42.1       sativa-amd64 www.horizon9.org
#
# RFC 1918 specifies that these networks are "internal".
# 10.0.0.0      10.255.255.255
# 172.16.0.0    172.31.255.255
# 192.168.0.0   192.168.255.255

Също така, UNIX има механизъм, по който да се указва реда на DNS - запитванията. Това се прави от файла /etc/nsswitch.conf

# cat /etc/nsswitch.conf
#   $NetBSD: nsswitch.conf,v 1.5 1999/10/24 12:36:52 lukem Exp $
#
# nsswitch.conf(5) -
#       name service switch configuration file
#
# These are the defaults in libc
#
group:          compat
group_compat:   nis
hosts:          files dns
netgroup:       files [notfound=return] nis
networks:       files
passwd:         compat
passwd_compat:  nis
shells:         files

# List of supported sources for each database
#
# group:                compat, dns, files, nis
# group_compat:         dns, nis
# hosts:                dns, files, nis
# netgroup:             files, nis
# networks:             dns, files, nis
# passwd:               compat, dns, files, nis
# passwd_compat:        dns, nis
# shells:               dns, files, nis

Както се вижда от тази конфигурация реда е:
1. търси се във файла /etc/hosts
2. ако там няма запис питаме конфигурирания DNS сървър

В коментарите има пример (hosts: dns, files, nis), при който първо се пита DNS - сървъра, и ако там няма такъв запис, се гледа в /etc/hosts файла, и ако там също няма запис, се изпраща запитване към конфигурираня NIS - сървър.

При Windows не съм сигурен, дали може да се променя реда на запитванията, но механизмът е следния:

1. Търси се в hosts - файла дали има запис. Той се намира в C:\Windows\System32\drivers\etc.

 C:\Windows\System32\drivers\etc>type hosts
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#       127.0.0.1       localhost
#       ::1             localhost

2. Пита се локалната услуга dns cache (DNS client, ако е стартиран). В случая това е stub resolver, защото сам по себе си той не може да извършва recursive заявки. Поддържа локално "кеширане".

C:\Windows\System32\drivers\etc>net start
These Windows services are started:

   Base Filtering Engine
   COM+ Event System
   Computer Browser
   Cryptographic Services
   DCOM Server Process Launcher
   Desktop Window Manager Session Manager
   DHCP Client
   Diagnostic Policy Service
   Diagnostic Service Host
   Distributed Link Tracking Client
   DNS Client
   ESET Service
   Function Discovery Resource Publication
   Group Policy Client
   Human Interface Device Access
   ......
   ......
   [ cut ]

Както се вижда, услугата локален DNS - cache вече е стартирана. Можем да видим какво има в локалния кеш с командата: C:\Windows\System32\drivers\etc>ipconfig /displaydns.

3. Ако записът го няма нито във файла "hosts", нито в локалната услуга DNS client, (или той не е пуснат) се прави запитване към конфигурирания DNS сървър в TCP/IP settings.

DNS cache сървър

DNS cache е сървър, който прави запитвания към authoritative dns вместо клиента, отговаря на клиента и локално запазва ("кешира") вече получените заявки за определен период. Принципно клиентския компютър никога не би трябвало да прави запитвания директно към authoritative dns - сървъри.

Всяка инсталация на DNS Cache - сървър включва и файл, в който са описани имената и IP - адресите на основните DNS - сървъри, наречени dns root hints. При BIND това е named.root, при djbdns towa e /service/dnscache/root/servers/@, при Windows Server това е C:\WINDOWS\system32\dns\cache.dns. Съдържанието на един такъв файл е:

A.ROOT-SERVERS.NET 198.41.0.4
B.ROOT-SERVERS.NET 192.228.79.201
C.ROOT-SERVERS.NET 192.33.4.12
D.ROOT-SERVERS.NET 128.8.10.90
E.ROOT-SERVERS.NET 192.203.230.10
F.ROOT-SERVERS.NET 192.5.5.241
G.ROOT-SERVERS.NET 192.112.36.4
H.ROOT-SERVERS.NET 128.63.2.53
I.ROOT-SERVERS.NET 192.36.148.17
J.ROOT-SERVERS.NET 192.58.128.30
K.ROOT-SERVERS.NET 193.0.14.129
L.ROOT-SERVERS.NET 199.7.83.42
M.ROOT-SERVERS.NET 202.12.27.33

Този файл е нужен на DNS Cache - сървъра, за да може от някъде да "започне" recursive - запитванията за даден домейн.

За пример ще използвам конфигурацията в моята домашна мрежа:
10.1.42.130 - клиентско PC с конфигуриран DNS 10.1.42.1
10.1.42.1 - DNS recursive cache сървър (в случая dnscache от пакета djbdns)

(потребител) 10.1.42.130 -> на кое IP отговаря www.google.bg? -> 10.1.42.1
(потребител) 10.242.42.130 <- 10.1.42.1 отговаря:

answer: www.google.bg 86400 CNAME www-cctld.l.google.com
answer: www-cctld.l.google.com 300 A 173.194.35.152
answer: www-cctld.l.google.com 300 A 173.194.35.159
answer: www-cctld.l.google.com 300 A 173.194.35.151

www.google.bg всъщност е препратка (CNAME) към адреса www-cctld.l.google.com, който има присвоени три IP адреса . CNAME записът има TTL (time to live) 86400 секунди докато всеки от IP адресите има TTL 300 секунди.

Ето какви операции извършва dns cache - сървъра, за да достави отговора на клиента.

Ако записа го има вече в локалния кеш и все още не му е изтекло TTL (time to live) стойността, клиентът получава кеширания запис. Ако запис липсва, или ако TTL е изтекъл, тоест записа е стар, DNS Cache - сървърът прави следното:

* DNS cache сървърът избира един от IP адресите от root dns hints файла на случаен (или round robin) принцип (примерно 193.0.14.129, k.root-servers.net) и го пита за SOA (Start of Authority) запис.

(dns cache) 10.1.42.1 -> кого да питам за google.bg зоната? -> 193.0.14.129 (k.root-servers.net)
(dns cache) 10.1.42.1 <- за google.bg не знам, но знам кой отговаря за .bg, питай тези DNS сървъри <- 193.0.14.129(k.root-servers.net)

# dnsq soa .bg 193.0.14.129
6 bg:
347 bytes, 1+0+6+9 records, response, noerror
query: 6 bg
authority: bg 172800 NS bg.cctld.authdns.ripe.net
authority: bg 172800 NS ns.register.bg
authority: bg 172800 NS ns2.register.bg
authority: bg 172800 NS ns3.register.bg
authority: bg 172800 NS ns4.register.bg
authority: bg 172800 NS ns-ext.isc.org
additional: bg.cctld.authdns.ripe.net 172800 A 193.0.9.61
additional: ns.register.bg 172800 A 192.92.129.99
additional: ns2.register.bg 172800 A 193.68.3.232
additional: ns3.register.bg 172800 A 94.155.14.10
additional: ns4.register.bg 172800 A 194.0.32.1
additional: ns-ext.isc.org 172800 A 204.152.184.64
additional: bg.cctld.authdns.ripe.net 172800 AAAA 2001:67c:e0:0:0:0:0:61
additional: ns4.register.bg 172800 AAAA 2001:678:3c:0:0:0:0:1
additional: ns-ext.isc.org 172800 AAAA 2001:4f8:0:2:0:0:0:13

Забележка: additional записите за GLUE - записи, които ще бъдат обяснени във втората част на тази статия.

* Нека попитаме отново кой е SOA за .bg използвайки някой от тези сървъри:

# dnsq soa .bg ns.register.bg
6 bg:
214 bytes, 1+1+6+0 records, response, authoritative, noerror
query: 6 bg
answer: bg 345600 SOA ns.register.bg hostmaster.register.bg 2012090506 3600 1800 2592000 86400
authority: bg 345600 NS ns.register.bg
authority: bg 345600 NS bg.cctld.authdns.ripe.net
authority: bg 345600 NS ns4.register.bg
authority: bg 345600 NS ns2.register.bg
authority: bg 345600 NS ns-ext.isc.org
authority: bg 345600 NS ns3.register.bg

* Следващата стъпка на DNS cache - сървъра е да попита един от тези сървъри - примерно 192.92.129.99 (ns.register.bg) за google.bg

(dns cache) 10.1.42.1 ---> кого да питам за google.bg зоната? ---> 192.92.129.99 (ns.register.bg)
(dns cache) 10.1.42.1 <--- за google.bg питай някой от [ns1,ns2,ns3,ns4].google.com  <--- 192.92.129.99 (ns.register.bg)

# dnsq ns google.bg ns.register.bg
6 google.bg:
109 bytes, 1+0+4+0 records, response, noerror
query: 6 google.bg
authority: google.bg 345600 NS ns3.google.com
authority: google.bg 345600 NS ns2.google.com
authority: google.bg 345600 NS ns1.google.com
authority: google.bg 345600 NS ns4.google.com

* В случая Start of Authority (SOA) записът не в същния домейн (.bg) а е в .com домейна, затова следващата стъпка е отново да се изпрати SOA - запитване този път до .com.

# dnsq soa .com k.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
additional: a.gtld-servers.net 172800 AAAA 2001:503:a83e:0:0:0:2:30
additional: b.gtld-servers.net 172800 AAAA 2001:503:231d:0:0:0:2:30

* Питаме някой от тези сървъри: кой отговаря за google.com?

# dnsq soa google.com f.gtld-servers.net
6 google.com:
164 bytes, 1+0+4+4 records, response, noerror
query: 6 google.com
authority: google.com 172800 NS ns2.google.com
authority: google.com 172800 NS ns1.google.com
authority: google.com 172800 NS ns3.google.com
authority: google.com 172800 NS ns4.google.com
additional: ns2.google.com 172800 A 216.239.34.10
additional: ns1.google.com 172800 A 216.239.32.10
additional: ns3.google.com 172800 A 216.239.36.10
additional: ns4.google.com 172800 A 216.239.38.10

* Тук вече има glue - записи за [ns1,ns2,ns3,ns4].google.com.  Питаме ns1.google.com отново SOA.

# dnsq soa google.bg ns1.google.com
6 google.bg:
219 bytes, 1+1+4+4 records, response, authoritative, weird rd, noerror
query: 6 google.bg
answer: google.bg 86400 SOA ns1.google.com dns-admin.google.com 2012032600 21600 3600 1209600 300
authority: google.bg 345600 NS ns4.google.com
authority: google.bg 345600 NS ns1.google.com
authority: google.bg 345600 NS ns2.google.com
authority: google.bg 345600 NS ns3.google.com
additional: ns4.google.com 345600 A 216.239.38.10
additional: ns1.google.com 345600 A 216.239.32.10
additional: ns2.google.com 345600 A 216.239.34.10
additional: ns3.google.com 345600 A 216.239.36.10

От този отговор вече знаем къде със сигурност има authoritative - информация за домейна google.com. SOA - записът на даден домейн е така нареченият "master dns", докато всички останали се водят slave. SOA записът съдържа и друга допълнителна информация за домейна като имейл за контакти (dns-admin@google.com) както сериен номер, TTL и т.н., на който ще обърнем внимание във втора част на тази статия.

* Тъй като вече знаем кого със сигурност да питаме за google.bg, подаваме запитване: кой dns сървъри отговарят за google.bg?

# dnsq ns google.bg ns1.google.com
2 google.bg:
173 bytes, 1+4+0+4 records, response, authoritative, weird rd, noerror
query: 2 google.bg
answer: google.bg 345600 NS ns4.google.com
answer: google.bg 345600 NS ns1.google.com
answer: google.bg 345600 NS ns3.google.com
answer: google.bg 345600 NS ns2.google.com
additional: ns4.google.com 345600 A 216.239.38.10
additional: ns1.google.com 345600 A 216.239.32.10
additional: ns3.google.com 345600 A 216.239.36.10
additional: ns2.google.com 345600 A 216.239.34.10

* Питаме някой от тях за A запис за www.google.bg.

(dns cache) 10.1.42.1 -> на кое IP отговаря www.google.bg? -> 216.239.34.10 (ns2.google.com)
(dns cache) 10.1.42.1 <-  отговор  <-216.239.34.10 (ns2.google.com)

# dnsq a www.google.bg 216.239.34.10
1 www.google.bg:
115 bytes, 1+4+0+0 records, response, authoritative, weird rd, noerror
query: 1 www.google.bg
answer: www.google.bg 86400 CNAME www-cctld.l.google.com
answer: www-cctld.l.google.com 300 A 173.194.35.159
answer: www-cctld.l.google.com 300 A 173.194.35.152
answer: www-cctld.l.google.com 300 A 173.194.35.151

* Резултатът се "кешира" и се връща отговор на клиента:

(dns cache) 10.1.42.1 -> www.google.bg има три IP адреса и те са 173.194.35.159,173.194.35.151, 173.194.35.152 -> 10.1.42.130

Всички тези препратки, докато се стигне до authoritative отговор, се наричат делегиране.

Forwarders

Накратко това са dns cache - сървъри които не правят recursive запитвания а просто "кешират" заявките. За изпълнение на recursive запитвания се използва друг сървър, който се конфигурира допълнително.

10.1.42.130 (клиент) -> 10.1.42.1 (cache only server) -> 212.73.138.38 (sns.neterra.bg)

В случая запитванията от клиента се препращат от 10.1.42.1 сървъра към трети външен dns cache, който изпълнява recursive запитвания, връща отговора на 10.1.42.1, който "кешира" информацията и след това отговаря на клиента. Тази конфигурация е удобна за филтриране на определени домейни. За пример искаме да спрем www.vbox7.com на служителите си и най-лесният начин за това е да се конфигурира dns forwarder като на запитванията за vbox.com да отговаря с IP адрес, на който има web страница - достъпът забранен! Всички останали заявки се препращат на истинския dns cache - сървър който прави recursive заявки.

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

(В примерите е използвана програмата dnsq от пакета djbdns, която позволява изпращането на non-recursive - заявки. Синтаксисът е следният: dnsq [a,mx,ns,soa...] domain.com dnscache/authority server)

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

Допълнителна статия за Windows nslookup: Windows DNS tools и как да ги използваме

Следва продължение...

DNSCurve, NaCl, CurveCP - съвременен поглед върху защитата на данните в интернет.

This summary is not available. Please click here to view the post.