Pages

Thursday, September 27, 2012

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

Monday, September 10, 2012

Kernel Message: INFO: task program:pid blocked for more than 120 seconds. [solved]

От известно време на една production машина взе да излизат подобни errors като този: 

[71521.708522] INFO: task apache2:12319 blocked for more than 120 seconds.
[71521.708567] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[71521.708612] apache2       D c10c5be2     0 12319   1564 0x00000000
[71521.708616]  f686f700 00200082 d2227c38 c10c5be2 d0684354 00000008 00000000 f6997019
[71521.708622]  010f9a20 c142ee80 f686f8bc c142a354 c10be7f4 f686f700 f686f8bc c142ee80
[71521.708628]  d726feac 00000000 00000000 00000000 f5636114 f686f700 f5636118 00000002
[71521.708633] Call Trace:
[71521.708640]  [<c10c5be2>] ? __d_lookup+0xa0/0xd4
[71521.708645]  [<c10be7f4>] ? do_lookup+0x49/0x112
[71521.708650]  [<c12738ee>] ? __mutex_lock_common+0xe7/0x138
[71521.708653]  [<c127394e>] ? __mutex_lock_slowpath+0xf/0x11
[71521.708656]  [<c12737a1>] ? mutex_lock+0x10/0x1d
[71521.708659]  [<c12737a1>] ? mutex_lock+0x10/0x1d
[71521.708663]  [<c10c1080>] ? do_filp_open+0x1da/0x7e3
[71521.708667]  [<c10aa3fc>] ? free_pages_and_swap_cache+0x43/0x50
[71521.708672]  [<c10c8515>] ? alloc_fd+0x4f/0xb1
[71521.708675]  [<c10b6804>] ? do_sys_open+0x49/0xdd
[71521.708678]  [<c10b68dc>] ? sys_open+0x1e/0x23
[71521.708682]  [<c10080db>] ? sysenter_do_call+0x12/0x28
[71521.708687]  [<c127007b>] ? native_cpu_up+0x1ea/0x594
[71521.708692] INFO: task php:14290 blocked for more than 120 seconds.
[71521.708735] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[71521.708780] php           D c10c5be2     0 14290  14289 0x00000000
[71521.708783]  f5a4d500 00000086 d2227c38 c10c5be2 d0604354 00000008 00000000 f6a43019
[71521.708789]  010fada7 c142ee80 f5a4d6bc c142a354 c10be7f4 f5a4d500 f5a4d6bc c142ee80
[71521.708795]  da11feac 00000000 00000000 00000000 f5636114 f5a4d500 f5636118 00000002
[71521.708800] Call Trace:
[71521.708803]  [<c10c5be2>] ? __d_lookup+0xa0/0xd4
[71521.708806]  [<c10be7f4>] ? do_lookup+0x49/0x112
[71521.708809]  [<c12738ee>] ? __mutex_lock_common+0xe7/0x138
[71521.708813]  [<c127394e>] ? __mutex_lock_slowpath+0xf/0x11
[71521.708816]  [<c12737a1>] ? mutex_lock+0x10/0x1d
[71521.708818]  [<c12737a1>] ? mutex_lock+0x10/0x1d
[71521.708822]  [<c10c1080>] ? do_filp_open+0x1da/0x7e3
[71521.708826]  [<c10c8515>] ? alloc_fd+0x4f/0xb1
[71521.708829]  [<c10b6804>] ? do_sys_open+0x49/0xdd
[71521.708832]  [<c1275ed6>] ? do_page_fault+0x2e7/0x2fd
[71521.708835]  [<c10b68dc>] ? sys_open+0x1e/0x23
[71521.708838]  [<c10080db>] ? sysenter_do_call+0x12/0x28

Машината буквално "увисва" за няколко минути. Оказа се че в crontab-a е сложен нов скрипт който изтрива някакви cache файлове.

Какво се оказа. Линукс ядрото кешира всичките дискови операции в паметта като когато се достигне определен процент от заетата RAM, дисковите операции се форсират да се запишат на хард диска. По подразниране в линукс ядрото при 40% от заетата рам се форсира записването им на хард диска, като записа става синхронно тоест всички останали процеси са блокирани за достъп към твърдия диск. От тук идва и проблема, машината е с 16 гигабайта RAM и 40% от 16gb не са никак малко. При достигането на 40% от паметта, форсираното записване продължава повече от 120 секунди (което е някакъв лимит за колко време може да отнеме тази операция) понеже диска не е толкова бърз за да запише всичко се изплюва тази грешка и като резултат машината е недостъпна известно време.

Процентното съотношение на може да се контролира през /etc/sysctl.conf:

vm.dirty_ratio = 7

или с команда:

sysctl vm.dirty_ratio=7

Това указва на ядрото кешираните IO операции да са не повече от 7% от общата RAM.


Wednesday, September 5, 2012

Как работи 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 и как да ги използваме

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

Проверка за променени файлове в Debian

Всеки от пакетите в Debian идва с предварително изчислени checksums на файловете съдържащи се в него.

За целта трябва да имаме инсталиран пакета debsums:

# apt-get install debsums

Ето как може да проверим дали имаме подменени/променени файлове:
# debsums -s -a
debsums: changed file /etc/apache2/sites-available/default (from apache2.2-common package)
debsums: no md5sums for binutils
debsums: no md5sums for dhcp3-server
debsums: no md5sums for doc-debian
debsums: no md5sums for g++
debsums: no md5sums for g++-multilib
debsums: no md5sums for gcc-multilib
debsums: no md5sums for git
debsums: changed file /etc/dhcp/dhcpd.conf (from isc-dhcp-server package)
debsums: no md5sums for mawk
debsums: changed file /etc/cron.d/mrtg (from mrtg package)
debsums: no md5sums for netbase
debsums: no md5sums for php5
debsums: no md5sums for qmail
debsums: changed file /usr/bin/qmhandle (from qmhandle package)
debsums: changed file /etc/rsyslog.conf (from rsyslog package)
debsums: no md5sums for ucspi-tcp-src
debsums: changed file /etc/vim/vimrc (from vim-common package)

Примера е от Debian 6.0 Squeeze наскоро инсталиран и конфигуриран. Вижда се променените конфигурациони файлове. Може да се сложи в crontab да се изпълнява 1 път в седмицата (примерно) и изхода на програмата да се изпраща на емейл.