Dotaz: cache-only DNS - jede?

[Martas]

Zdravim, muj dotaz je v podstate trivialni, ale nikde se mi nedari nalezt odpoved. Jak poznam, ze cache-only DNS server opravdu kesuje? Pouzivam distribuci Slackware 10 a jako DNS jsem si nainstaloval BIND. Po precteni prislusne sekce v LDP jsem zjistil, ze konfigurace cache-only DNS na Slacku spociva v podstate v instalaci BINDu. resolv.conf jsam nastavil na nameserver 127.0.0.1. Po spusteni BINDu zaclo vse bezproblemu fungovat. Pak jsem ale chtel zjitit, jestli BIND opravdu kesuje a zda-li se stale nedotazuje korenovych name serveru, coz samozrejme nechci. V LDP jsem se docetl, ze kdyz pri pouziti programu nslookup dostanu odpoved NON-AUTHORITATIVE ANSWER cache jede. Jenze me to tuhle odpoved hazi porad... Jak tedy zjitim jestli mi DNS kesuje? Diky moc

Odpovědi

[unchallenger]

Spusť tcpdump či ethereal a polož dvakrát tentýž dotaz. Pokud se bude ptát dalších serverů i podruhé, tak asi necacheuje, ale jen forwarduje...

[Petr]

Dikes testnu to. Spis jsem ale doufal, jestli neexistuje nejakej prikaz jak vypsat cache. Zrejme tedy asi ne..

[Petr]

Vypada to, ze to maka, ale v odchytavani paketu nejsem az zas tak zbehlej. Nemohl bys mi prosim jeste poradit jak pri pouziti tcpdump filtrovat pouze dns dotazy? Dikes

[unchallenger]

tcpdump -n udp port 53

by mohlo stačit. -n je tam kvůli tomu, aby si tcpdump negenroval DNS dotazy sám...

[Petr]

Tak nevim jestli je to to prave orechove. Z nejakeho me neznameho duvodu mi to odchytne pouze dotazy, ktere jsou smerovane ven. Kdyz dam treba lynx www.abclinuxu.cz a pozoruji co to udela, tak vidim, ze se to pta DNS serveru, ktery je nastaveny ve forwarders. Pri pokusu o dalsi spojeni uz se zadny dotaz ven neodchyti, ale neodchyti se ani zadnej dotaz na lo interface.. Zacinam z toho byt stale min a min moudrej..

[Michal Marek (twofish)]

Když všechno selže...

-i     Listen   on  interface.   If  unspecified,  tcpdump
       searches the system interface list for  the  lowest
       numbered,  configured up interface (excluding loop-
       back).  Ties are broken by  choosing  the  earliest
       match.

;-)

[Michal Marek (twofish)]

Navíc (nevím jestli je to případ zrovna lynxu) si ty výsledky může klidně cachovat i browser.

[Ara]

Pokud chcete vypsat vše co má nameserver v cache, tak na to lze použít příkaz

rndc -y rndckey dumpdb

ve /var/named se Vám uloží soubor named_dump.db

za -y musíte uvézt Váš rndc.key (viz. named.conf)

Jirka

[Antonín Kolísek]

Nebo také:

např. rndc -k /var/named/etc/rndc.key dumpdb (za -k dát cestu k rndc.key souboru)

[Petr]

Diky, presne neco takovyho jsem si predstavoval. Ted bohuzel nemam moznost to testnout, ale hned jak prijdu domu, tak to vyzkousim a dam vedet. Taky to zkusim nejak rozumnejs otestovat. Vcera to byla zbrklost a uz jsem u toho moc nepremejslel. Stejne je to zajimava ironie. BIND jsem rozchodil za par minut, ale uz druhej den zjistuju jestli spravne funguje...

[Petr]

Vitezstvi dosazeno....BIND mi opravdu kesuje. Pro uplnost tohoto threadu prikladam konfiguraky. BIND jsem pouzil z distribuce. Dosti mi pomohl tento odkaz http://langfeldt.net/DNS-HOWTO/BIND-9/DNS-HOWTO-3.html , clanek zde na abicku a v neposledni rade Vase reakce. Takze ted ty slibovane konfiguraky:

named.conf

options {
	directory "/var/named";
	/*
	 * If there is a firewall between you and nameservers you want
	 * to talk to, you might need to uncomment the query-source
	 * directive below.  Previous versions of BIND always asked
	 * questions using port 53, but BIND 8.1 uses an unprivileged
	 * port by default.
	 */
	auth-nxdomain no;
	// Server neposkytuje informace o nasi siti
	
	query-source address * port 53;
	// Pro komunikaci s jinou DNS pouzij port 53
	
	forward first;
	// Pokud neco nevi, pta se nejprve serveru
	// uvedenych ve forwarders
	
	forwarders {
	 10.109.151.1;
	 10.109.140.254;	 
	};
	
	cleaning-interval 259200;
	// Procistuje tabulku pomocnho serveru od zaznamu
	// na ktere se nikdo neptal (v sekundach)
};

key "rndc-key" {
      algorithm hmac-md5;
      secret "8CrFhDQFjoigc9KGDI7jJQ==";
};

controls {
      inet 127.0.0.1 port 953
              allow { 127.0.0.1; } keys { "rndc-key"; };
};


// 
// a caching only nameserver config
// 
zone "." IN {
	type hint;
	file "caching-example/named.ca";
};

zone "localhost" IN {
	type master;
	file "caching-example/localhost.zone";
	allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
	type master;
	file "caching-example/named.local";
	allow-update { none; };
};

named.local

$TTL	86400
@       IN      SOA     localhost. root.localhost.  (
                                      1997022700 ; Serial
                                      28800      ; Refresh
                                      14400      ; Retry
                                      3600000    ; Expire
                                      86400 )    ; Minimum
              IN      NS      localhost.

1       IN      PTR     localhost.

localhost.zone

$TTL	86400
$ORIGIN localhost.
@			1D IN SOA	@ root (
					42		; serial (d. adams)
					3H		; refresh
					15M		; retry
					1W		; expiry
					1D )		; minimum

			1D IN NS	@
			1D IN A		127.0.0.1

named.ca
Jedna se o seznam korenovych nameserveru. Jeho aktualizaci zajistime prikazem dig @a.root-servers.net > named.ca.new. Vznikne nam tak soubor named.ca.new, kterym nahradime stavajici named.ca. Tim je zajistena aktualizace.

rndc.conf

# Start of rndc.conf
key "rndc-key" {
	algorithm hmac-md5;
	secret "8CrFhDQFjoigc9KGDI7jJQ==";
};

options {
	default-key "rndc-key";
	default-server 127.0.0.1;
	default-port 953;
};
# End of rndc.conf

# Use with the following in named.conf, adjusting the allow list as needed:
# key "rndc-key" {
# 	algorithm hmac-md5;
# 	secret "8CrFhDQFjoigc9KGDI7jJQ==";
# };
# 
# controls {
# 	inet 127.0.0.1 port 953
# 		allow { 127.0.0.1; } keys { "rndc-key"; };
# };
# End of named.conf

Ten ziskame pomoci prikazu rndc-confgen resp. rndc-confgen > /etc/rndc.conf

Ted uz staci jen spustit BIND pomoci prikazu named a je hotovo. Pro uplnost jeste dodavam, ze v resolv.conf musi byt polozka nameserver 127.0.0.1, coz je zrejme.

To, ze server kesuje overime bud vypisem databaze viz odpoved Antonina Koliska (rndc -k /var/named/etc/rndc.key dumpdb (za -k dát cestu k rndc.key souboru)) a nebo muzeme pouzit prikaz dig a to nasledovne:

dig www.neco.cz
Jedna z polozek je Query time napr. Query time: 61 msec

Po opetovnem zadani dig www.neco.cz
dostavame Query time: 1 msec

To znamena ze druhy dotaz na www.neco.cz byl zoodpovezen z cache.
Timto vsem dekuji za pomoc a preji hodne stesti lidem co to teprve budou zkouset.

[rastos]

Fajn. Az na to, ze tam kde sa pise v konfigurakoch o 'rndc-key' najdes aj slovicko 'secret' - ktore znamena, ze by si ten kluc nemal zverejnovat

/usr/sbin/rndc-confgen -h

[Jirka V.]

Ahoj, mam na Debian Unstable rozjetej BIND9 a podle všeho to vypadá, že nakonfigurován jako cache-only. Jenže: Nevím proč, ale velikost onoho výpisu po rndc dumpdb se velice mění! Podle toho bych očekával, že se mění i obsah DNS cache. Nevím proč, ale když serfuju, tak si to nechá uložené DNS záznamy, ale velice rychle je zapomene. Rychle snamená řádově v minutách. Procházel jsem konfiguráky a nevím přesně který čas nastavit na "víc", ale u všeho mám default hodnoty a přesně sedí na ty hodnoty, co jsou občas vidět v conf na netu (mimojiné i v této diskuzi). Nevíte kde je zrada?

[petr_p]

Kazdy zaznam v zonovem souboru ma definovany TTL. Coz je prave doba, po kterou si ho cachovaci name server smi pamatovat. Ovykle byva radove ve dnech. Bohuzel, nekteri admini (zrovna tak jako webmastri) si mysli, ze vypnuti cache je ten nejlepsi zpusob, jak zajistit klientovi vzdy cerstve informace. Zkus se podivat na autoriatativni server, jaky ma TTL.