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 и как да ги използваме
Следва продължение...
