Neplechy v DNS a jak se jim vyhnout

Pracovní skupina IETF, zabývající se provozními záležitostmi DNS, nedávno vydala doporučení RFC 4697. Na základě statistik pocházejících z několika serverů z nejvyšších pater doménové hierarchie v něm shrnuje nejčastější nesmyslné dotazy, zbytečně zatěžující DNS. Podívejme se na ně a na to, co by se proti nim dalo dělat.

Dokument je orientován zejména na autory implementací DNS, konkrétně jeho klientské části zajišťující kladení dotazů. Některé prohřešky spadají čistě na vrub špatných implementací a tomu odpovídají i doporučení k jejich odstranění. Ovšem řada jiných problémů je způsobena chybnými či nešťastně zvolenými daty uloženými v DNS zónách. K jejich eliminaci může přispět každý správce DNS.

Problémy ovlivnitelné správci domén a serverů

Podívejme se nejprve na tuto zajímavější skupinu, kde může správce domény ledacos pokazit nebo napravit. Jako statisticky významné byly popsány následující problémy:

  • Opakované dotazy na nekompetentní servery. Jako lame server je označován server, který má být podle údajů v DNS autoritativním (je uveden v NS záznamu), ale sám není konfigurován jako autoritativní pro danou doménu. Jsou klienti, kteří se jej přesto znovu a znovu vyptávají, ačkoli nemají naději na autoritativní odpověď.

    Tato situace je zjevnou chybou správce serveru. V RFC 4697 se autorům DNS klientů doporučuje pamatovat si zjištěné nekompetentní servery a nedotazovat se jich. Základem by ovšem měla být kvalitní práce ze strany správců domén a udržování serverů ve stavu konzistentním s obsahem DNS.

  • Jestliže server pro doménu A se nachází v doméně B, ovšem server pro doménu B je v doméně C (a řetěz případně pokračuje), mají s tím někteří klienti problém. To je sice především problém implementace, ovšem správce domény může vyjít vstříc softwarovým nedokonalostem. Dokument proto doporučuje, aby vždy alespoň jeden z autoritativních serverů domény (řekněme kdesi.cz) ležel v doméně samotné (něco jako ns.kdesi.cz).
  • Zoufalé opakování dotazů klienta nacházejícího se za špatně konfigurovaným firewallem. Nejhorší situací je, pokud klient může klást dotazy, ale firewall blokuje přicházející odpovědi. Výsledkem bývá hustá a dlouhotrvající sekvence dotazů bez užitku. Používáte-li firewall, ověřte si, že místní rekurzivní DNS server jím projde oběma směry a že klienti řeší své DNS problémy prostřednictvím tohoto serveru.
  • Chybné NS záznamy v DNS. Oblíbenou chybou je zapomenout v zónovém souboru tečku za kompletním jménem serveru, což na jeho konec přidá aktuální doménu. Výsledkem bude neexistující jméno v NS záznamu. Klientovi se pochopitelně nepodaří získat o něm jakékoli informace a bude se opakovaně dotazovat na autoritativní servery domény. Je záhodno pečlivě hlídat a následně si vhodným dotazem ověřit, co je v doméně uvedeno o jejích serverech.
  • NS záznamy s nulovou životností vyžadují, aby se po nich klienti ptali stále znovu a znovu. Prostě to nedělejte. I pokud chystáte změny ve složení doménových serverů, nastavte NS záznamům kratší, ale s nenulovou životnost. Beztak jejich změna vyžaduje kooperaci se správcem rodičovské domény, takže nebude úplně na písknutí.
  • Rekurzivní dotazy směřované na servery, jež je odmítají řešit (někdy dokonce kořenové). Je třeba hlídat konfigurace koncových počítačů, aby měly nastaven pro řešení DNS vhodný, nejlépe místní rekurzivní DNS server. Jinak budou generovat nesmyslné dotazy a navíc bude DNS z uživatelského pohledu „fungovat špatně“. V RFC se doporučuje, aby si operační systém toto nastavení hlídal a při pokusu nasměrovat jej na server nepodporující rekurzivní dotazy uživatele upozornil.

Problémy způsobované implementacemi

Pro úplnost se ještě zmiňme o druhé skupině problémů, jejichž příčinou je samotná implementace DNS. S nimi sice mnoho nenaděláme, ale je dobré o nich mít alespoň přehled.

  • Agresivní vyptávání u rodičů. Pokud žádný z autoritativních serverů domény neodpovídá, některé implementace se obracejí na servery rodičovské domény a opakovaně se jich vyptávají na informace o serverech kýžené domény. To nemá valný smysl a navíc je to v některých situacích vyloženě chybné. Dá se tomu pochopitelně předejít volbou rozumně spolehlivých a dobře umístěných autoritativních serverů.
  • Aktivní obstarávání propojovacích záznamů. Propojovací záznamy (glue records) obsahují informaci o adresách strojů, jejichž jména jsou uvedena v odpovědi. Server by je měl přibalovat, pokud je má k dispozici. Ovšem některé servery jsou aktivní a snaží se tyto informace získat dotazováním v DNS i v případě, že je samy neznají. Někdy to vede k nezvykle vysoké frekvenci dotazů.
  • Nesmyslné aktualizace dynamického DNS. Někteří klienti, když neuspějí s odesláním aktualizace obsahu DNS (zpráva UPDATE), zkusí ji poslat serveru o patro výš v hierarchii a pak ještě výš, klidně až do kořene. Autoři dokumentu doporučují implementátorům, aby si klient nejprve pomocí DNS dotazů na záznamy typu SOA a NS zjistil, který server je zodpovědný za „jejich“ doménu a UPDATE pak poslal pouze a jedině tomuto serveru. Pokud neuspěje, klient nemůže aktualizovat DNS a neměl by se o to pokoušet jinde.
  • Dotazy na záznamy typu A, kde dotazovaným řetězcem je IPv4 adresa. Jejich příčinou je špatné používání různých programů. (Například když programu dig pro zjišťování informací z DNS zadáte jako parametr adresu, ale zapomenete na volbu -x. Pokud jste zvyklí na nslookup, stane se vám to celkem snadno.) Doporučené řešení je celkem zajímavé – vytvořit číselné domény odpovídající možným hodnotám prvního bajtu adresy a delegovat je na servery typu černá díra, které budou posílat negativní odpovědi.
  • Volba osloveného serveru z nabídky NS záznamů má nezanedbatelný vliv na chování DNS. Autoři doporučují zátěž rozumně rozkládat, sledovat doby odezvy, dávat přednost rychlým serverům, ale čas od času zkusit i ty pomalejší, zda se nezlepšily.

Jak si zkontrolovat doménu

Správce domény by měl hlídat řadu věcí a jeho případná chyba může mít nepříjemné důsledky. Existuje pochopitelně mnoho softwarových nástrojů pro kontrolu a správu DNS. Znalost programů jako je dig či nslookup by měla být naprostou samozřejmostí.

EBF16

Z těch složitějších, které se neomezují na prosté sdělení obsahu DNS, ale snaží se informace analyzovat a kontrolovat, je uživatelsky nejpohodlnější DNS Stuff, konkrétně jeho DNS Report. Stačí zadat jméno domény a během chvilky obdržíte obšírnou zprávu o řadě testovaných parametrů, včetně vysvětlení a barevného zvýraznění problematických mís­t.

Ale přes drobné mušky je DNS Stuff velmi užitečným a přitom pohodlným nástrojem. Kromě vlastního DNS se zajímá i o nejběžnější služby – elektronickou poštu a WWW. Zejména v elektronické poště se vrtá dost zevrubně – ověřuje existenci MX záznamů, ale i dostupnost serverů a jejich chování. Nemluvě o tom, že titulní stránka obsahuje celou řadu dalších nástrojů a udělátek. Vřele jej doporučuji vaší pozornosti, možná se o své doméně dozvíte netušené věci.

Anketa

Používáte nástroje jako DNS Stuff pro správu svých DNS?

6 názorů Vstoupit do diskuse
poslední názor přidán 24. 11. 2006 6:57

Školení web copywritingu

  •  
    Jak strukturovat text na webové stránce.
  • Tajemství atraktivního a úderného titulku.
  • Optimalizace webového textu pro vyhledávače.

Detailní informace o školení psaní pro web »