Напоследък повечето игри идват с поддръжка предимно на xbox gamepad. От друга страна на никой не му се дават толкова пари за един gamepad в който на практика няма кой знае какво.
Ето как да играем игри с обикновен gamepad който се разпознава от Windows като Generic USB Joystick.
За целта ви е нужна ето тази програмка - Xbox 360 Controller Emulator, която позволява вашият game контролер (gamepad, joystick, racing wheel ...) да бъде разпознаван от игрите и да работи като XBOX 360 контролер.
След като изтеглите програмата, поставете я в директорията на играта която искате да играете, стартирайте я като преди това сте включили game контролера. Когато x360ce открие контролера, на tab-а controller 1 ще се появи допълнителна опция - Generic USB Joystick и tab-а ще светне в червено. Разгледайте падащото меню с Presets и изпробвайте някои от тези предварително зададени настройки. При зареждане на настройките с 'Load' бутона, очакваните резултати са tab-a с контролер 1 да светне в зелено. При мен нещата тръгнаха идеално с Phillips PC compatible preset-а. Записвате настройките с бутона 'Save' след което излизате от програмката. При записване на настройките, x360ce генерира файл именуван xinput1_3.dll и го записва в текущата директория (на играта).
При стартиране на игра която поддържа x360 gamepad, тя автоматично ще зареди този файл и вече ще можете да изполвате контролера си като емулиран xbox gamepad.
Тествани от мен игри които работят с x360ce - F1 Race Stars, Skyrim.
Monday, December 10, 2012
Monday, December 3, 2012
Lotus Notes 8.5.3 on Debian Unstable problems and solution.
Lotus Notes 8.5.3 on Debian Unstable problems and solution
(based on link from ibm site with Ubuntu 11.10 solution).
Get debian packages of Lotus Notes 8.5.3 and install them.
List of available packages for Debian :
Install what you need with 'dpkg -i'. Here are dependencies for Lotus Notes packages so you can install whatever is needed.
Lotus Sametime chat client also works fine for me.
(based on link from ibm site with Ubuntu 11.10 solution).
Get debian packages of Lotus Notes 8.5.3 and install them.
List of available packages for Debian :
ibm-lotus-activities-8.5.3.i586.deb
ibm-lotus-cae-8.5.3.i586.deb
ibm-lotus-feedreader-8.5.3.i586.deb
ibm-lotus-notes-8.5.3.i586.deb
ibm-lotus-sametime-8.5.3.i586.deb
ibm-lotus-symphony-8.5.3.i586.deb
Install what you need with 'dpkg -i'. Here are dependencies for Lotus Notes packages so you can install whatever is needed.
$ apt-cache show ibm-lotus-notesYou need extra fonts which are in non-free repository of Debian Unstable so you need to enable this if you want your Notes client to look like win32 one.
Package: ibm-lotus-notes
Status: install ok installed
Priority: extra
Section: IBM
Installed-Size: 681204
Maintainer: IBM Lotus Product <sw_support@us.ibm.com>
Architecture: i386
Version: 8.5.3-20110916.0921
Replaces: ibm-lotus-notes-fixpack
Depends: gdb, coreutils, unzip, bash, procps, grep, sed, libart-2.0-2, libasound2, libatk1.0-0, libbonobo2-0, libbonoboui2-0, libc6, libcupsys2, libfontconfig1, libfreetype6, libgcc1, libgconf2-4, libgtk2.0-0, libglib2.0-0, libgnome2-0, libgnomecanvas2-0, libgnome-desktop-2 | libgnome-desktop-2-7 | libgnome-desktop-2-11 | libgnome-desktop-2-17, libgnomeui-0, libgnomevfs2-0, libglib2.0-0, libice6, libjpeg62, liborbit2, libpam0g, libpango1.0-0, libpng12-0, libpopt0, libsm6, libstdc++6, libx11-6, libxcursor1, libxext6, libxft2, libxi6, libxkbfile1, libxml2, libxp6, libxrender1, libxss1, libxt6, libxtst6, libz1
Pre-Depends: libgnomeprint2.2-0, libgnomeprintui2.2-0
Recommends: ttf-xfree86-nonfree
Conflicts: ibm-lotus-notes-hotfix, ibm-lotus-notes-fixpack (<< 8.5.3)
$ apt-get install ttf-xfree86-nonfree t1-xfree86-nonfreeWe also need to get some additional libs which are specific to this release and to place them in /opt/ibm/lotus/notes directory.
# wget http://www.benkevan.com/upload/lotus_notes/libgdk-x11-2.0.so.0Start your Notes now and everything should be ok. If you have Notes installation on Windows you can transfer file desktop8.ndk (found somewhere in local user Notes directory) and place it in ~/lotus/notes/data/. When you start your Notes select Open -> Application -> Workspace.
# wget http://www.benkevan.com/upload/lotus_notes/libgdk_pixbuf-2.0.so.0
# wget http://www.benkevan.com/upload/lotus_notes/libgdk_pixbuf_xlib-2.0.so.0
# wget http://www.benkevan.com/upload/lotus_notes/libgtk-x11-2.0.so.0
# mv *.so.0 /opt/ibm/lotus/notes
Lotus Sametime chat client also works fine for me.
Изложба на Иван Христов Грога, галерия Аспект, Пловдив
Изложба на Иван Христов Грога
На 12 декември 2012 година, Иван Христов Грога открива изложба в галерия Аспект, пл. Стефан Стамболов 1А, Пловдив. Откриването е 16:00 до 18:00 часа.
За повече информация може да посетите Facebook страницата на Иван Христов Грога.
Както и страницата му: http://groga.gabrovo.com/.
На 12 декември 2012 година, Иван Христов Грога открива изложба в галерия Аспект, пл. Стефан Стамболов 1А, Пловдив. Откриването е 16:00 до 18:00 часа.
За повече информация може да посетите Facebook страницата на Иван Христов Грога.
Както и страницата му: http://groga.gabrovo.com/.
Sunday, December 2, 2012
GNOME 3 Fallback - къде са ми иконките на десктопа?
Новият GNOME 3 е прекрасен ... вероятно ако го използвате за телефон. Добре че има и fallback сесия за тези които харесват стария стил на GNOME 2.
Проблем: Липсват ми иконите на десктопа, right/left click с мишката нищо не прави. Как да си върнем предишната функционалност?
Решение:
$ gsettings set org.gnome.desktop.background show-desktop-icons true
Проблем: Десен бутон върху панела не работи и не мога да му променя настройките?
Решение: Просто задръжте ALT + right click върху панела и менютата ще се появят.
Проблем: Десен бутон върху App менютата не работи. Как да си направя shortcuts на десктопа?
Решение: Използвайте drag-n-drop функцията. Отивате на менюто, избирате елемента който искате да имате на shortcut, хващате го с левия бутон на мишката и го пускате върху десктопа. Вече имате иконка-shortcut.
Проблем: Иконите на десктопа са прекалено големи, как да им намаля големината?
Решение: Отваряме nautilus (примерно double-click на някоя икона от десктопа като 'home'). След това избираме Edit -> Preferences -> Views и разглеждаме опцията Icon View Defaults като я сменяме с някоя от изброените стойности в падащото меню. При мен добре се получава на 66% default zoom level.
Tuesday, November 27, 2012
Проблем с F1 2012 и Logitech Driving Force GT Wheel
Наскоро си закупих ето това чудо Logitech Driving Force GT и естествено го тествах с демото на F1 2012. Оказва се, че първоначалните настройки са объркани и воланът е прекалено чувствителен и е много трудно да се играе. Поиграх си с настройките и успях да го докарам до положение в което реагира както очаквам.
Ето какво точно съм сменил:
В Logitech Profiler направих радиуса на волана да е заключен на 271 градуса.
В Logitech Profiler направих Centering wheel на 45%.
В настройките на F1 2012 промених следните неща:
Много е важна опцията Override Input Device Type, тъй като вградените настройки на DFGT в F1 2012 са сбъркани и воланът е прекалено чувствителен.
Интересно е да се отбележе, че на F1 2011 този проблем го няма с настройките по подразбиране на този волан.
rFactor също се държи идеално.
Ако имате по-добри настройки/предложения за настройки за F1 2012 пишете в коментарите.
Редактирано 07.01.2013:
Още една примерна конфигурация която се държи дори по-добре от гореописаната:
Ето какво точно съм сменил:
В Logitech Profiler направих радиуса на волана да е заключен на 271 градуса.
В Logitech Profiler направих Centering wheel на 45%.
В настройките на F1 2012 промених следните неща:
Driving Controls -> Override Input Device Type -> Steering WheelВсичко останало на 0% (освен deadzone опциите които за всеки човек настройките са различни).
Driving Controls -> Advanced Wheel Settings -> Steering Deadzone - 1%
Driving Controls -> Advanced Wheel Settings -> Steering Saturation - 0%
Driving Controls -> Advanced Wheel Settings -> Steering Linearity - от 60 до 65% (в зависимост как ви харесва, при мен е на 60%)
Много е важна опцията Override Input Device Type, тъй като вградените настройки на DFGT в F1 2012 са сбъркани и воланът е прекалено чувствителен.
Интересно е да се отбележе, че на F1 2011 този проблем го няма с настройките по подразбиране на този волан.
rFactor също се държи идеално.
Ако имате по-добри настройки/предложения за настройки за F1 2012 пишете в коментарите.
Редактирано 07.01.2013:
Още една примерна конфигурация която се държи дори по-добре от гореописаната:
В Logitech Profiler направих радиуса на волана да е заключен на 310 градуса.
Driving Controls -> Override Input Device Type -> Steering Wheel
Driving Controls -> Advanced Wheel Settings -> Steering Deadzone - 1%
Driving Controls -> Advanced Wheel Settings -> Steering Saturation - 10%
Driving Controls -> Advanced Wheel Settings -> Steering Linearity - 63%
Wednesday, November 21, 2012
Outlook 2010 reported error (0x800CCC0F) : Outlook cannot synchronize subscribed folders"
Outlook 2010 reported error (0x800CCC0F) : Outlook cannot synchronize subscribed folders"
С новият MS Office 2010 пакет идват и нови проблеми. При upgrade на Outlook до 2010 и използване на IMAP акаунт се получава следната грешка:
Оказва се че Outlook 2010 при изтриване на съобщение при IMAP акаунт емейла се маркира като изтрит, но освен това се опитва да го премести в папка за изтрити съобщения. Старата версия на Outlook просто ги маркираше като изтрити без да ги мести никъде (и при purge се изтриваха).
Оказва се че по подразбиране на Outlook 2010 не е указана папката в която да се местят при изтриване съобщенията и при всеки опит да се провери пощата, Outlook се опитва да премести всички изтрити съобщения (които не са purged) в несъществуваща папка.
За да оправим този проблем е нужно следното, отиваме в Account Settings -> Advanced Account Settings след което избираме tab-a "Deleted Items". Избираме опцията "Mark items to delete but not move them", цъкаме на ок и всичко е наред.
С новият MS Office 2010 пакет идват и нови проблеми. При upgrade на Outlook до 2010 и използване на IMAP акаунт се получава следната грешка:
Outlook reported error (0x800CCC0F) : Outlook cannot synchronize subscribed folders"
Оказва се че Outlook 2010 при изтриване на съобщение при IMAP акаунт емейла се маркира като изтрит, но освен това се опитва да го премести в папка за изтрити съобщения. Старата версия на Outlook просто ги маркираше като изтрити без да ги мести никъде (и при purge се изтриваха).
Оказва се че по подразбиране на Outlook 2010 не е указана папката в която да се местят при изтриване съобщенията и при всеки опит да се провери пощата, Outlook се опитва да премести всички изтрити съобщения (които не са purged) в несъществуваща папка.
За да оправим този проблем е нужно следното, отиваме в Account Settings -> Advanced Account Settings след което избираме tab-a "Deleted Items". Избираме опцията "Mark items to delete but not move them", цъкаме на ок и всичко е наред.
Wednesday, November 14, 2012
Как работи 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 го има на пакет. Инсталираме го:
Конфигурацията на bind се намира в /etc/bind/ - директорията, като файла се казва named.conf. В Debian този файл е разделен на няколко файла, като във всеки от тях се конфигурират отделни неща. Ето:
Както се вижда, настройките се правят в няколко отделни файла. Тъй като ние искаме да конфигурираме само cache сървър, файлът който ни интересува е named.conf.options.
С този ред разрешяваме recursive запитвания към dns cache сървъра от мрежата 172.20.20.0/255.255.255.0 както и от IP адреса 172.20.30.3. Съответно - променяте ги на ip/мрежите които ще го ползват като dns cache сървър.
Вече имате работещ 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 пакета съдържа няколко програми, като всяка от която върши определена работа:
Тъй като ще инсталираме dns cache сървър, ще разгледаме dnscache и програмата за конфигуриране, която върви към него - dnscache-conf. Синтаксиса на програмата е следния:
където:
acct - нужен е да се създаде потребителски акаунт, с който ще се стартира dnscache;
logacct - нужен е да се създаде потребителски акаунт, с който ще се стартира multilog, който ще записва log - файловете на dnscache;
/directory - в коя директория да бъдат създадени стартиращите/log - файлове на dnscache
myip - на кое IP ще "слуша" dnscache.
Остава да укажем от кои ip/мрежи е разрешен да се ползва dns cache сървърът. Това се прави в директорията /etc/dnscache/root/ip/, като в нея се създават празни файлове с имената на мрежи/ip адреси от които може да се ползва сървъра.
Както следва, dnscache може да се използва от 127.0.0.1 ip адреса и от мрежата 172.20.20.0/24
Остава само да стартираме dnscache. Това става, като направим symbolic link към /etc/services директорията:
Конфигурационната директория на djbdns се намира в /etc/dnscache/env, като всички променливи са в отделни файлове.
По подразбиране CACHESIZE е 1000000 байта, което е твърде малко и трябва да бъде променено на по-голяма стойност в зависимост от свободната памет с която разполагате.
DATALIMIT се използва от програмата softlimit, която ограничава dnscache да използва определен ресурс памет. DATASIZE трябва да е по-голям от CACHESIZE.
ROOT указва в коя директория се намират dns root hints.
IP указва на кой IP адрес ще отговаря dnscache при запитвания.
IPSEND указва от кой адрес да се изпращат рекурсивните заявки.
Тези стойности указват 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 сървъри: 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
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).
пример
В случая правим запитване за 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 домейна . (точка), както е видно и от следния пример:
Както е видно, за 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 сървърите за даденния домейн, по следния начин:
Както се вижда този ред "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 сървърите:
Повече информация за GLUE записите: http://tools.ietf.org/html/draft-koch-dns-glue-clarifications-04
Reverse DNS (PTR записи)
Това е така нареченият "обратен resolving", на кой hostname отговаря даденият IP адрес. Това на практика е един специален домейн, който се нарича in-addr.arpa.
За Top-Level домейна ARPA authritative dns сървъри са root dns сървърите
За домейна in-addr.arpa dns сървърите са [a-f].in-addr.servers.arpa както и glue записите към тях.
Тук вече получихме достоверна информация за in-addr.arpa dns сървърите.
Зоните в домейна in-addr.arpa се състоят от IP адресите на мрежите на които ще се правят PTR записи. Разликата е че мрежите се пишат в обратен ред. Пример за мрежата 216.239.32.0/24:
За повече информация можете да прочетете 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
Видно е, че при второто запитване отговорът е 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 запис, като приоритета им се указва чрез число, при което колкото е по-ниска стойността, е с по-голям приоритет. Пример:
Както се вижда от примера по-горе, с най-голям приоритет от тези мейл сървъри е 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
Пример за това как изглежда една стандартно конфигурирана зона:
За да имаме собствени DNS сървъри като за начало е нужно да си закупим домейн. Това става от съответната фирма, предлагаща тази услга. Това което трябва да направите при регистрацията, е да добавите 2 DNS сървъра, както и GLUE записите към тях.
Ако сме закупили домейна example.com, трябва да въведем и DNS сървърите, които ще обслужват този домейн заедно с техните IP адреси в административния панел за DNS на сайта, от който сме купили домейна. Например:
Примерни инсталация и конфигурация на тези сървъри ще бъде разгледано в третата част на тази поредица от статии за DNS.
Lame nameservers
Това са DNS сървъри, които са посочени за authoritative dns за даден домейн, но не са конфигурирани да отговарят на запитвания за този домейн. С други думи, те връщат отговор от типа - refused. Ето пример за lame nameserver:
Кои са dns сървърите, обслужващи зоната cnsys.bg?
Нека попитаме за mx - запис към домейна cnsys.bg. Първо питаме ns.btc-net.bg.
Да попитаме вторият DNS сървър (ns2.atlantis.bg) за същото:
Как да инсталираме и конфигурираме authoritative dns сървър ще разгледаме в следващата част на тази поредица статии.
Статията е публикувана в http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=450185369
DNS протокол
Комуникацията на DNS преминава предимно по UDP протокола. Това гарантира възможно най-малко забавяне на отговорите. Правило е че UDP DNS заявките не трябва да бъдат по-големи от 512 байта, като се има впредвид, че и най-зле конфигурираните рутери ще пропускат UDP пакети с големина 512 байта. Когато отговорът надвиши тази големина, се преминава към TCP - протокола, а това е по-бавният вариант за обмяна на DNS информация.
Връзката между клиент и сървър се осъществява чрез запитване (query) и отговор (answer).
Запитването се състои от "запитване за запис на ресурс" или Resource Record query (или за по-кратко RR query) и съответно - отговор с данните за ресурса, ако е открит, или отрицателен отговор NXDOMAIN (non-existent domain).
пример
# host -v -t ns google.bg ns1.google.com
Trying "google.bg"
Using domain server:
Name: ns1.google.com
Address: 216.239.32.10#53
Aliases:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63087
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4
;; QUESTION SECTION:
;google.bg. IN NS
;; ANSWER SECTION:
google.bg. 345600 IN NS ns1.google.com.
google.bg. 345600 IN NS ns2.google.com.
google.bg. 345600 IN NS ns4.google.com.
google.bg. 345600 IN NS ns3.google.com.
;; ADDITIONAL SECTION:
ns1.google.com. 345600 IN A 216.239.32.10
ns2.google.com. 345600 IN A 216.239.34.10
ns4.google.com. 345600 IN A 216.239.38.10
ns3.google.com. 345600 IN A 216.239.36.10
Received 173 bytes from 216.239.32.10#53 in 48 ms
В случая правим запитване за RR - тип NS, тоест "кои DNS - сървъри обслужват зоната google.bg?". Отговорът както се вижда, са 4 DNS сървъра и техния TTL (time to live, или колко време да се "кешират" записите от DNS cache сървърите). Списъкът на типа запитвания за RR не е малък, но по-голямата част рядко се ползва. Ще изброя най-често използваните RR queries, придружени с кратко описание.
SOA - Start of authority или "достоверен източник", от където със сигурност ще разберем кой "master dns" обслужва дадения домейн.
NS - "кои DNS сървъри обслужват дадения домейн?"
A - най-често се използва за свързване на hostname към IP адрес. A записът www към домейна linux-bg.org отговаря на IP адрес 212.50.10.155 (www.linux-bg.org).
MX - "кои мейл сървъри обслужват пощата за дадения домейн?"
TXT - може да се използва за всичко, ако искате може да си напишете "This is my DNS" и при RR тип TXT ще получите точно това. Принципно се използва за SPF anti-spam записи.
CNAME - това е псевдоним към друг hostname, например www.google.bg е псевдоним (alias) към www.l.google.com.
PTR - "на кой hostname отговаря дадения IP адрес?", или това е обратното на A запис.
AAAA - същото като A запис, но за IPv6 адреси.
ANY - всички записи, касаещи дадения домейн.
Топология на DNS
Структурата на DNS е йерархична, като в основата се намират сървърите от root hints файла. Те обслужват root домейна . (точка), както е видно и от следния пример:
# host -t soa . c.root-servers.netТези dns root сървъри са authoritative само за . домейна. За всички останали, те имат препратки, към които евентуално могат да знаят къде се намира SOA записът на даден домейн.
Using domain server:
Name: c.root-servers.net
Address: 192.33.4.12#53
Aliases:
. has SOA record a.root-servers.net. nstld.verisign-grs.com. 2012091300 1800 900 604800 86400
# dnsq soa .com a.root-servers.net
6 com:
509 bytes, 1+0+13+15 records, response, noerror
query: 6 com
authority: com 172800 NS a.gtld-servers.net
authority: com 172800 NS b.gtld-servers.net
authority: com 172800 NS c.gtld-servers.net
authority: com 172800 NS d.gtld-servers.net
authority: com 172800 NS e.gtld-servers.net
authority: com 172800 NS f.gtld-servers.net
authority: com 172800 NS g.gtld-servers.net
authority: com 172800 NS h.gtld-servers.net
authority: com 172800 NS i.gtld-servers.net
authority: com 172800 NS j.gtld-servers.net
authority: com 172800 NS k.gtld-servers.net
authority: com 172800 NS l.gtld-servers.net
authority: com 172800 NS m.gtld-servers.net
additional: a.gtld-servers.net 172800 A 192.5.6.30
additional: b.gtld-servers.net 172800 A 192.33.14.30
additional: c.gtld-servers.net 172800 A 192.26.92.30
additional: d.gtld-servers.net 172800 A 192.31.80.30
additional: e.gtld-servers.net 172800 A 192.12.94.30
additional: f.gtld-servers.net 172800 A 192.35.51.30
additional: g.gtld-servers.net 172800 A 192.42.93.30
additional: h.gtld-servers.net 172800 A 192.54.112.30
additional: i.gtld-servers.net 172800 A 192.43.172.30
additional: j.gtld-servers.net 172800 A 192.48.79.30
additional: k.gtld-servers.net 172800 A 192.52.178.30
additional: l.gtld-servers.net 172800 A 192.41.162.30
additional: m.gtld-servers.net 172800 A 192.55.83.30
Както е видно, за TLD има 13 сървъра, които са именувани по подобие на root сървърите, а те са [a-m].gtld-servers.net.
Домейните от типа .com, .net, .org се наричат Top-level Domains (TLD), като специфичните домейни на държави като .bg, .de и т.н. се наричат Country Code Top-Level Domains (ccTLD).
GLUE записи
Когато authoritative DNS сървърите на дадена зона (example.com) са в самата зона (ns1.example.com, ns2.example.com,...), се получава проблем с откриването на IP адресите им.
За това е нужно, при регистрацията на домейн, да се зададат така наречените GLUE записи (допълнителен A запис), които са допълнителни записи с IP адресите на authoritative dns сървърите за даденния домейн, по следния начин:
ns1.example.com 123.123.123.1GLUE - записите могат да се диагностицират чрез някои от достъпните по мрежата DNS инструменти като http://www.webdnstools.com/dnstools/domain_check , или чрез програмките dnstrace, dnstracesort от пакета djbdns. Dnstrace започва от root сървърите и следва всички препратки за дадения домейн. Изходът на програмата е доста обемист, за това ще покажем само малка част от него:
ns2.example.com 123.222.123.2
# dnstrace ns google.com b.root-servers.net | dnstracesort > google.com.txt
# ls -la google.com.txt
-rw-r--r-- 1 root wheel 726714 Sep 14 10:54 google.com
забележка: DNS сървърите на google.com са от мрежата 216.239.3хх.ххх за това правя извадка само на тези IP-та от dnstrace.
# cat google.com.txt|grep 216.239.3
- [cut ] -
1 ns1.google.com 216.239.32.10 345600 A 216.239.32.10
1 ns2.google.com 216.239.32.10 345600 A 216.239.34.10
1 ns3.google.com 216.239.32.10 345600 A 216.239.36.10
1 ns4.google.com 216.239.38.10 345600 A 216.239.38.10
...
glue google.com 216.239.32.10 NS ns1.google.com
glue google.com 216.239.32.10 NS ns2.google.com
glue google.com 216.239.32.10 NS ns3.google.com
glue google.com 216.239.32.10 NS ns4.google.com
...
glue ns1.google.com 192.12.94.30 A 216.239.32.10
glue ns1.google.com 192.26.92.30 A 216.239.32.10
glue ns1.google.com 192.31.80.30 A 216.239.32.10
glue ns1.google.com 192.33.14.30 A 216.239.32.10
glue ns1.google.com 192.35.51.30 A 216.239.32.10
glue ns1.google.com 192.41.162.30 A 216.239.32.10
glue ns1.google.com 192.42.93.30 A 216.239.32.10
glue ns1.google.com 192.43.172.30 A 216.239.32.10
glue ns1.google.com 192.48.79.30 A 216.239.32.10
glue ns1.google.com 192.5.6.30 A 216.239.32.10
glue ns1.google.com 192.52.178.30 A 216.239.32.10
glue ns1.google.com 192.54.112.30 A 216.239.32.10
glue ns1.google.com 192.55.83.30 A 216.239.32.10
glue ns1.google.com 216.239.32.10 A 216.239.32.10
glue ns1.google.com 216.239.34.10 A 216.239.32.10
glue ns1.google.com 216.239.36.10 A 216.239.32.10
glue ns1.google.com 216.239.38.10 A 216.239.32.10
...
- [ cut ] -
Както се вижда този ред "glue ns1.google.com 192.12.94.30 A 216.239.32.10" dns сървърът 192.12.94.30 има допълнителен A (glue) запис за ns1.google.com който е 216.239.32.10. IP адреса 192.12.94.30 всъщност е един от global TLD сървърите:
# host 192.12.94.30
30.94.12.192.in-addr.arpa domain name pointer e.gtld-servers.net.
Повече информация за GLUE записите: http://tools.ietf.org/html/draft-koch-dns-glue-clarifications-04
Reverse DNS (PTR записи)
Това е така нареченият "обратен resolving", на кой hostname отговаря даденият IP адрес. Това на практика е един специален домейн, който се нарича in-addr.arpa.
# dnsq soa arpa f.root-servers.net
6 arpa:
508 bytes, 1+1+12+13 records, response, authoritative, noerror
query: 6 arpa
answer: arpa 86400 SOA a.root-servers.net nstld.verisign-grs.com 2012091400 1800 900 604800 86400
authority: arpa 518400 NS c.root-servers.net
authority: arpa 518400 NS d.root-servers.net
authority: arpa 518400 NS m.root-servers.net
authority: arpa 518400 NS i.root-servers.net
authority: arpa 518400 NS f.root-servers.net
authority: arpa 518400 NS l.root-servers.net
authority: arpa 518400 NS h.root-servers.net
authority: arpa 518400 NS k.root-servers.net
authority: arpa 518400 NS g.root-servers.net
authority: arpa 518400 NS b.root-servers.net
authority: arpa 518400 NS e.root-servers.net
authority: arpa 518400 NS a.root-servers.net
- [ cut ] -
За Top-Level домейна ARPA authritative dns сървъри са root dns сървърите
# dnsq soa in-addr.arpa f.root-servers.net
6 in-addr.arpa:
406 bytes, 1+0+6+12 records, response, noerror
query: 6 in-addr.arpa
authority: in-addr.arpa 172800 NS e.in-addr-servers.arpa
authority: in-addr.arpa 172800 NS c.in-addr-servers.arpa
authority: in-addr.arpa 172800 NS f.in-addr-servers.arpa
authority: in-addr.arpa 172800 NS b.in-addr-servers.arpa
authority: in-addr.arpa 172800 NS a.in-addr-servers.arpa
authority: in-addr.arpa 172800 NS d.in-addr-servers.arpa
additional: a.in-addr-servers.arpa 172800 A 199.212.0.73
additional: b.in-addr-servers.arpa 172800 A 199.253.183.183
additional: c.in-addr-servers.arpa 172800 A 196.216.169.10
additional: d.in-addr-servers.arpa 172800 A 200.10.60.53
additional: e.in-addr-servers.arpa 172800 A 203.119.86.101
additional: f.in-addr-servers.arpa 172800 A 193.0.9.1
За домейна in-addr.arpa dns сървърите са [a-f].in-addr.servers.arpa както и glue записите към тях.
# dnsq ns in-addr.arpa e.in-addr-servers.arpa
2 in-addr.arpa:
142 bytes, 1+6+0+0 records, response, authoritative, noerror
query: 2 in-addr.arpa
answer: in-addr.arpa 86400 NS d.in-addr-servers.arpa
answer: in-addr.arpa 86400 NS f.in-addr-servers.arpa
answer: in-addr.arpa 86400 NS a.in-addr-servers.arpa
answer: in-addr.arpa 86400 NS b.in-addr-servers.arpa
answer: in-addr.arpa 86400 NS e.in-addr-servers.arpa
answer: in-addr.arpa 86400 NS c.in-addr-servers.arpa
Тук вече получихме достоверна информация за in-addr.arpa dns сървърите.
Зоните в домейна in-addr.arpa се състоят от IP адресите на мрежите на които ще се правят PTR записи. Разликата е че мрежите се пишат в обратен ред. Пример за мрежата 216.239.32.0/24:
# dnsq soa 32.239.216.in-addr.arpa a.in-addr-servers.arpaКакто се вижда по-горе, зоната за мрежата 216.239.32.х (32.239.216.in-addr.arpa) е делегирана към ns1.google.com.
6 32.239.216.in-addr.arpa:
177 bytes, 1+0+8+0 records, response, noerror
query: 6 32.239.216.in-addr.arpa
authority: 216.in-addr.arpa 86400 NS u.arin.net
authority: 216.in-addr.arpa 86400 NS w.arin.net
authority: 216.in-addr.arpa 86400 NS t.arin.net
authority: 216.in-addr.arpa 86400 NS v.arin.net
authority: 216.in-addr.arpa 86400 NS z.arin.net
authority: 216.in-addr.arpa 86400 NS y.arin.net
authority: 216.in-addr.arpa 86400 NS r.arin.net
authority: 216.in-addr.arpa 86400 NS x.arin.net
# dnsq soa 32.239.216.in-addr.arpa u.arin.net
6 32.239.216.in-addr.arpa:
123 bytes, 1+0+4+0 records, response, noerror
query: 6 32.239.216.in-addr.arpa
authority: 32.239.216.in-addr.arpa 86400 NS ns4.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns2.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns3.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns1.google.com
# dnsq soa 32.239.216.in-addr.arpa ns1.google.com
6 32.239.216.in-addr.arpa:
233 bytes, 1+1+4+4 records, response, authoritative, weird rd, noerror
query: 6 32.239.216.in-addr.arpa
answer: 32.239.216.in-addr.arpa 86400 SOA ns1.google.com dns-admin.google.com 2012082800 21600 3600 1209600 10800
authority: 32.239.216.in-addr.arpa 86400 NS ns1.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns2.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns4.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns3.google.com
additional: ns1.google.com 345600 A 216.239.32.10
additional: ns2.google.com 345600 A 216.239.34.10
additional: ns4.google.com 345600 A 216.239.38.10
additional: ns3.google.com 345600 A 216.239.36.10
За повече информация можете да прочетете RFC2317 - Classless in-addr.arpa delegaion.
Authoritative DNS сървър
Authoritative DNS сървър е сървър, който е конфигуриран да отговаря на запитвания за дадени домейни. Той не изпълнява recursive dns запитвания, и е строго ограничен само до отговори за предварително конфигурираните домейни.
Тук трябва да се отбележи объркването и смесването на понятията "dns cache" и "authoritative dns сървър", дължащо се на най-разпространата имплементация на dns сървър - BIND.
Добрите практики за сигурност показват, че authoritative dns и dns cache сървърите трябва да са отделни програми, стартирани като отделни процеси, слушащи на отделни IP адреси. При BIND, двата сървъра са в един процес. Чак от BIND 10 тези сървъри ще бъдат отделни процеси.
Ето пример за отговори:
питаме dns cache сървър (10.1.42.1) за два dns записа - www.google.com и www.linux-bg.org
# host www.google.com 10.1.42.1питаме authoritative dns сървър (в случая ns1.google.com за зоната google.com) за www.google.com и www.linux-bg.org.
Using domain server:
Name: 10.1.42.1
Address: 10.1.42.1#53
Aliases:
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 173.194.35.144
www.l.google.com has address 173.194.35.148
www.l.google.com has address 173.194.35.147
www.l.google.com has address 173.194.35.145
www.l.google.com has address 173.194.35.146
# host www.linux-bg.org 10.1.42.1
Using domain server:
Name: 10.1.42.1
Address: 10.1.42.1#53
Aliases:
www.linux-bg.org has address 212.50.10.155
# host www.google.com ns1.google.com
Using domain server:
Name: ns1.google.com
Address: 216.239.32.10#53
Aliases:
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 173.194.35.148
www.l.google.com has address 173.194.35.147
www.l.google.com has address 173.194.35.145
www.l.google.com has address 173.194.35.144
www.l.google.com has address 173.194.35.146
# host www.linux-bg.org ns1.google.com
Using domain server:
Name: ns1.google.com
Address: 216.239.32.10#53
Aliases:
Host www.linux-bg.org not found: 5(REFUSED)
Видно е, че при второто запитване отговорът е REFUSED. Това показва, че ns1.google.com не изпълнява recursive запитвания и отговаря само за google.com зоната (както и за други зони за които е конфигуриран да е authoritative).
Препоръки за authoritative dns
Тъй като dns е много чувствителен от към бързината на достъп, има няколко изисквания, преди да си инсталираме authoritative dns сървър за обслужване на личен домейн.
* препоръчително е да имате 2 IP адреса от различни мрежи, свързани с различни доставчици;
* скоростта трябва да е гарантирана до известна степен в двете посоки;
* прекъсванията на интернета да бъдат възможно най-малки.
Ако не можете да осигурите тези изисквания, Ви препоръчвам да използвате за dns hosting сървърите на фирмата, от която сте закупили дадения домейн, освен ако не сте ентусиаст и искате да се научите.
Конфигурационният файл на един authoritative dns сървър се състои от отделни "зони", които на практика представляват списък с Resource Records за даден домейн. Всяка зона трябва да съдържа:
* SOA - запис - master.dns.domain.com, email.za.kontakti.domain.com, сериен номер, refresh, retry, expire, min TTL.
master dns - основен dns сървър.
email - емейл за контакти при проблеми с този домейн.
serial - сериен номер чрез който се разбира по данните на домейна има промени. Препоръчително да текущата дата на промените във формат: DDMMYYYYX, където X e брой промени за деня.
refresh - след колко секунди slave dns сървъра ще се опита да обнови данните си от master dns.
retry - при проблем, след колко секунди slave dns сървъра ще се опита отново да опресни данните от master dns.
expire - при проблем с обновлението, след колко секунди slave dns сървъра ще спре да отговаря на запитвания за дадения домейн, тъй като данните ще бъдат смятани за остарели.
* NS - запис - минимун един, от типа ns1.domain.com
* A - запис - A запис за ns1 към domain.com
ако домейна ще получава поща, е нужен и поне един:
* MX - запис - hostname, където ще се намира мейл сървърите обслужващи domain.com, например mail.domain.com. Може да имате повече от един mx запис, като приоритета им се указва чрез число, при което колкото е по-ниска стойността, е с по-голям приоритет. Пример:
# dnsq mx google.com ns1.google.com
15 google.com:
216 bytes, 1+5+0+5 records, response, authoritative, weird rd, noerror
query: 15 google.com
answer: google.com 600 MX 20 alt1.aspmx.l.google.com
answer: google.com 600 MX 10 aspmx.l.google.com
answer: google.com 600 MX 50 alt4.aspmx.l.google.com
answer: google.com 600 MX 30 alt2.aspmx.l.google.com
answer: google.com 600 MX 40 alt3.aspmx.l.google.com
Както се вижда от примера по-горе, с най-голям приоритет от тези мейл сървъри е aspmx.l.google.com, който е с най-ниска стойност (10), а с най-нисък приоритет е alt4.aspmx.l.google.com (50).
* A - запис - за mail.domain.com към кое IP сочи
ако домейна ще бъде достъпен през web сървър е нужен запис:
* A - запис - А запис за www към домейна domain.com, тоест на кое IP отговаря www.domain.com.
* TXT - препоръчително е да се използва за SPF запис, когато има конфигурирани MX записи (www.openspf.org).
* Празен A - запис - това не нужно, за да работи web сървъра (примерно www.domain.com), когато потребителите не пишат www.domain.com, а само domain.com
Пример за това как изглежда една стандартно конфигурирана зона:
Зона example.com ns1.example.com. hostmaster.example.com. 2012010601 3600 600 120960 3600 3600
NS запис ns1.example.com 3600
NS запис ns2.example.com 3600
MX запис mail1.example.com 10 86400
MX запис mail2.example.com 100 86400
А запис ns1.example.com 193.22.103.226 3600
А запис ns2.example.com 193.22.103.2 3600
А запис example.com 195.177.249.170 3600
А запис mail1.example.com 195.177.249.170 3600
А запис mail2.example.com 195.177.249.170 3600
А запис archive.example.com 195.177.249.170 3600
А запис blog.example.com 195.177.249.170 3600
А запис www.example.com 195.177.249.170 86400
TXT запис за SPF "v=spf1 mx a:mail1.example.com a:mail2.example.com -all"
За да имаме собствени DNS сървъри като за начало е нужно да си закупим домейн. Това става от съответната фирма, предлагаща тази услга. Това което трябва да направите при регистрацията, е да добавите 2 DNS сървъра, както и GLUE записите към тях.
Ако сме закупили домейна example.com, трябва да въведем и DNS сървърите, които ще обслужват този домейн заедно с техните IP адреси в административния панел за DNS на сайта, от който сме купили домейна. Например:
ns1.example.com 193.32.12.1От тук нататък трябва да имаме инсталирани DNS сървъри на тези IP адреси като те трябва да бъдат конфигурирани да обслужват домейна example.com (да са authoritative за example.com).
ns2.example.com 193.52.50.1
Примерни инсталация и конфигурация на тези сървъри ще бъде разгледано в третата част на тази поредица от статии за DNS.
Lame nameservers
Това са DNS сървъри, които са посочени за authoritative dns за даден домейн, но не са конфигурирани да отговарят на запитвания за този домейн. С други думи, те връщат отговор от типа - refused. Ето пример за lame nameserver:
Кои са dns сървърите, обслужващи зоната cnsys.bg?
# host -t ns cnsys.bg
cnsys.bg name server ns.btc-net.bg.
cnsys.bg name server ns2.atlantis.bg.
cnsys.bg name server clio.cnsys.bg.
Нека попитаме за mx - запис към домейна cnsys.bg. Първо питаме ns.btc-net.bg.
# host -t mx cnsys.bg ns.btc-net.bg.
Using domain server:
Name: ns.btc-net.bg.
Address: 212.39.90.73#53
Aliases:
cnsys.bg mail is handled by 10 clio.cnsys.bg.
Да попитаме вторият DNS сървър (ns2.atlantis.bg) за същото:
# host -t mx cnsys.bg ns2.atlantis.bg.Както се вижда, въпреки, че ns2.atlantis.bg е в списъка с dns сървъри обслужващи cnsys.bg, при запитване към него за mx запис отговорът е REFUSED, тоест конфигурацията е неправилна, и ns2.atlantis.bg не отговаря на запитвания за зоната cnsys.bg, въреки, че фирурира в списъка като authoritative. В този случай този dns сървър се води lame за зоната cnsys.bg.
Using domain server:
Name: ns2.atlantis.bg.
Address: 193.108.24.4#53
Aliases:
Host cnsys.bg not found: 5(REFUSED)
Как да инсталираме и конфигурираме authoritative dns сървър ще разгледаме в следващата част на тази поредица статии.
Статията е публикувана в http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=450185369
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 сканирането не би ни свършило работа. Както следва:
Сканирането отне около един ден. Резултатът беше 24911 IP адреса на които има отворен 53ти порт. Трябва да се отбележи, че не всички от тези IP адреси имат инсталиран DNS софтуер. За това следващата стъпка е да сканираме за версията на DNS софтуера. Програмката която ползвам се казва fpdns (fingerprint dns) и я има на пакет в Debian Squeeze (apt-get install fpdns).
Fingerprint сканирането отне един weekend. Резултатите са както следва:
Както се вижда най-използваният DNS софтуер е ISC BIND. Другото което прави впечатление е големият брой DNS сървъри които изпълняват рекурсивни заявки (тоест можете да си ги сложите в настройките за DNS и да ги ползвате без проблем или с други думи казано - в повечето случаи default install).
Ето и какви са версиите на DNS софтуера при запитване за версия:
Върнатият отговор при запитване за версия не е гаранция за това дали софтуера е със сигурност този, тъй като тази стойност може да се променя от администратора (както се забелязва - 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.
Ако някои иска да погледне данните в неформатиран (и пълен) вид от това изследване нека ми пише коментар.
Оказа се малко трудно да се намерят в момента всичките български 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Бележка: tee програмката записва във файл и едновременно с това показва какво е записано и на stdout.
for a in `cat ip-dns-port-53.txt`;
do
fpdns -t 1 -f $a|tee -a dns-scan-oct-2012.txt
done
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.
Ако някои иска да погледне данните в неформатиран (и пълен) вид от това изследване нека ми пише коментар.
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 като този:
Машината буквално "увисва" за няколко минути. Оказа се че в crontab-a е сложен нов скрипт който изтрива някакви cache файлове.
Какво се оказа. Линукс ядрото кешира всичките дискови операции в паметта като когато се достигне определен процент от заетата RAM, дисковите операции се форсират да се запишат на хард диска. По подразниране в линукс ядрото при 40% от заетата рам се форсира записването им на хард диска, като записа става синхронно тоест всички останали процеси са блокирани за достъп към твърдия диск. От тук идва и проблема, машината е с 16 гигабайта RAM и 40% от 16gb не са никак малко. При достигането на 40% от паметта, форсираното записване продължава повече от 120 секунди (което е някакъв лимит за колко време може да отнеме тази операция) понеже диска не е толкова бърз за да запише всичко се изплюва тази грешка и като резултат машината е недостъпна известно време.
Процентното съотношение на може да се контролира през /etc/sysctl.conf:
или с команда:
Това указва на ядрото кешираните IO операции да са не повече от 7% от общата RAM.
[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
(същото като)
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):
При Windows това се намира в Control Panel -> Network -> Local Area Connection -> Properties -> TCP/IP Settings. Можем да видим текущите DNS настройки и с командата: ipconfig /all
В горепосочения пример конфигурирания DNS cache - сървър е 10.1.42.1.
Операционните системи имат и локален файл, в който може статично да се описват dns - адреси да отговарят на дадени IP - адреси. Файлът се нарича "hosts" и се намира, както следва:
При UNIX - подобните операционни системи това е:
Както се вижда от тази конфигурация реда е:
1. търси се във файла /etc/hosts
2. ако там няма запис питаме конфигурирания DNS сървър
В коментарите има пример (hosts: dns, files, nis), при който първо се пита DNS - сървъра, и ако там няма такъв запис, се гледа в /etc/hosts файла, и ако там също няма запис, се изпраща запитване към конфигурираня NIS - сървър.
При Windows не съм сигурен, дали може да се променя реда на запитванията, но механизмът е следния:
1. Търси се в hosts - файла дали има запис. Той се намира в C:\Windows\System32\drivers\etc.
2. Пита се локалната услуга dns cache (DNS client, ако е стартиран). В случая това е stub resolver, защото сам по себе си той не може да извършва recursive заявки. Поддържа локално "кеширане".
Както се вижда, услугата локален 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. Съдържанието на един такъв файл е:
Този файл е нужен на 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 отговаря:
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)
* Нека попитаме отново кой е SOA за .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)
* Тук вече има glue - записи за [ns1,ns2,ns3,ns4].google.com. Питаме ns1.google.com отново SOA.
* Тъй като вече знаем кого със сигурност да питаме за google.bg, подаваме запитване: кой dns сървъри отговарят за google.bg?
* Питаме някой от тях за 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)
(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 и как да ги използваме
Следва продължение...
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.comdns cache сървър -> ок, кое е IP-то на един от тези сървъри, за да мога да го питам за www.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.
(същото като)
# host ns3.google.com.dns cache сървър -> питам 216.239.36.10 на кое IP отговаря www.gmail.com
ns3.google.com has address 216.239.36.10
(същото като)dns cache сървър -> www.gmail.com е псевдоним към googlemail.l.google.com, който има няколко IP адреса.
# 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 сървър -> отговор към 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Също така, UNIX има механизъм, по който да се указва реда на DNS - запитванията. Това се прави от файла /etc/nsswitch.conf
# $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
# 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Забележка: additional записите за GLUE - записи, които ще бъдат обяснени във втората част на тази статия.
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
* Нека попитаме отново кой е 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* В случая Start of Authority (SOA) записът не в същния домейн (.bg) а е в .com домейна, затова следващата стъпка е отново да се изпрати SOA - запитване този път до .com.
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
# dnsq soa .com k.root-servers.net* Питаме някой от тези сървъри: кой отговаря за google.com?
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
# 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От този отговор вече знаем къде със сигурност има authoritative - информация за домейна google.com. SOA - записът на даден домейн е така нареченият "master dns", докато всички останали се водят slave. SOA записът съдържа и друга допълнителна информация за домейна като имейл за контакти (dns-admin@google.com) както сериен номер, TTL и т.н., на който ще обърнем внимание във втора част на тази статия.
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
* Тъй като вече знаем кого със сигурност да питаме за 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 и как да ги използваме
Следва продължение...
Subscribe to:
Posts (Atom)