Administrace UNIXu. Leo Galamboš. Domain Name System. Co je potřeba pro. Name servery Konfigurace serveru BIND implementace Klientské utility

Podobné dokumenty

DNS. Počítačové sítě. 11. cvičení

Přístup k transportní vrstvě z vrstvy aplikační rozhraní služeb služby pro systémové aplikace, služby pro uživatelské aplikace DNS

DNS Domain Name System

Administrace Unixu (DNS)

DNS, DHCP DNS, Richard Biječek

Y36SPS Jmenné služby DHCP a DNS

Aplikační vrstva. Přístup k transportní vrstvě z vrstvy aplikační rozhraní služeb služby pro systémové aplikace, služby pro uživatelské aplikace HTTP

Počítačové sítě Aplikační vrstva Domain Name System (DNS)

Jmenné služby a adresace

Počítačové sítě II. 16. Domain Name System Miroslav Spousta,

Knot DNS workshop. CZ.NIC Labs Daniel Salzman / daniel.salzman@nic.cz Jan Kadlec / jan.kadlec@nic.cz

DNS,BIND - jednoduche zaklady Jiri Kubina jiri.kubina@osu.cz Ver. 1.0 unor 2006

Principy a správa DNS - cvičení

Správa a provoz serveru Knot DNS

Y36SPS: Domain name systém 1. Seznamte se s výchozími místy uložení konfiguračních souborů serveru bind9 v Debianu

X36PKO Jmenné služby Jan Kubr - X36PKO 1 4/2007

DHCP a DNS a jak se dají využít v domácí síti

Praktikum Směrování Linux

Instalační a uživatelská příručka aplikace PSImulator2 Obsah

Linux jako broadband router (2)

Překlad jmen, instalace AD. Šimon Suchomel

Site - Zapich. Varianta 1

Serverové systémy Microsoft Windows

Domain Name System (DNS)

Popis nastavení DNS serveru Subjektu

Serverové systémy Microsoft Windows

Další nástroje pro testování

Domain Name System. Hierarchie

Technologie počítačových sítí AFT NAT64/DNS64. Bc. Lumír Balhar (BAL344), Bc. Petr Kadlec (KAD0019)

Základní principy obrany sítě II. Michal Kostěnec CESNET, z. s. p. o.

Administrace OS UNIX

3. listopadu Uvedené dílo podléhá licenci Creative Commons Uved te autora 3.0 Česko.

ISA seminární práce. Zadání č. 4 Konfigurace www serveru ISP

Domain Name System (DNS)

Poslední aktualizace: 1. srpna 2011

15. DNS. Miroslav Spousta, Domain Name System. eklad ze snadno zapamatovatelných jmen na IP adresy. Historie

Základy IOS, Přepínače: Spanning Tree

Konfigurace síťových stanic

SOU Valašské Klobouky. VY_32_INOVACE_02_18 IKT DNS domény. Radomír Soural. III/2 Inovace a zkvalitnění výuky prostřednictvím ICT

Knot DNS workshop (aneb alternativy k BINDu) Jan Kadlec jan.kadlec@nic.cz

Zásobník protokolů TCP/IP

Serverové systémy Microsoft Windows

Principy a správa DNS - cvičení

Europen: IP anycast služba

Internet a zdroje. (ARP, routing) Mgr. Petr Jakubec. Katedra fyzikální chemie Univerzita Palackého v Olomouci Tř. 17. listopadu

Falšování DNS s RPZ i bez

NAT-PT/DNS64/AFT. Bc. Lumír Balhar (BAL344), Bc. Petr Kadlec (KAD0019)

Ondřej Caletka. 2. března 2014

Téma 2 - DNS a DHCP-řešení

DNS, jak ho (možná) neznáte

1. Směrovače směrového protokolu směrovací tabulku 1.1 TTL

9. Systém DNS. Počítačové sítě I. 1 (6) KST/IPS1. Studijní cíl. Představíme si problematiku struktury a tvorby doménových jmen.

Administrace Unixu a sítí

X36PKO Úvod Protokolová rodina TCP/IP

Přednáška 9. Síťové rozhraní. Úvod do Operačních Systémů Přednáška 9

Síť LAN. semestrální práce X32PRS Ondřej Caletka ČVUT V PRAZE, Fakulta Elektrotechnická

Semestrální projekt do předmětu SPS

Analýza protokolů rodiny TCP/IP, NAT

Správa linuxového serveru: DNS a DHCP server dnsmasq

- jedinečná adresa síťové karty: 48bit 6 polí - hexadecimální tvar 00-B0-D0-86-BB-F7

Nová cesta ip. Stará cesta ifconfig, route. Network address translation NAT

Počítačové sítě Systém doménových jmen a centralizované přidělování IP adres. Leoš Boháč Jan Kubr

Uživatelský modul. Modem Bonding

ANALÝZA TCP/IP 2 ANALÝZA PROTOKOLŮ DHCP, ARP, ICMP A DNS

Měřicí přístroje pro testování metalických vedení

L i n u x j a k o r o u t e r, f i r e w a l l, D H C P s e r v e r, p r o x y a D N S c a c h e, 2. č á s t

Počítačové sítě. Jan Outrata KATEDRA INFORMATIKY UNIVERZITA PALACKÉHO V OLOMOUCI. přednášky

Alcatel-Lucent VitalQIP DNS/DHCP & IP Management Software

Počítačové sítě I LS 2004/2005 Návrh a konstrukce sítě zadání

Registrační číslo projektu: CZ.1.07/1.5.00/ Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Útok na DNS pomocí IP fragmentů

Abychom se v IPv6 adresách lépe orientovali, rozdělíme si je dle způsobu adresování do několika skupin:

Registrační číslo projektu: CZ.1.07/1.5.00/ Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/ Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Hypertext Transfer Protocol (HTTP/1.1 RFC 2616) Počítačové sítě Pavel Šinták

Registrační číslo projektu: CZ.1.07/1.5.00/ Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

CAD pro. techniku prostředí (TZB) Počítačové sítě

VLSM Statické směrování

9. Sítě MS Windows. Distribuce Windows. Obchodní označení. Jednoduchý OS pro osobní počítače, pouze FAT, základní podpora peer to peer sítí,

PSK3-11. Instalace software a nastavení sítě. Instalace software

DNSSEC Pavel Tuček

Instalace Active Directory

Útoky na DNS. CZ.NIC Labs. Emanuel Petr IT10, Praha

Zásobník protokolů TCP/IP

pozice výpočet hodnota součet je 255

BIRD Internet Routing Daemon

Střední odborná škola a Střední odborné učiliště, Hořovice

BEZTŘÍDNÍ SMĚROVÁNÍ, RIP V2 CLASSLESS ROUTING, RIP V2

Technologie počítačových sítí 10. přednáška

Semestrální projekt 2. část

5. Směrování v počítačových sítích a směrovací protokoly

SPARKLAN WX-7615A - návod k obsluze. Verze i4 Portfolio s.r.o.

Téma 3 - řešení s obrázky

Počítačové sítě 1 Přednáška č.10 Služby sítě

Administrace Unixu (Nastavení firewallu)

Administrace OS Windows

Systém doménových jmen. DNS Domain Name Systém, systém doménových jmen WINS Windows Internet Name Service

Knot DNS a DNSSEC. IT14 Workshop Jan Kadlec Daniel Salzman

Adresářové služby, DNS

Transkript:

2009

Příklad B 10.10.20.0/24 F 10.10.60.0/24 C D E 10.10.30.0/24 10.10.40.0/24 10.10.50.0/24 A 10.10.10.0/24 G 10.10.70.0/24

1 dynamické uvnitř anebo mezi autonomními sítěmi (systémy) RIPv2, IGRP, OSPF, BGP, EGP... zebra/quagga, gated, routed 2 statické

Směrovací tabulky lo 127.0.0.0/8 Stanice eth0 ostatní Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 195.113.18.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 195.113.19.222 0.0.0.0 UG 0 0 0 eth0 195.113.18.0/23 přímo dosažitelné na eth0 127.0.0.0/8 přímo dosažitelné na lo ostatní na defaultní směrovač 195.113.19.222 za eth0

Směrovací tabulky aktivních spojení $ /sbin/route -Cn Kernel IP routing cache Source Destination Gateway Flags Metric Ref Use Iface 74.125.87.101 172.315.48.50 172.315.48.50 l 0 0 2 lo 172.315.48.41 172.315.48.50 172.315.48.50 il 0 0 2 lo 172.315.48.50 172.315.48.41 172.315.48.41 0 0 0 eth1 127.0.0.1 127.0.0.1 127.0.0.1 l 0 0 13 lo 172.315.48.50 172.315.48.41 172.315.48.41 0 1 1 eth1 172.315.48.50 74.125.13.89 172.315.48.1 0 0 0 eth1 172.315.48.50 172.315.48.1 172.315.48.1 0 0 6 eth1 172.315.48.50 172.315.48.1 172.315.48.1 0 0 6 eth1 172.315.48.50 74.125.13.89 172.315.48.1 0 1 1 eth1 74.125.13.89 172.315.48.50 172.315.48.50 l 0 0 3 lo 172.315.48.50 74.125.87.101 172.315.48.1 0 1 1 eth1 127.0.0.1 127.0.0.1 127.0.0.1 l 0 0 6 lo 172.315.48.50 74.125.87.101 172.315.48.1 0 0 0 eth1 172.315.48.1 172.315.48.50 172.315.48.50 il 0 0 6 lo

Směrovací tabulky netstat(8) route(8) -r výpis směrovacích tabulek -n bez symbolických jmen show výpis směrovacích tabulek add přidání nové cesty do tabulky delete odstranění cesty z tabulky ifconfig(8) parametry na síťových adaptérech Inicializace Platformově závislé, provádějí startovací skripty. OpenBSD /etc/netstart /etc/mygate /etc/hostname.* Gentoo /etc/conf.d/net

Detekce špatně nastavených tabulek $ ping -A ns.cythres PING ns.cythres (172.****) 56(84) bytes of data. 64 bytes from ns.cythres (172.****): icmp_seq=1 ttl=255 time=0.202 ms 64 bytes from ns.cythres (172.****): icmp_seq=2 ttl=255 time=0.207 ms : : $ ping 172.16.255.1 sendto: Network is unreachable

Syslog démon starající se o nakládání s logy/zprávami zprávy jsou určené zdrojem (modul systému: kernel, user prg, mail. daemon, auth... ) a úrovní konfigurace /etc/syslog.conf určuje: komu bude zpráva doručena na konzoli do jakého souboru bude zpráva připsána na jaký stroj bude zpráva předána unsecure mód: syslog flags -u (remote accept) API: openlog(3) a syslog(3) novější software: metalog, syslog-ng,...

Selektory Zdroje zpráv auth, authpriv cron daemon kern lpr mail mark news syslog user uucp local0... local7 Úrovně zpráv emerg alert crit err warning notice info debug

Příklad!* *.notice;auth,authpriv,cron,ftp,kern.none /var/log/messages *.emerg * kern.debug;user.info;syslog.info root auth.info /var/log/authlog authpriv.debug /var/log/secure cron.info /var/cron/log daemon.info /var/log/daemon ftp.info /var/log/xferlog lpr.debug /var/log/lpd-errs mail.info /var/log/maillog *.notice;ftp,kern,lpr,mail,user.none @loghost:514!sudo *.* /var/log/sudo!!sudo

Syntax když je specifikována úroveň, logují se i úrovně nad ní některé verze nemusí mít kompletní podporu pro syntax a la OpenBSD (například IBM UNIXy) zkratka čárka není podporována značkované bloky (proces name/pid) mezi selekcí a akcí je jeden nebo více tabulátorů

Rotování logů Rotování logů zajišťuje další démon, například newsyslog(8) nebo logrotate. Rotování probíhá v několika krocích: 1 staré logy se přemístí na nové místo 2 touch-nou se soubory na původních umístěních 3 HUPne se syslogd, respektive se pošle správnému programu správný signál 4 zpracují se staré soubory (komprese) V OpenBSD je k dispozici newsyslog(8) spouštěný root-em v rámci jeho crontab-u každou celou hodinu.

/etc/newsyslog.conf # logfilename owner:group mode ngen size time [ZB] /var/cron/log root:wheel 600 3 10 * Z /var/log/authlog root:wheel 640 7 * 168 Z /var/log/daemon 640 5 30 * Z /var/log/lpd-errs 640 7 10 * Z /var/log/maillog 600 7 * 24 Z /var/log/messages 644 5 30 * Z /var/log/secure 600 7 * 168 Z /var/log/wtmp 644 7 * 168 ZB /var/log/xferlog 640 7 250 * Z /var/www/logs/access_log 644 7 250 * Z...>...> /var/run/httpd.pid SIGUSR1 /var/www/logs/error_log 644 7 250 * Z...>...> /var/run/httpd.pid SIGUSR1

jeden syslog box realizující logování pro více strojů syslog box bez možnosti síťového připojení (ssh) syslog box s paraniodní bezpečností bez dalších démonů zablokování některých API volání kernelu (změny směrování... )

Začátky V roce 1970 má ARPAnet pár strojů a jejich báze je v jednom souboru spravovaném na Network Information Center ve Stanford Research Institute. Do centrály posílají lokální správci změny a stahují si aktuální verzi báze. S růstem sítě a plným přechodem na TCP/IP byl tento způsob práce neudržitelný. Paul Mockapetris byl pověřen vytvořením distribuovaného systému RFC 882 883 (1984) RFC 1034 1035 (současné)

Zivot bez DNS: /etc/hosts # # Table of IP addresses and hostnames # 127.0.0.1 localhost 172.16.12.1 logger.firma.cz loghost 172.16.1.2 oracle.firma.com ora

cz cuni lf mff pedf www cs

cz cuni lf mff pedf A 195.113.36.2 www cs A 195.113.20.12 CNAME

cz cuni lf mff pedf A 195.113.36.2 www cs A 195.113.20.12 CNAME cuni.cz domain

cz cuni delegování lf mff pedf A 195.113.36.2 www cs A 195.113.20.12 CNAME

cz cuni delegování zone lf mff pedf A 195.113.36.2 www cs A 195.113.20.12 CNAME

Doménová jména zapisují se od nejvíce po nejméně významnou část (od hostname k top-level) FQDN (fully qualified domain name) končí doménou nejvyšší úrovně, například www.hq.firma.com. relativní jméno - systém k němu připojí defaultní doménové jméno, například www.hq na většině systémů se ke jménu s tečkou již nepřipojuje defaultní doménové jméno

Zóny pro musí existovat alespoň jeden autoritativní DNS většinou se požadují alespoň dva AADNS: plně postačuje, když podporuje nerekursivní mód

Dotazy do DNS nerekursivní (iterativní) mód vrací jen známou informaci nebo hint rekursivní mód následuje hinty a celý dotaz se dořeší

primár (master) čte data o zóně z konfiguračního souboru sekundár (slave) čte data při svém startu z primáru a pak v určitých intervalech keš dotazuje se AADNS serveru a odpovědi kešuje proxy (forwarder) všechny neresolvované dotazy posílá na jiný DNS server a kešuje odpovědi Primár i sekundár jsou rovnocennými AADNS, liší se jen zdrojem svých informací... viz následující schéma...

TSIG Vzdálený admin Master AXFR IXFR Slave DNSSEC Remote caching Resolver Proxy High Speed Disk Lokální disk Dumb

Konfigurace DNS (systém) 1 režim práce DNS /var/named/etc/named.conf 2 soubory se zónami (AADNS) 1 /var/named/master/* /var/named/slave/* /var/named/standard/*: root hint, loopback, localhost 3 BIND často běží v chroot-u a syslogd(8) mu dává do ohrádky rouru dev/log OpenBSD: nastavte named flags a restartujte nebo jen restartujte syslogd se správnými parametry 1 OpenBSD rozložení

Konfigurace BIND8/9 primár (master) zone "example.com" IN { type master; file "master/example.com"; }; odpovědi mají AA bit existuje primary master NS v SOA (význam pro dynamické updaty) nemá souvislost s primary/secondary v MS-Windows

Konfigurace BIND8/9 sekundár (slave) zone "example.com" IN { type slave; file "slave/example.com"; masters { 192.168.300.2; }; }; stahuje z masters aktuální stav zóny (expiry v SOA) nikdy nepoužívá zastaralá data file je nepovinný atribut, de-facto zrychluje restarty BINDu

Konfigurace BIND8/9 keš options { directory "/var/named"; version "ouha"; recursion yes; }; // cokoliv zone "." IN { type hint; file "root.servers"; }; RR z primáru/sekundáru zóny vrací s AA bitem, z keše ne keš musí mít povolenou rekursi (je defaultně), to implikuje hint sekci keš je pouze v paměti, neukládá se na disk keš zatěžuje samotný server, nehodí se na 1000q/sec

Konfigurace BIND8/9 proxy fallback forwarder

Konfigurace BIND8/9 proxy options { // globálně directory "/var/named"; version "ouha"; forwarders {192.168.300.1; 192.168.300.2;}; forward only; }; zone "example.com" IN { // per domain type forward; forwarders {192.168.300.1; 192.168.300.2;}; }; cíl by měl podporovat rekurzivitu

Konfigurace BIND8/9 proxy options { forwarders {12.266.48.32; }; forward only; }; Server nadále spoléhá na vlastní autoritativní záznamy, ale pak již výhradně na forwarder (direktiva forward-only). Otázka K čemu mít forwarder tohoto typu? Proč to nenapsat přímo do resolv.conf(5)?

Ryze autoritativní DNS server Definice odpovědi mají výhradně AA (server je tedy master/slave) nekešuje options { directory "/var/named"; version "ouha"; recursion no; allow-transfer {"none";}; // v zóně pak allow-transfer pro sekundáry }; Využití zvýšení výkonu veřejný DNS server v rozděleném DNS systému (soukromé/dmz/veřejné)

Konfigurace BIND8/9 komplex options { directory "/var/named"; listen-on-v6 { none; }; listen-on { 127.0.0.1; }; }; zone "." IN { type hint; file "standard/root.hint"; }; zone "cuni.cz" IN { type master; file "master/cuni.cz"; allow-transfer { 195.113.0.2; } allow-update { none; }; notify no; }; zone "egothor.org" IN { type slave; file "slave/egothor.org"; masters { 134.36.80.123; } allow-update { none; }; };

Konfigurace DNS (zóny) $TTL 172800 ; 2 dny @ IN SOA ns.localhost. root.localhost. ( 2002081601 ; Serial YYYYMMDDVV 28800 ; Refresh 14400 ; Update retry 604800 ; Expire - 1 week 86400 ) ; Minimum IN NS ns IN MX 10 mail.localhost. localhost. IN A 127.0.0.1 ns IN A 127.0.0.1 mail IN A 127.0.0.1

DNS záznamy (RR) SOA start-of-authority signalizuje autoritu nad danou zónou NS name-server v dané zóně MX mail-exchanger v dané zóně A name-to-address mapování PTR address-to-name mapování CNAME canonical name (alias)

SOA - časovače Refresh sekundáry v tomto intervalu sledují změny na primáru Retry za jak dlouho zkouší sekundár kontaktovat primár, který neodpovídá Expire doba vedoucí k nezplatnění záznamů (nadále nejsou autoritativní) MinTTL mělo několik rozdílných významů 1 minimální TTL všech RR (odmítnuto praxí) 2 default TTL pro RR bez TTL (vhodné jen pro primáry) 3 TTL negativních odpovědí ( pozitivní : direktiva TTL) Doporučené nastavení kořenové servery 8h-2h-30d-4d běžné servery 8h-2h-7d-1d

Konfigurace DNS (zóny) $TTL 2d $ORIGIN lg.com. @ IN SOA ns1.lg.com. hostmaster.lg.com. ( 2006010100 ; Serial 3h ; Refresh 15M ; Retry 3W12h ; Expiry 2h20M ; Minimum ) IN NS ns1 ; lg.com. IN NS ns1.lg.com. IN NS ns2 ; klasické Ačko ns1 IN A 192.168.300.3 ns2 IN A 192.168.300.4

Konfigurace DNS (zóny) $TTL 2d $ORIGIN lg.com. @ IN SOA ns1.cp.com. hostmaster.lg.com. ( 2006010100 ; Serial 3h ; Refresh 15M ; Retry 3W12h ; Expiry 2h20M ; Minimum ) IN NS ns1.cp.com. IN NS ns2.někde.cz. ; tohle není naše věc!! ;ns1.cp.com. IN A 192.168.300.3 ;ns2.někde.cz. IN A 192.168.300.4

Konfigurace DNS (zóny) $TTL 2d $ORIGIN lg.com. @ IN SOA ns1.lg.com. hostmaster.lg.com. ( 2006010100 ; Serial 3h ; Refresh 15M ; Retry 3W12h ; Expiry 2h20M ; Minimum ) IN NS ns1 IN NS ns2 ns1 IN A 192.168.300.3 ns2 IN A 192.168.300.4 www IN A 192.168.300.5 out IN NS ns3.out.lg.com. IN NS ns2.lg.com. ns3.out IN A 192.168.300.6 ; GLUE!

Verze Nejpoužívanější verze BIND (Berkeley Internet Name Domain): 4.X starší verze: obtíže s multihomed 8.X/9.X multihomed, rozumná ACL pro přístup ke službám DNS DNS u jednotlivých záznamů uvádí čas 4.X pouze v sekundách. BIND9 už rozumí zkratkám za čísly: #s sekundy #m minuty #h hodiny #d dny #w týdny

Signály HUP znovunačtení báze záznamů INT uložení interní DB BINDu do named dump.db WINCH zapne/vypne logování všech dotazů přes syslog ABRT/ILL vypsání statistik do named.stats (ABRT v4, ILL v8) USR1/USR2 zapnutí a vypnutí debug režimu TERM uloží dynamické zóny do souborů (v8)

Konfigurace BIND počet transferů zón (dovnitř i ven) velikost datových bloků velikost zásobníku počet otevřených souborů interval čištení keše interval kontroly adaptérů (dynamické změny up/down, dhcp... ) interval tisku statistiky

nslookup Starší způsob pokládání dotazů do DNS serveru. nslookup -type=ns cuni.cz alfik.ms.mff.cuni.cz nslookup -type=a www.cuni.cz nslookup -norecursive -type=ns egothor.org alfik.ms.mff.cuni.cz

dig Kvalitnější diagnostika než nslookup(1). dig @192.168.4.98. dig @198.41.0.4. NS dig @alfik.ms.mff.cuni.cz ms.mff.cuni.cz axfr NS

1 A.B.C.D se převede na D.C.B.A.in-addr.arpa 2 v DNS se hledá PTR záznam pro D.C.B.A.in-addr.arpa Jak se deleguje? Kdyby všechny sítě byly A.B.C.D/N s N = 8, 16, 24, tak je možné delegovat na místě tečky. U adres typu A.B.C.D/27 si musíme pomáhat fintou.

Delegování podsítě v in-addr.arpa $ORIGIN 0.127.in-addr.arpa. 33 CNAME 33.32/27 34 CNAME 34.32/27 : 62 CNAME 62.32/27 32/27 NS ns.somewhere.out. Konzervativní syntax Lomítko není korektní znak v hostname, proto se nahrazuje nějakým povoleným znakem (typicky pomlčkou).

Efektivní transfery zóny options { // default transfer-format many-answers; }; server 12.266.48.32 { // MS-Windows transfer-format one-answer; } many-answers umí jen BIND9/8, pozdní čtyřka one-answer je třeba pro komunikaci se staršími BINDy (nebo i MS-Windows)

Dynamický update zone "egothor.org" { type master; file "pri/egothor.org"; allow-update { 127.0.0.1; }; }; Podrobnosti nsupdate(8)

NOTIFY k sekundárům zone "egothor.org" { type master; file "pri/egothor.org"; notify yes; also-notify 129.34.20.80; };

Příliš volné ACL Příklad: transfery zón z IP adres, které nejsou našimi sekundáry. Filosoficky je to správně (DNS záznamy jsou public), prakticky to může prozradit strukturu sítě. # dig @195.113.20.71 -t axfr ms.mff.cuni.cz ; <<>> DiG 9.2.5 <<>> @195.113.20.71 -t axfr ms.mff.cuni.cz ; (1 server found) ;; global options: printcmd ms.mff.cuni.cz. 28800 IN SOA ns.ms.mff.cuni.cz. hostmaster.ms.mff.cuni.cz. 2005101802 28800 14400 2419200 86400 ms.mff.cuni.cz. 28800 IN NS ns.ms.mff.cuni.cz. ms.mff.cuni.cz. 28800 IN NS sns.ms.mff.cuni.cz. ms.mff.cuni.cz. 28800 IN NS ns.kolej.mff.cuni.cz. ms.mff.cuni.cz. 28800 IN NS golias.ruk.cuni.cz. ms.mff.cuni.cz. 28800 IN MX 20 smtp1.ms.mff.cuni.cz. ms.mff.cuni.cz. 28800 IN MX 20 smtp2.ms.mff.cuni.cz. ms.mff.cuni.cz. 28800 IN MX 40 smtp1.kolej.mff.cuni.cz. : :

Kešování Kešují se nejen záznamy týkající se vlastního požadavku, ale i odkazy na autoritativní NS. většina NS kešuje pozitivní odpovědi (od autoritativních zdrojů) BIND 4.9/8/9 kešuje i negativní odpovědi opatrně s TTL záznamů TTL negativních odpovědí bývalo natvrdo 10 minut.

Glue Pozor Nevkládejte do zón chybné nebo duplicitní glue záznamy! glue je potřeba pouze když je NS v téže doméně a ještě není odpovídající A-záznam některé kompilace BIND hlásí chybné glue, ale poslední standard-branch nikoliv dávejte pozor sami

dot-bouda Položka neukončená tečkou dostává suffix $ORIGIN: mail MX 10 relay.isp.out. mail2 MX 10 relay2.isp.out znamená totéž co ($ORIGIN = mydomain.in) mail MX 10 relay.isp.out. mail2 MX 10 relay2.isp.out.mydomain.in.

Zameťte si vlastní smetí Na kořenové servery by neměly přicházet zbytečné žádosti, proto by každý nameserver měl sloužit jako primár pro: 0.in-addr.arpa 255.in-addr.arpa 0.0.127.in-addr.arpa Stačí pokrýt SOA a NS, u localhost revers by měl být ještě záznam: 1 PTR localhost. Není dobré připustit k localhost ještě lokální doménu, protože: localhost je všude v pořádku překlad 127.0.0.1 na localhost.mydomain a zpět vede často přes DNS, prostý localhost. se zpracuje přes lokální tabulky /etc/hosts

Kontrola 1 SOA a časovače 2 Glue je v pořádku 3 MX záznamy 4 sekundáry pracují

Problém: chybný SOA serial současný SOA serial je menší než správný stačí nastavit na primáru správný a inicializovat reload (SIGHUP) současný SOA serial je jen o málo větší než správný necháme to být současný SOA serial je o hodně větší než správný přetočíme SOA serial přes 31. bit 1 2014023101 2014023101 + 2 31 1 = 4161506748 2 reload primáru, sekundáry si musí stáhnout nové zóny 3 4161506748 2004022101

Nameservery alespoň 2 - ochrana proti výpadku alespoň jeden v každé (pod)síti - eliminace problémů se směrovačem poblíž větších strojů, ne nutně na nich - generují největší počet DNS dotazů homogenní O/S prostředí DNS - zjednodušuje správu i analýzu chyb bezpečnost: DNS server (a zejména primár) by měl být na dedikovaném stroji

Plánování kapacity Jak poznám, že je můj DNS server přetížený? velikost paměti procesu named nebezpečí swapování velké NS pomalu startují velké NS se pomalu dělí (např. při transferech zón) zátěž CPU - měla by být velmi malá (řádově jednotky procent) analýza: pohled do statistik BINDu 2 v4: ABRT signal v9: rndc stats parametry v named.conf, blok options statistics-interval: globální přehled o počtech dotazů, rekurzí, chyb... host-statistics: hledání původců zátěže 2 bindgraph postavený na RRDtool

Vyzkoušejte si zajistěte správné směrování mezi svými stanicemi spusťte BIND pozor na OpenBSD a jeho syslogd zaregistrujte si svoji doménu 1. řádu (u cvičícího) nastavte si primár s alespoň jedním A-záznamem ověřte si navzájem že tento záznam mohou resolvovat i ostatní

Vyzkoušejte si rozjeďte sekundár pro cizí na vašem NS delegujte část své domény vyzkoušejte si změny v zónách a jejich replikace na sekundáry vyzkoušejte si řešení chybného SOA serial přetočením přes 31. bit rozběhněte vlastní správu kořenové zóny (*)