Проблем с F1 2012 и Logitech Driving Force GT Wheel

Наскоро си закупих ето това чудо Logitech Driving Force GT и естествено го тествах с демото на F1 2012. Оказва се, че първоначалните настройки са объркани и воланът е прекалено чувствителен и е много трудно да се играе. Поиграх си с настройките и успях да го докарам до положение в което реагира както очаквам.

Ето какво точно съм сменил:

В Logitech Profiler направих радиуса на волана да е заключен на 271 градуса.
В Logitech Profiler направих Centering wheel на 45%.

В настройките на F1 2012 промених следните неща:

Driving Controls -> Override Input Device Type -> Steering Wheel
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%)

Всичко останало на 0% (освен deadzone опциите които за всеки човек настройките са различни).
Много е важна опцията 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%

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 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", цъкаме на ок и всичко е наред.

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

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

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

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

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

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

# apt-get install bind9

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

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

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

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

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

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

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

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

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

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

};

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

# /etc/init.d/bind9 restart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


DNS протокол

Комуникацията на DNS преминава предимно по UDP протокола. Това гарантира възможно най-малко забавяне на отговорите. Правило е че UDP DNS заявките не трябва да бъдат по-големи от 512 байта, като се има впредвид, че и най-зле конфигурираните рутери ще пропускат UDP пакети с големина 512 байта. Когато отговорът надвиши тази големина, се преминава към TCP - протокола, а това е по-бавният вариант за обмяна на DNS информация.

Връзката между клиент и сървър се осъществява чрез запитване (query) и отговор (answer).
Запитването се състои от "запитване за запис на ресурс" или Resource Record query (или за по-кратко RR query) и съответно - отговор с данните за ресурса, ако е открит, или отрицателен отговор NXDOMAIN (non-existent domain).

пример

# host -v -t ns google.bg ns1.google.com
Trying "google.bg"
Using domain server:
Name: ns1.google.com
Address: 216.239.32.10#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63087
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;google.bg.                     IN      NS

;; ANSWER SECTION:
google.bg.              345600  IN      NS      ns1.google.com.
google.bg.              345600  IN      NS      ns2.google.com.
google.bg.              345600  IN      NS      ns4.google.com.
google.bg.              345600  IN      NS      ns3.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.         345600  IN      A       216.239.32.10
ns2.google.com.         345600  IN      A       216.239.34.10
ns4.google.com.         345600  IN      A       216.239.38.10
ns3.google.com.         345600  IN      A       216.239.36.10

Received 173 bytes from 216.239.32.10#53 in 48 ms

В случая правим запитване за RR - тип NS, тоест "кои DNS - сървъри обслужват зоната google.bg?". Отговорът както се вижда, са 4 DNS сървъра и техния TTL (time to live, или колко време да се "кешират" записите от DNS cache сървърите). Списъкът на типа запитвания за RR не е малък, но по-голямата част рядко се ползва. Ще изброя най-често използваните RR queries, придружени с кратко описание.

SOA - Start of authority или "достоверен източник", от където със сигурност ще разберем кой "master dns" обслужва дадения домейн.
NS - "кои DNS сървъри обслужват дадения домейн?"
A - най-често се използва за свързване на hostname към IP адрес. A записът www към домейна linux-bg.org отговаря на IP адрес 212.50.10.155 (www.linux-bg.org).
MX - "кои мейл сървъри обслужват пощата за дадения домейн?"
TXT - може да се използва за всичко, ако искате може да си напишете "This is my DNS" и при RR тип TXT ще получите точно това. Принципно се използва за SPF anti-spam записи.
CNAME - това е псевдоним към друг hostname, например www.google.bg е псевдоним (alias) към www.l.google.com.
PTR  - "на кой hostname отговаря дадения IP адрес?", или това е обратното на A запис.
AAAA - същото като A запис, но за IPv6 адреси.
ANY - всички записи, касаещи дадения домейн.

Топология на DNS

Структурата на DNS е йерархична, като в основата се намират сървърите от root hints файла. Те обслужват root домейна . (точка), както е видно и от следния пример:

# host -t soa . c.root-servers.net
Using domain server:
Name: c.root-servers.net
Address: 192.33.4.12#53
Aliases:

. has SOA record a.root-servers.net. nstld.verisign-grs.com. 2012091300 1800 900 604800 86400

Тези dns root сървъри са authoritative само за . домейна. За всички останали, те имат препратки, към които евентуално могат да знаят къде се намира SOA записът на даден домейн.

# dnsq soa .com a.root-servers.net
6 com:
509 bytes, 1+0+13+15 records, response, noerror
query: 6 com
authority: com 172800 NS a.gtld-servers.net
authority: com 172800 NS b.gtld-servers.net
authority: com 172800 NS c.gtld-servers.net
authority: com 172800 NS d.gtld-servers.net
authority: com 172800 NS e.gtld-servers.net
authority: com 172800 NS f.gtld-servers.net
authority: com 172800 NS g.gtld-servers.net
authority: com 172800 NS h.gtld-servers.net
authority: com 172800 NS i.gtld-servers.net
authority: com 172800 NS j.gtld-servers.net
authority: com 172800 NS k.gtld-servers.net
authority: com 172800 NS l.gtld-servers.net
authority: com 172800 NS m.gtld-servers.net
additional: a.gtld-servers.net 172800 A 192.5.6.30
additional: b.gtld-servers.net 172800 A 192.33.14.30
additional: c.gtld-servers.net 172800 A 192.26.92.30
additional: d.gtld-servers.net 172800 A 192.31.80.30
additional: e.gtld-servers.net 172800 A 192.12.94.30
additional: f.gtld-servers.net 172800 A 192.35.51.30
additional: g.gtld-servers.net 172800 A 192.42.93.30
additional: h.gtld-servers.net 172800 A 192.54.112.30
additional: i.gtld-servers.net 172800 A 192.43.172.30
additional: j.gtld-servers.net 172800 A 192.48.79.30
additional: k.gtld-servers.net 172800 A 192.52.178.30
additional: l.gtld-servers.net 172800 A 192.41.162.30
additional: m.gtld-servers.net 172800 A 192.55.83.30

Както е видно, за TLD има 13 сървъра, които са именувани по подобие на root сървърите, а те са [a-m].gtld-servers.net. 

Домейните от типа .com, .net, .org се наричат Top-level Domains (TLD), като специфичните домейни на държави като .bg, .de и т.н. се наричат Country Code Top-Level Domains (ccTLD).

GLUE записи

Когато authoritative DNS сървърите на дадена зона (example.com) са в самата зона (ns1.example.com, ns2.example.com,...), се получава проблем с откриването на IP адресите им.
За това е нужно, при регистрацията на домейн, да се зададат така наречените GLUE записи (допълнителен A запис), които са допълнителни записи с IP адресите на authoritative dns сървърите за даденния домейн, по следния начин:

ns1.example.com 123.123.123.1
ns2.example.com 123.222.123.2

GLUE - записите могат да се диагностицират чрез някои от достъпните по мрежата DNS  инструменти като http://www.webdnstools.com/dnstools/domain_check , или чрез програмките dnstrace, dnstracesort от пакета djbdns. Dnstrace започва от root сървърите и следва всички препратки за дадения домейн. Изходът на програмата е доста обемист, за това ще покажем само малка част от него:

# dnstrace ns google.com b.root-servers.net | dnstracesort > google.com.txt
# ls -la google.com.txt
-rw-r--r--  1 root  wheel  726714 Sep 14 10:54 google.com

забележка: DNS сървърите на google.com са от мрежата 216.239.3хх.ххх за това правя извадка само на тези IP-та от dnstrace.

# cat google.com.txt|grep 216.239.3

- [cut ] -

1 ns1.google.com 216.239.32.10    345600 A 216.239.32.10
1 ns2.google.com 216.239.32.10    345600 A 216.239.34.10
1 ns3.google.com 216.239.32.10    345600 A 216.239.36.10
1 ns4.google.com 216.239.38.10    345600 A 216.239.38.10
...
glue google.com 216.239.32.10    NS ns1.google.com
glue google.com 216.239.32.10    NS ns2.google.com
glue google.com 216.239.32.10    NS ns3.google.com
glue google.com 216.239.32.10    NS ns4.google.com
...
glue ns1.google.com 192.12.94.30     A 216.239.32.10
glue ns1.google.com 192.26.92.30     A 216.239.32.10
glue ns1.google.com 192.31.80.30     A 216.239.32.10
glue ns1.google.com 192.33.14.30     A 216.239.32.10
glue ns1.google.com 192.35.51.30     A 216.239.32.10
glue ns1.google.com 192.41.162.30    A 216.239.32.10
glue ns1.google.com 192.42.93.30     A 216.239.32.10
glue ns1.google.com 192.43.172.30    A 216.239.32.10
glue ns1.google.com 192.48.79.30     A 216.239.32.10
glue ns1.google.com 192.5.6.30       A 216.239.32.10
glue ns1.google.com 192.52.178.30    A 216.239.32.10
glue ns1.google.com 192.54.112.30    A 216.239.32.10
glue ns1.google.com 192.55.83.30     A 216.239.32.10
glue ns1.google.com 216.239.32.10    A 216.239.32.10
glue ns1.google.com 216.239.34.10    A 216.239.32.10
glue ns1.google.com 216.239.36.10    A 216.239.32.10
glue ns1.google.com 216.239.38.10    A 216.239.32.10
...
- [ cut ] -

Както се вижда този ред "glue ns1.google.com 192.12.94.30     A 216.239.32.10" dns сървърът 192.12.94.30 има допълнителен A (glue) запис за ns1.google.com който е 216.239.32.10. IP адреса 192.12.94.30 всъщност е един от global TLD сървърите:

# host 192.12.94.30
30.94.12.192.in-addr.arpa domain name pointer e.gtld-servers.net.

Повече информация за GLUE записите: http://tools.ietf.org/html/draft-koch-dns-glue-clarifications-04

Reverse DNS (PTR записи)

Това е така нареченият "обратен resolving", на кой hostname отговаря даденият IP адрес. Това на практика е един специален домейн, който се нарича in-addr.arpa.

# dnsq soa arpa f.root-servers.net
6 arpa:
508 bytes, 1+1+12+13 records, response, authoritative, noerror
query: 6 arpa
answer: arpa 86400 SOA a.root-servers.net nstld.verisign-grs.com 2012091400 1800 900 604800 86400
authority: arpa 518400 NS c.root-servers.net
authority: arpa 518400 NS d.root-servers.net
authority: arpa 518400 NS m.root-servers.net
authority: arpa 518400 NS i.root-servers.net
authority: arpa 518400 NS f.root-servers.net
authority: arpa 518400 NS l.root-servers.net
authority: arpa 518400 NS h.root-servers.net
authority: arpa 518400 NS k.root-servers.net
authority: arpa 518400 NS g.root-servers.net
authority: arpa 518400 NS b.root-servers.net
authority: arpa 518400 NS e.root-servers.net
authority: arpa 518400 NS a.root-servers.net
- [ cut ] -

За Top-Level домейна ARPA authritative dns сървъри са root dns сървърите

# dnsq soa in-addr.arpa f.root-servers.net
6 in-addr.arpa:
406 bytes, 1+0+6+12 records, response, noerror
query: 6 in-addr.arpa
authority: in-addr.arpa 172800 NS e.in-addr-servers.arpa
authority: in-addr.arpa 172800 NS c.in-addr-servers.arpa
authority: in-addr.arpa 172800 NS f.in-addr-servers.arpa
authority: in-addr.arpa 172800 NS b.in-addr-servers.arpa
authority: in-addr.arpa 172800 NS a.in-addr-servers.arpa
authority: in-addr.arpa 172800 NS d.in-addr-servers.arpa
additional: a.in-addr-servers.arpa 172800 A 199.212.0.73
additional: b.in-addr-servers.arpa 172800 A 199.253.183.183
additional: c.in-addr-servers.arpa 172800 A 196.216.169.10
additional: d.in-addr-servers.arpa 172800 A 200.10.60.53
additional: e.in-addr-servers.arpa 172800 A 203.119.86.101
additional: f.in-addr-servers.arpa 172800 A 193.0.9.1

За домейна in-addr.arpa dns сървърите са [a-f].in-addr.servers.arpa както и glue записите към тях.

# dnsq ns in-addr.arpa e.in-addr-servers.arpa
2 in-addr.arpa:
142 bytes, 1+6+0+0 records, response, authoritative, noerror
query: 2 in-addr.arpa
answer: in-addr.arpa 86400 NS d.in-addr-servers.arpa
answer: in-addr.arpa 86400 NS f.in-addr-servers.arpa
answer: in-addr.arpa 86400 NS a.in-addr-servers.arpa
answer: in-addr.arpa 86400 NS b.in-addr-servers.arpa
answer: in-addr.arpa 86400 NS e.in-addr-servers.arpa
answer: in-addr.arpa 86400 NS c.in-addr-servers.arpa

Тук вече получихме достоверна информация за in-addr.arpa dns сървърите.

Зоните в домейна in-addr.arpa се състоят от IP адресите на мрежите на които ще се правят PTR записи. Разликата е че мрежите се пишат в обратен ред. Пример за мрежата 216.239.32.0/24:

# dnsq soa 32.239.216.in-addr.arpa a.in-addr-servers.arpa
6 32.239.216.in-addr.arpa:
177 bytes, 1+0+8+0 records, response, noerror
query: 6 32.239.216.in-addr.arpa
authority: 216.in-addr.arpa 86400 NS u.arin.net
authority: 216.in-addr.arpa 86400 NS w.arin.net
authority: 216.in-addr.arpa 86400 NS t.arin.net
authority: 216.in-addr.arpa 86400 NS v.arin.net
authority: 216.in-addr.arpa 86400 NS z.arin.net
authority: 216.in-addr.arpa 86400 NS y.arin.net
authority: 216.in-addr.arpa 86400 NS r.arin.net
authority: 216.in-addr.arpa 86400 NS x.arin.net

# dnsq soa 32.239.216.in-addr.arpa u.arin.net
6 32.239.216.in-addr.arpa:
123 bytes, 1+0+4+0 records, response, noerror
query: 6 32.239.216.in-addr.arpa
authority: 32.239.216.in-addr.arpa 86400 NS ns4.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns2.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns3.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns1.google.com

# dnsq soa 32.239.216.in-addr.arpa ns1.google.com
6 32.239.216.in-addr.arpa:
233 bytes, 1+1+4+4 records, response, authoritative, weird rd, noerror
query: 6 32.239.216.in-addr.arpa
answer: 32.239.216.in-addr.arpa 86400 SOA ns1.google.com dns-admin.google.com 2012082800 21600 3600 1209600 10800
authority: 32.239.216.in-addr.arpa 86400 NS ns1.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns2.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns4.google.com
authority: 32.239.216.in-addr.arpa 86400 NS ns3.google.com
additional: ns1.google.com 345600 A 216.239.32.10
additional: ns2.google.com 345600 A 216.239.34.10
additional: ns4.google.com 345600 A 216.239.38.10
additional: ns3.google.com 345600 A 216.239.36.10

Както се вижда по-горе, зоната за мрежата 216.239.32.х (32.239.216.in-addr.arpa) е делегирана към ns1.google.com.

За повече информация можете да прочетете RFC2317 - Classless in-addr.arpa delegaion.

Authoritative DNS сървър

Authoritative DNS сървър е сървър, който е конфигуриран да отговаря на запитвания за дадени домейни. Той не изпълнява recursive dns запитвания, и е строго ограничен само до отговори за предварително конфигурираните домейни.

Тук трябва да се отбележи объркването и смесването на понятията "dns cache" и "authoritative dns сървър",  дължащо се на най-разпространата имплементация на dns сървър - BIND.
Добрите практики за сигурност показват, че authoritative dns и dns cache сървърите трябва да са отделни програми, стартирани като отделни процеси, слушащи на отделни IP адреси. При BIND, двата сървъра са в един процес. Чак от BIND 10 тези сървъри ще бъдат отделни процеси.

Ето пример за отговори:

питаме dns cache сървър (10.1.42.1) за два dns записа - www.google.com и www.linux-bg.org

# host www.google.com 10.1.42.1
Using domain server:
Name: 10.1.42.1
Address: 10.1.42.1#53
Aliases:

www.google.com is an alias for www.l.google.com.
www.l.google.com has address 173.194.35.144
www.l.google.com has address 173.194.35.148
www.l.google.com has address 173.194.35.147
www.l.google.com has address 173.194.35.145
www.l.google.com has address 173.194.35.146

# host www.linux-bg.org 10.1.42.1
Using domain server:
Name: 10.1.42.1
Address: 10.1.42.1#53
Aliases:

www.linux-bg.org has address 212.50.10.155

питаме authoritative dns сървър (в случая ns1.google.com за зоната google.com) за www.google.com и www.linux-bg.org.

# host www.google.com ns1.google.com
Using domain server:
Name: ns1.google.com
Address: 216.239.32.10#53
Aliases:

www.google.com is an alias for www.l.google.com.
www.l.google.com has address 173.194.35.148
www.l.google.com has address 173.194.35.147
www.l.google.com has address 173.194.35.145
www.l.google.com has address 173.194.35.144
www.l.google.com has address 173.194.35.146

# host www.linux-bg.org ns1.google.com
Using domain server:
Name: ns1.google.com
Address: 216.239.32.10#53
Aliases:

Host www.linux-bg.org not found: 5(REFUSED)

Видно е, че при второто запитване отговорът е REFUSED. Това показва, че ns1.google.com не изпълнява recursive запитвания и отговаря само за google.com зоната (както и за други зони за които е конфигуриран да е authoritative).

Препоръки за authoritative dns

Тъй като dns е много чувствителен от към бързината на достъп, има няколко изисквания, преди да си инсталираме authoritative dns сървър за обслужване на личен домейн.

* препоръчително е да имате 2 IP адреса от различни мрежи, свързани с различни доставчици;
* скоростта трябва да е гарантирана до известна степен в двете посоки;
* прекъсванията на интернета да бъдат възможно най-малки.


Ако не можете да осигурите тези изисквания, Ви препоръчвам да използвате за dns hosting сървърите на фирмата, от която сте закупили дадения домейн, освен ако не сте ентусиаст и искате да се научите.

Конфигурационният файл на един authoritative dns сървър се състои от отделни "зони", които на практика представляват списък с Resource Records за даден домейн. Всяка зона трябва да съдържа:

* SOA - запис - master.dns.domain.com, email.za.kontakti.domain.com, сериен номер, refresh, retry, expire, min TTL.
master dns - основен dns сървър.
email - емейл за контакти при проблеми с този домейн.
serial - сериен номер чрез който се разбира по данните на домейна има промени. Препоръчително да текущата дата на промените във формат: DDMMYYYYX, където X e брой промени за деня.
refresh -  след колко секунди slave dns сървъра ще се опита да обнови данните си от master dns.
retry - при проблем, след колко секунди slave dns сървъра ще се опита отново да опресни данните от master dns.
expire -  при проблем с обновлението, след колко секунди slave dns сървъра ще спре да отговаря на запитвания за дадения домейн, тъй като данните ще бъдат смятани за остарели.
* NS - запис - минимун един, от типа ns1.domain.com
* A - запис - A запис за ns1 към domain.com
ако домейна ще получава поща, е нужен и поне един:
* MX - запис - hostname, където ще се намира мейл сървърите обслужващи domain.com, например mail.domain.com. Може да имате повече от един mx запис, като приоритета им се указва чрез число, при което колкото е по-ниска стойността, е с по-голям приоритет. Пример:

# dnsq mx google.com ns1.google.com
15 google.com:
216 bytes, 1+5+0+5 records, response, authoritative, weird rd, noerror
query: 15 google.com
answer: google.com 600 MX 20 alt1.aspmx.l.google.com
answer: google.com 600 MX 10 aspmx.l.google.com
answer: google.com 600 MX 50 alt4.aspmx.l.google.com
answer: google.com 600 MX 30 alt2.aspmx.l.google.com
answer: google.com 600 MX 40 alt3.aspmx.l.google.com

Както се вижда от примера по-горе, с най-голям приоритет от тези мейл сървъри е aspmx.l.google.com, който е с най-ниска стойност (10), а с най-нисък приоритет е alt4.aspmx.l.google.com (50).

* A - запис - за mail.domain.com към кое IP сочи
ако домейна ще бъде достъпен през web сървър е нужен запис:
* A - запис - А запис за www към домейна domain.com, тоест на кое IP отговаря www.domain.com.
* TXT - препоръчително е да се използва за SPF запис, когато има конфигурирани MX записи (www.openspf.org).

* Празен A - запис - това не нужно, за да работи web сървъра (примерно www.domain.com), когато потребителите не пишат www.domain.com, а само domain.com

Пример за това как изглежда една стандартно конфигурирана зона:

Зона example.com ns1.example.com. hostmaster.example.com. 2012010601 3600 600 120960 3600 3600
NS запис ns1.example.com 3600
NS запис ns2.example.com 3600
MX запис mail1.example.com 10 86400
MX запис mail2.example.com 100 86400
А запис ns1.example.com 193.22.103.226 3600
А запис ns2.example.com 193.22.103.2 3600
А запис example.com 195.177.249.170 3600
А запис mail1.example.com 195.177.249.170 3600
А запис mail2.example.com 195.177.249.170 3600
А запис archive.example.com 195.177.249.170 3600
А запис blog.example.com 195.177.249.170 3600
А запис www.example.com 195.177.249.170 86400
TXT запис за SPF "v=spf1 mx a:mail1.example.com a:mail2.example.com -all"

За да имаме собствени DNS сървъри като за начало е нужно да си закупим домейн. Това става от съответната фирма, предлагаща тази услга. Това  което трябва да направите при регистрацията, е да добавите 2 DNS сървъра, както и GLUE записите към тях.
Ако сме закупили домейна example.com, трябва да въведем и DNS сървърите, които ще обслужват този домейн заедно с техните IP адреси в административния панел за DNS на сайта, от който сме купили домейна. Например:

ns1.example.com 193.32.12.1
ns2.example.com 193.52.50.1

От тук нататък трябва да имаме инсталирани DNS сървъри на тези IP адреси като те трябва да бъдат конфигурирани да обслужват домейна example.com (да са authoritative за example.com).
Примерни инсталация и конфигурация на тези сървъри ще бъде разгледано в третата част на тази поредица от статии за DNS.

Lame nameservers

Това са DNS сървъри, които са посочени за authoritative dns за даден домейн, но не са конфигурирани да отговарят на запитвания за този домейн. С други думи, те връщат отговор от типа - refused. Ето пример за lame nameserver:

Кои са dns сървърите, обслужващи зоната cnsys.bg?

# host -t ns cnsys.bg
cnsys.bg name server ns.btc-net.bg.
cnsys.bg name server ns2.atlantis.bg.
cnsys.bg name server clio.cnsys.bg.

Нека попитаме за mx - запис към домейна cnsys.bg. Първо питаме ns.btc-net.bg.

# host -t mx cnsys.bg ns.btc-net.bg.
Using domain server:
Name: ns.btc-net.bg.
Address: 212.39.90.73#53
Aliases:

cnsys.bg mail is handled by 10 clio.cnsys.bg.

Да попитаме вторият DNS сървър (ns2.atlantis.bg) за същото:

# host -t mx cnsys.bg ns2.atlantis.bg.
Using domain server:
Name: ns2.atlantis.bg.
Address: 193.108.24.4#53
Aliases:

Host cnsys.bg not found: 5(REFUSED)

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

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

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

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

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

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

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

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

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

#!/bin/bash
for a in `cat ip-dns-port-53.txt`;
do
fpdns -t 1 -f $a|tee -a dns-scan-oct-2012.txt
done

Бележка: tee програмката записва във файл и едновременно с това показва какво е записано и на stdout.

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

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

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

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

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

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

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

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

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

How to install djbdns in Debian Squeeze as deb package

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

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

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

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

You can choose another debian mirror if you like.

# apt-get update
# apt-get source djbdns

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

# apt-get install build-essential

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

# dpkg-buildpackage -uc -rfakeroot

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

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

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

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

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

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

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

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

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

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

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

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

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

vm.dirty_ratio = 7

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

sysctl vm.dirty_ratio=7

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