Fake DNS with dnsmasq for testing purposes on Debian/Devuan

Install dnsmasq:

apt install dnsmasq

add to your /etc/resolv.conf the following:

nameserver 192.168.0.1

Edit /etc/dnsmasq.conf and add the following at the end of the file:

address=/real-domain-that-we-want-to-fake-for-testing.com/192.168.0.14
address=/horizon9.org/192.168.0.2
address=/google.com/192.168.0.14

The DNS request will ask first dnsmasq for a domain and if it is configured (for instance horizon9.org) it will return answer with 192.168.0.14 IP address. If domain is not found in dnsmasq configuration then it will pass dns request to real dns servers in /etc/resolv.conf file.

Now you can test your webserver by using this 192.168.0.1 for dns queries.

If you are accessing dnsmasq server from different network you will get REFUSED messages on the dns queries. If you want to fix that edit /etc/dnsmasq.conf and find the already commented line starting with 'interface=':

#interface=

and make it like this

interface=eth0

Replace eth0 with the right interface you want then restart dnsmasq.

Опасностите от DNSSEC протокола или как "събориха" www.spamhaus.org.

Нека да започнем с малко предистория... Краят на 90-те се появи първата атака от типа DDoS или Distributed Denial of Service, останала в историята като smurf атака. Накратко - чрез изпращането на ICMP пакети с подправен source IP адрес (с IP-то на жертвата) до broadcast адреси на големи мрежи се получаваше умножен в пъти ответен трафик към жертвата.

Този тип атаки биха се осъществили при наличието на три фактора:

• Използването на stateless протокол, при който не се очаква обратна връзка - например ICMP, UDP;
• Наличието на рутери по трасето до жертвата, позволяващи трафик с фалшив source IP адрес;
• Пожелателно е да има някакъв вид умножение на трафик, тоест жертвата да получи в пъти повече трафик, отколкото атакуващият изпраща.

Тъй като icmp smurf атаката отдавна лесно се филтрира, и е заложено на новите рутери по default да не отговарят на icmp broadcast запитвания, като че ли напоследък този тип атаки бяха позабравени.

Ако се запитаме, кой протокол отговаря на гореспоменатите изисквания, веднага изниква един основен протокол в интернет - DNS. DNS работи както по UDP, така и по TCP (повече може да прочетете за това в една моя статия: http://geroyblog.blogspot.com/2012/07/dns-1-resolvers-cache.html). При наличието по дизайн на DNS cache сървъри се вижда, че dns протоколът отговаря и на изискването да има умножител на трафик. В случаят това са DNS cache сървърите.
Какво имам в предвид?
Нека да направим едно рекурсивно запитване към някой dns cache сървър (например google public dns - 8.8.8.8).

Запитване за mx запис без да се използва TCP:

# dig mx +notcp google.com @8.8.8.8

При пуснат tcpdump се вижда,че изпратената заявка е 28 байта, а полученият отговор е 136 байта.

11:26:05.900877 PPPoE  [ses 0xbb] IP 192.168.1.76.64805 > 8.8.8.8.53:  26451+ MX? google.com. (28)
11:26:05.945839 PPPoE  [ses 0xbb] IP 8.8.8.8.53 > 192.168.1.76.64805:  26451 5/0/0 MX aspmx.l.google.com. 10, MX alt2.aspmx.l.google.com. 30, MX alt1.aspmx.l.google.com. 20, MX alt3.aspmx.l.google.com. 40, MX alt4.aspmx.l.google.com. 50 (136)

Приблизително 4.9 пъти умножение на трафика. Ако направим запитване ANY - трафика се увеличава до 546 байта, при което умножението се качва до 19.5 пъти.
Ако променим 192.168.1.76 адреса, който е нашият, сложим този на "жертвата" и изпратим 1 мегабайт заявки към публичния DNS съръвр на google, "жертвата" ще получи 19.5 мегабайта трафик. Умножение има, и то не малко, но като цяло не би трябвало да достигне ефекта на ICMP Smurf атаката.

Не толкова отдавна беше предложен, приет, променен, надграждан много пъти една нова надстройка на текущия DNS протокол, която според създателите им (главно isc.org) би решила проблемa със сигурността му.

Тъй като и аз се оплетох при четене на RFC (над 20 rfc - http://www.dnssec.net/rfc), които стандартизират DNSSEC и като цяло мнението ми е, че е прекалено усложнен протокол, ще го кажа на кратко.
Идеята на DNSSEC е за всеки DNS запис да имате подписан със сертификат кореспондиращ запис. Това би предотвратило DNS cache poisoning атакаите при положение, че протокола масово навлезе при всички операционни системи - както сървърни, така и клиентски софтуер. Ако направим запитване за MX - запис, наблюдаваме следният ефект:

# dig mx +notcp +dnssec isc.org @8.8.8.8

; <<>> DiG 9.4.1-P1 <<>> mx +notcp +dnssec isc.org @8.8.8.8
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27208
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;isc.org.                       IN      MX

;; ANSWER SECTION:
isc.org.                6419    IN      MX      10 mx.pao1.isc.org.
isc.org.                6419    IN      MX      10 mx.ams1.isc.org.
isc.org.                6419    IN      RRSIG   MX 5 2 7200 20130501233249 20130401233249 50012 isc.org. v0fb7TcHcwdjN2XZqSZfogavpS7T1ODK+rau7j1hiMJML2UdSPGpqiwf xyizY5yIcObHmF926xebjOsg1WFPJy85Fdhv/r2uD+Ibzo7QQL3QbQbp FqQlgpZUQHUFU/dpmZswRoZcMlRC4AhpkbsvYic4xbFV6O4z0hpgYUQ9 jgM=

;; Query time: 48 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Apr  2 11:58:14 2013
;; MSG SIZE  rcvd: 251

Нека направим запитване ANY записи за домейна isc.org:

# dig any +notcp +dnssec isc.org @8.8.8.8

; <<>> DiG 9.4.1-P1 <<>> any +notcp +dnssec isc.org @8.8.8.8
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55327
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;isc.org.                       IN      ANY

;; ANSWER SECTION:
isc.org.                5644    IN      SOA     ns-int.isc.org. hostmaster.isc.org. 2013040200 7200 3600 24796800 3600
isc.org.                5644    IN      RRSIG   SOA 5 2 7200 20130501233249 20130401233249 50012 isc.org. k/eRQT9zlZu+9HQr3WLl5ZwCAagwbD4cKkbYX7poLGzWFDWbgPC2ZN6J ZmNEQnz6dS4GYiuFX5NiEEyxHAVlpxUz6mdBM21TjHEH6OBqOsyOHMbA RMi9ijCN2coY2X28uhZ/cpcZccTPXQwEIN2PwqILVxbMq31+2bEXUZa5 DOY=
isc.org.                5644    IN      NS      sfba.sns-pb.isc.org.
isc.org.                5644    IN      NS      ams.sns-pb.isc.org.
isc.org.                5644    IN      NS      ns.isc.afilias-nst.info.
isc.org.                5644    IN      NS      ord.sns-pb.isc.org.
isc.org.                5644    IN      RRSIG   NS 5 2 7200 20130501233249 20130401233249 50012 isc.org. opQ2IchpAm1TXFiXBDxCeHwnFDBWzn41PCeoKRpLmLqSGyx867360zSc sBDXtE4Co4Z5IG7S4jUVZd8iXz0Y3CK3FZ/Yd1PD9c3T0Xwjku+HvF8j /h9LrlnFGi40i/4k1vE/5sTb+U4NEYKLowKb/gsoXRgVrgiASKRnAdsw vXg=
isc.org.                5644    IN      A       149.20.64.42
isc.org.                5644    IN      RRSIG   A 5 2 7200 20130501233249 20130401233249 50012 isc.org. Y9xN05o0BP+l2S6wTHlIPbLo8DuBVZOhZZ750IO6nS+3cHZ0XJEa3DzL 2O1gXQW8kCadF4yrLFT5XmBhfDbI94VBzBiYGvZ2vRcjPYtto4O2sxPw NQ+u6e/IcnHIIdueklz1dI8LgLn8+ZwtZ9+CUCRMhjwQtlejbxQEjLBe Gmo=
isc.org.                5644    IN      MX      10 mx.ams1.isc.org.
isc.org.                5644    IN      MX      10 mx.pao1.isc.org.
isc.org.                5644    IN      RRSIG   MX 5 2 7200 20130501233249 20130401233249 50012 isc.org. v0fb7TcHcwdjN2XZqSZfogavpS7T1ODK+rau7j1hiMJML2UdSPGpqiwf xyizY5yIcObHmF926xebjOsg1WFPJy85Fdhv/r2uD+Ibzo7QQL3QbQbp FqQlgpZUQHUFU/dpmZswRoZcMlRC4AhpkbsvYic4xbFV6O4z0hpgYUQ9 jgM=
isc.org.                5644    IN      TXT     "$Id: isc.org,v 1.1791 2013-03-27 00:02:30 ziegast Exp $"
isc.org.                5644    IN      TXT     "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org.                5644    IN      RRSIG   TXT 5 2 7200 20130501233249 20130401233249 50012 isc.org. qW2z10OjWeBpQ34YhbbluUFK5N8ELTxDXsa3dN1LI+/KEu9F/rzWh+KL ndoq2PsMeznJ6vTFVOSwm+602sIPb++cajgg1+fZAewNAWALJpEYLpYp TgIwbwZo7NoyGo1EUmMjqslFP+2uOgylIl8MHv/+XzbNivBZBNG0n4eQ Rb8=
isc.org.                5644    IN      AAAA    2001:4f8:0:2::d
isc.org.                5644    IN      RRSIG   AAAA 5 2 7200 20130501233249 20130401233249 50012 isc.org. Vj/4QQYtDNPw8oNU3H7lXSIKsQQLSOQiyTq1oYgbCPp4sWcx8RMyW64e 962azK7av5/NqE0c4WSQ2NXN/rBL17U7iwdeFkVO8ZVQSNGp7Kanah8T LCzhpNqcV0Op2PIor1JgcuNXiYLp3b5H0KpAI+Ibue3wzfsr48LYs0D2 7ik=
isc.org.                5644    IN      NAPTR   20 0 "S" "SIP+D2U" "" _sip._udp.isc.org.
isc.org.                5644    IN      RRSIG   NAPTR 5 2 7200 20130501233249 20130401233249 50012 isc.org. pXwjHqeueJk64dm4FJKz7JuwBjaa2CK3zJ4sODtnnsj7yeesTHckfnHk O+DJUVlgXf/GbxQ0tQ1y+qZXjmHKmsjp+oapsmebC9T6pZZwy3EHznQW KLDhhcnbLztyXWMS8o0cDm1uk35YhGvfhLpgMV2grfVaX0WU8VZTLLjq HBI=
isc.org.                2044    IN      NSEC    _adsp._domainkey.isc.org. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY SPF
isc.org.                2044    IN      RRSIG   NSEC 5 2 3600 20130501233249 20130401233249 50012 isc.org. fg3o/hFWeDIoFMo/pyKRGAz+LiE5f4HTJq6YvunBP/UpRenEFxZhVBxa tTn0v5ZeNq1XzLTm1JWl0yKUVmYwaHDnrH86j35iK+GnJ42UyQo0iv5r PHd6rakaPmMfq+6TK9FP1kUjJDgH/syYDRbSHbaynIBTR2zhpB8Y45xM Xa0=
isc.org.                5644    IN      DNSKEY  256 3 5 BQEAAAABwuHz9Cem0BJ0JQTO7C/a3McR6hMaufljs1dfG/inaJpYv7vH XTrAOm/MeKp+/x6eT4QLru0KoZkvZJnqTI8JyaFTw2OM/ItBfh/hL2lm Cft2O7n3MfeqYtvjPnY7dWghYW4sVfH7VVEGm958o9nfi79532Qeklxh x8pXWdeAaRU=
isc.org.                5644    IN      DNSKEY  257 3 5 BEAAAAOhHQDBrhQbtphgq2wQUpEQ5t4DtUHxoMVFu2hWLDMvoOMRXjGr hhCeFvAZih7yJHf8ZGfW6hd38hXG/xylYCO6Krpbdojwx8YMXLA5/kA+ u50WIL8ZR1R6KTbsYVMf/Qx5RiNbPClw+vT+U8eXEJmO20jIS1ULgqy3 47cBB1zMnnz/4LJpA0da9CbKj3A254T515sNIMcwsB8/2+2E63/zZrQz Bkj0BrN/9Bexjpiks3jRhZatEsXn3dTy47R09Uix5WcJt+xzqZ7+ysyL KOOedS39Z7SDmsn2eA0FKtQpwA6LXeG2w+jxmw3oA8lVUgEf/rzeC/bB yBNsO70aEFTd
isc.org.                5644    IN      RRSIG   DNSKEY 5 2 7200 20130501230129 20130401230129 12892 isc.org. UFxebBneKnZHasXdUtdD6LsSbso2twRVuVOLuG6sMdfkV2io52GASy/a xIHHAJTOZYHOGyfqCrEKDkTJ3V6e0i9g52B5dy8IsAZY5IaGK4OmcCWr utkqzzBofeLkWP0UqNMc7xZsi6zD4CPqqi1sxT1sb7/fimImTTBJnr44 hcES7tVDttq9Nd0/wc+sSyFo9KIkhPNQgIc/t2SZ0jGJqJOiOnUI3SkH qVAkn+a0Km1cbkqd19JxMEPc+KP1ke4InCQPD+yHS/wWsjeJ2Ajh97vp +1HzivRA9rTRr20P3HrolyVzOPvV8r4n6LXmJDOHRfAnwzq+vnWqNPlE sLO6pQ==
isc.org.                5644    IN      RRSIG   DNSKEY 5 2 7200 20130501230129 20130401230129 50012 isc.org. vxFVIb9MIY4AnMTiADKkAtFo0nwgNh4B2UTSCDF7m5q3S8iJGTlfO3EK PK0ilpinqnHXFWx+k3UiR8eRf7xMPBKONjNA8GdcAZ7XgdPgi2Ri0yOs DXApZLKgByIkc5B976UKJ5wRFR/eGs5Loqby+j6HHpeNRS0v5N2rfbUI 3kU=
isc.org.                5644    IN      SPF     "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org.                5644    IN      RRSIG   SPF 5 2 7200 20130501233249 20130401233249 50012 isc.org. ZBxS3Pg0D3apDPAbIUcRVTBkIaScqYyWt2jUkeWbSZ4FrEpY4V8ZA2VN vsw/uu5WcAnxu42xOjLqGi0tLbpbcfKu7NnzijgzJcxGaBw3iIJrK9lS htqMysY1F14hn4r3NXzfN9hWps0v7IKPAbnKQHKtcThDjF7hE7S7EbLU gy4=

;; Query time: 48 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Apr  2 11:54:43 2013
;; MSG SIZE  rcvd: 3064

Тук се вижда, че при заявка от 36 байта се получава отговор от 3064 или 85.1 пъти повече трафик! Сега ако сменим source IP адреса на пакета с този на жертвата и това бъде направено от ботнет от 50000 зомбирани компютри, досещате ли се какво се получава?

Като цяло, изводът е, че DNSSEC протокола по дизайн е великолепен умножител на трафик. Наскоро проверявах, и се оказа, че всички основни домейни като .com, .net, .org, .info и т.н., както и cc-домейните (country code) като .bg, .ru, .se и т.н. са подписани и поддържат DNSSEC.

# dig any +dnssec com @8.8.8.8

; <<>> DiG 9.4.1-P1 <<>> any +dnssec com @8.8.8.8
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55969
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;com.                           IN      ANY

;; ANSWER SECTION:
com.                    899     IN      SOA     a.gtld-servers.net. nstld.verisign-grs.com. 1364891984 1800 900 604800 86400
com.                    899     IN      RRSIG   SOA 8 1 900 20130409083944 20130402072944 23975 com. ifejuy4CNjIISV4kpWe1jjrwM03nluADb6K43W4px4UWPj0JI8bQ61oN KEs1708MkGIbH9hLehTTEwKEZ0sKj91LXUyiWzIPF/oCjWkX+IeZYCTM tAM1euj+hOiaNiPVtQBChcgaQ0CiJM+DFxrofs/uk0Xcytvxw0MoJwVp DIY=
com.                    21599   IN      NS      j.gtld-servers.net.
com.                    21599   IN      NS      g.gtld-servers.net.
com.                    21599   IN      NS      i.gtld-servers.net.
com.                    21599   IN      NS      k.gtld-servers.net.
com.                    21599   IN      NS      l.gtld-servers.net.
com.                    21599   IN      NS      d.gtld-servers.net.
com.                    21599   IN      NS      c.gtld-servers.net.
com.                    21599   IN      NS      m.gtld-servers.net.
com.                    21599   IN      NS      a.gtld-servers.net.
com.                    21599   IN      NS      h.gtld-servers.net.
com.                    21599   IN      NS      f.gtld-servers.net.
com.                    21599   IN      NS      e.gtld-servers.net.
com.                    21599   IN      NS      b.gtld-servers.net.
com.                    21599   IN      RRSIG   NS 8 1 172800 20130408041926 20130401030926 23975 com. AOYql4O2Zi6v013LUQXSo5K0VuzmfSZzb9Qk/UEAlziHoDUVDvhkceQu 8nseo8PKKJZwhmjhRde5mIuVFfTHIb6Hbv+29UnXhBVguD54I4J7lbRE BEMnJIjrJSs84W8uUgiUsZ4dKuMU0pTXcEonLIfQuUNfltuTifYOOPm+ Mk8=
com.                    21599   IN      DNSKEY  257 3 8 AQPDzldNmMvZFX4NcNJ0uEnKDg7tmv/F3MyQR0lpBmVcNcsIszxNFxsB fKNW9JYCYqpik8366LE7VbIcNRzfp2h9OO8HRl+H+E08zauK8k7evWEm u/6od+2boggPoiEfGNyvNPaSI7FOIroDsnw/taggzHRX1Z7SOiOiPWPN IwSUyWOZ79VmcQ1GLkC6NlYvG3HwYmynQv6oFwGv/KELSw7ZSdrbTQ0H XvZbqMUI7BaMskmvgm1G7oKZ1YiF7O9ioVNc0+7ASbqmZN7Z98EGU/Qh 2K/BgUe8Hs0XVcdPKrtyYnoQHd2ynKPcMMlTEih2/2HDHjRPJ2aywIpK Nnv4oPo/
com.                    21599   IN      DNSKEY  256 3 8 AQPcnY9mVa8t+3ab9SsbKjGh38DXxdCZsL0sCdUEzyj1b3nN9BFLolfM o7PyfRhOw29YvgwHq1wRB2nRWcOpuUZhgZNOxWqLoOu84KR7HtQmY1yZ uSkh9WA6mUDQT+i/7zpUVbtmZqNJm5SuQZFE0hn+N5CMxnXOLOsHJsn6 WvB1sQ==
com.                    21599   IN      RRSIG   DNSKEY 8 1 86400 20130408182533 20130401182033 30909 com. ohJvhu03H5M8PrkIcQDoozJjpokwWKKNfFqUXeU/pdvlY3X63IyJWXTZ 8qBp0lvhYWKHTpmGCCDBTC1X/DO+RXyYZAiQBeh8MVjyW4ZC8gz2/lS7 NTGRHmhCOFjsvYk6WNHy9vUqUomNuDDD9qIAS1HkYCmNGuo/2umLb+zU lsU8gcl6TyZIyepbeuTZQ4rkf+O53yJLngitaAoVCDI+hJE0OWZNAYg0 8AmJyuEZcnYlFUbuqR/SnL5FAfdo7XY9I5y5eJnWRT1YoFFcp6NTwZl8 KLlSLRhfLmIsP8mPGf3inJNnJ79MB6m6aArvo5aXWDhBM4HxbjkRZlO3 +cBu4g==
com.                    21599   IN      TYPE51  \# 5 0100000000
com.                    21599   IN      RRSIG   TYPE51 8 1 86400 20130408041926 20130401030926 23975 com. 2dfpD6RLPMGOM3HrPfvhSAPKb26oCeF0jX6Kd8xrCI3/YhiRJu80ilPA 5mQo9uduxAPHcn0E+G+Vu69PEmlTySbDgjZ6m4TA6LeCx1wEdX+6x7uc Z2ksNVqQBitZnjl+3Fb+ou2ekJjSk8mUjqbsHNtz/4u2nJ4zD1/bkDcc 0Jc=

;; Query time: 326 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Apr  2 12:06:02 2013
;; MSG SIZE  rcvd: 1528

Тук стигаме и до атаката срещу анти-спам листата spamhaus.org. Тъй като те предоставяха лист от спамерски IP адреси дистрибутирани чрез DNS, тази атака доведе до отказ на услуги на този анти-спам доставчик. Атаката е била осъществена чрез множество DNS open recursive resolvers и DNSSEC протокола. Ендовременно с това се забелязва увеличение на спам - мейлите, които се разпространяват по интернет. Това означава, че атака е координирана.

Какви са защитите срещу това?
В общи линии трябва да се ограничат UDP - заявките за DNS да са до 512 байта от самите рутери по пътя. За DNSSEC да се използва само TCP (което би забавило отговорите така че няма пълно щастие). Rate limit на заявките по UDP към 53-ти порт от firewalls или от самата имплементация на софтуера за DNS cache сървър. Филтриране на трафик от spoofed source IP адреси.

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

Как работи 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.

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