Názory k článku Jak přežít plánovanou údržbu DNS: v říjnu se mění klíče kořenové zóny
-
r2d2 (neregistrovaný)
Dobrý den, p. Špačku
náš autoritativní server vrací
ednsopt=echoed edns1opt=echoed
stručná verze Vašeho testeru ukazovala žlutý vykřičník, že nám to sice pojede OK, ale jsou tam drobné chyby
Je tomu tak ? Už ji nemohu najít.DNS je na Winsrv2012 R2.
Co mohu udělat víc, než poslední MS update ?celý výsledek
dns=ok edns=ok edns1=ok edns@512=ok ednsopt=echoed edns1opt=echoed do=ok ednsflags=ok docookie=ok edns512tcp=ok optlist=ok,subnet -
Petr Špaček (neregistrovaný)
Dobrý den, r2d2,
pravděpodobně se jedná o chybu v DNS software. Pokud máte již nainstalované všechny aktualizace od Microsoftu, tak jediný další krok je napsat na jejich podporu a upozornit je/požadovat opravu. Obvykle to funguje tak, že čím více zákazníků se jim ozve, tím větší prioritu konkrétní požadavek dostane.
Po provedení změn ve vašem DNS můžete test zopakovat pomocí formuláře na stránce https://dnsflagday.net/cs/ .
Děkuji za čas, který tomuto problému věnujete.
Petr Špaček -
Johanka (neregistrovaný)
@bez přezdívky, 21:38:
Donutil jste mě na zkušebních Win2012R2 spustit dcpromo a zkusit si vytvořit novou doménu. Samozřejmě přidání funkce DNS to nabízelo, ale nevyžadovalo. Tím je pro mě tahle diskuse uzavřená...https://ibb.co/jhf7Me
https://ibb.co/bLXXnK
https://ibb.co/dgxbEz -
Johanka (neregistrovaný)
@bez přezdívky, 23:05:
No ono si jde většinu záznamů připravit předem. V podstatě předem neznáte jen CNAME záznamy _msdcs.domena.com.<uuid-domenoveho-radice> a SRV záznamy _msdcs.domena._ldap._tcp.<uuid-domeny>.domains. A co si pamatuju (naposledy jsem to komplet dělala někdy před čtyřmi lety, takže si to už moc nepamatuju a můžu se mýlit), bez těhle záznamů DC naběhne, jen jsou nějaké chybové hlášky v logu. Po přihlášení se už příslušné UUID zjistí, doplní a můžete fungovat.A škrtbox pro instalaci DNS je ve výchozím stavu vybraný, takže pokud někdo jen kliká na "Next", DNS se mu nainstaluje.
Ono to i to řešení má svoje výhody i nevýhody. Výhody Win DNS jste popsal, nicméně jak už psal vedle "jouda", Bind nemá s replikací problém a společně s ISC DHCP (které zvládá i replikaci na záložní server) tam funguje i DDNS včetně ověřování validity záznamů. Windowsové řešení znamená buď že zapisovat do DNS mohou jen zařízení ověřená přes AD, takže třeba Apply, linuxové stroje nebo tiskárny mají smůlu - anebo že se autorizace zruší a pak může zapisovat kdokoli cokoli, což mi nepřijde dvakrát bezpečné. Tedy pokud vím, pokud jsem něco přehlédla, nechám se poučit. Bind+ISC DHCP tohle řeší a pokud se doménové řadiče a topologie sítě příliš nemění, nechá se těch pár záznamů zvládnout ručne, zvlášť když se využívá $INCLUDE.
Příklad využití: mám takhle, mimo jiné, ve správě firmu, kde se jednou za pár týdnů část zaměstnanů zvedne a přesune do jiné lokality s jiným subnetem a pár tiskáren si bere s sebou. Tyhle tiskárny si prostě se statickou adresou nevystačí (a to nemluvím o tom že tam jsou i Apply pro grafiky apod.). Předtím jsem to řešila drobným NATovým a routovacím harakiri na hraničních mikrotikách, které prostě posílaly pakety tam, kde příslušná tiskárna zrovna byla připojena. Ale s funkčním DDNS je to výrazně jednodušší, zvlášť při výměně tiskárny. Což se děje podstatně častěji než změny v topologii AD. Samozřejmě, tohle řešení není pro klikače. Ale ti by jim síť stejně spravovat nemohli, kromě Windows tam mají i linuxové servery atd...
-
Johanka (neregistrovaný)
Raději pro jistotu doplním, že samozřejmě záleží na konkrétní situaci. Jinak bude člověk uvažovat v případě firmy se 150 pobočkami po celém světě, z nichž většina bude mít vlasní DC, jinak ve firmě se 100 lidmi v pár kancelářích v Praze. Jde o to zvážit potřeby a možnosti a rozhodnout se v závislosti na nich.
-
jouda (neregistrovaný)
Tak AD replikace (pořád to replikuje jednou za 12 minut jako za blahé paměti na 2003 a něco jako okamžitá replikace tomu nic neříká?) není zrovna žádná výhra.
Aktualizaci záznamu mezi DHCP a DNS umí i vanilkovej ISC DHCPD a Bind, takže ani tu není problém.
k té instalaci role - jestli mě paměť neklame, tam nebyla podmínka M$ DNS, ale jen to aby to z nově instalovaného AD bralo DDNS updaty a povolit podtržítka (takže ano, se statickým DNS bylo nejrychlejší při změně to přepnout na nějakej microsoftí DNS, nechat doběhnout dcpromo a doménu si zonetransfernout a přehodit do "hlavního" DNS)
-
BobTheBuilderStříbrný podporovatelNe, není to omyl.
První AD můžete nainstalovat, pokud jde o DNS, na 4 způsoby:
1) DNS je rolí toho serveru (nejjednodušší a default)
2) do DNS vložíte ručně pár záznamů a do několika vnořených zón povolíte modifikace klienty - _tcp, _udp, _sites,...)
3) celou doménu AD dáte do vnořené zóny s povolenou modifikací klienty (to je jednodušší, ale pak všechny počítače nemáte např. v doméně firma.cz, ale ad.firma.cz)
4) celé AD dáte do vnořené zóny, kterou delegujete na DNS na DC (kombinace 1 a 3)
V 1 a 2 máte AD doménu firma.cz, ve 3 a 4 máte AD doménu ad.firma.cz.
Když máte DNS jinde, než na DC, tak vás nějaká replikace DNS záznamů prostředky AD netrápí, na to máte prostředky toho DNS, který použijete.
Do volby, jak to uděláte, vstupuje i to, kde máte DHCP - já třeba mám DHCP s ruční registrací MAC adres - a počítač sám pak zjistí, jak se má jmenovat (a v případě změny se sám přejmenuje), takže provozuju variantu 2 a současně pro jakýsi experiment máme nezávislé AD s variantou 4. -
Johanka (neregistrovaný)
A nemáte tam EDNS vypnuté?
https://morgansimonsen.com/2010/04/20/windows-and-extension-mechanisms-for-dns-edns/Asi bych jinak zkusila nainstalovat čistá Windows 2012 R2 se všemi záplatami, na chvíli je vystavit přímo na veřejnou IP do Internetu a pustit na ně ten test. Tím zjistíte, jestli tahle verze Windows potřebná DNS rozšíření zvládá (pokud ne, asi bych už nepočítala, že by to Microsoft nějak řešil). Případně totéž zkusit s trial verzí Windows 2016 a případně holt upgradovat. Nebo si s upgradem počkat na zimu na Windows 2019.
-
Johanka (neregistrovaný)
No, jak to tak vypadá, chybují i Windows 2016. Zatím jsem to zkoušela na neaktualizovaných, uvidíme, jestli to nespraví nějaké patche. Bohužel aktualizace jedou šnečím tempem, nespíš to dochroupe až někdy během noci.
Podle mě to buď neřešte (podle těch testů nejde o fatální chyby), nebo si mezi Internet a Wokna hoďte nějaký Linux s Bindem nebo Knotem, který ty dotazy bude přeposílat.
-
Johanka (neregistrovaný)
Windows 2012 R2 jedou už dvanáct dní v režimu Extended Support. Můžeme pro ně očekávat bezpečnostní záplaty, ale to je tak všechno. :-(
https://support.microsoft.com/en-us/lifecycle/search?alpha=Windows%20Server%202012%20R2%20Standard
-
xxxxx (neregistrovaný)
@Ondřej Surý ... U 5+ - 6+ let starého sw produktu placení moc nepomůže. Akorát tak na opravy chyb a podobně, ale žádné software enhancements. Viz např. https://access.redhat.com/support/policy/updates/errata/
@r2d2 ... pokud bude blbnout stále a pokud to bude problém a bude požadevek řešit to vše jen pomocí MS, tak asi nezbude než upgrade. Ale počkal bych si na Windows Server 2019 (a to čím déle tím lépe).
-
Windows Server 2008 (2008R2) jsou podporovány do ledna 2020. Přesto nemají funkční podporu DNSSEC, což byl kolem roku 2010 velký problém (částečné řešení bylo až ve Windows Server 2012), protože už tehdy bylo DNSSEC v USA vyžadováno jako standard pro instituce. Microsoft má tyhle věci úplně na háku a to odjakživa. A když pro verzi 2012 řešení není, tak kdo si v dobré víře zaplatil 2008R2 (vím o dost místech, kde je mají a myslí si, že dobře koupili...).
BTW: DNSSEC se pro 2008R2 řeší tak, že se zapne forwarding na Linux s DNSSEC, vypnou se root hinty a zapne se volba, která způsobí jako vedlejší efekt, že je to "použitelné". Je to jednodušší, než plný offload DNS mimo MS platformu (myslete na údržbu, kde běžný správce potřebuje klikací bázmek). -
František Mlejnek (neregistrovaný)
Jak se to dotkne obyčejných uživatelů ? Pochopil jsem, že mi pravděpodobně některé weby přestanou chodit. Doufám, že ne ty, které s oblibou používám - Ventusky, CHMI, ČSFD, Wikipedia, SMS-TV... Ach jo, život je změna, ale rozhodně by to neměl být boj, protože mi to dělá rýhy do srdíčka a jsem vždycky blíž a blíž infarktu... Taky se blíží říjnová aktualizace W 10, to zas bude hrůza...
-
j (neregistrovaný)
Nedotkne se jich to nejspis vubec nijak, protoze naproto drtiva vetsina DNSSEC nepouziva. A je i uplne sumafuk, jestli dnssec zaznamy ma tvuj cilovej web, podstatny je, ze to ignoruje tvoje DNS.
A k ty druhy casti tech retardu v NICu https://tools.ietf.org/html/rfc2681 ... "A Round-trip Delay Metric for IPPM" ... fakt ?
"To prakticky znamená, že servery, které po 1. únoru nebudou odpovídat na dotazy s EDNS rozšířením, přestanou z pohledu klientů fungovat a domény hostované na těchto serverech se stanou nedostupnými!"
To praktidky znamena ze NIC prokracuje v sireni hoven svejme zcela nesmyslnejma blabolama."přestanou významní výrobci DNS software po 1. únoru 2019 "
Jo a lusknutim prstu se vsechny servery a klienti po cely platene aktualizujou ... tovizejo. -
Petr Špaček (neregistrovaný)
V ideálním případě běžný uživatel změnu nezaznamená - článek proto cílí na správce DNS infrastruktury.
U první změny se musí připravit zejména ISP. Poslední statistika zveřejněná na adrese https://stats.labs.apnic.net/dnssec/CZ říká, že v ČR používá DNSSEC validující resolver zhruba 50 % klientů, takže poctivá příprava na straně poskytovatelů připojení je opravdu nutná.
U druhé změny (naplánované na únor 2019) situaci vyhodnocujeme. Můžete se těšit na další článek, ve kterém se podíváme na stav .CZ domény.
-
Není na škodu asi dodat, pokud používáte BIND, hodí se zkontrolovat aktivní kořenové klíče přímo v bindu.
Slouží k tomu příkaz "rndc secroots", který vynutí zápis named.secroots do adresáře directory. V něm uvidíte, kterým BIND doopravdy už důvěřuje.
Může se totiž stát, že ačkoliv v managed-keys máte zcela správné klíče, BIND už měl aktivní interní proces aktualizace klíčů. Pokud by fungoval špatně, nebudete mít klíče uvedené v konfiguraci. Ale klíče, které byly v konfiguraci v při prvním startu, kdy se mu podařilo kontaktovat root. Pokud to od té doby už nejde, můžete být překvapení. K vynucení důvěry z konfigurace smažte managed-keys.bind, v případě použití view *.mkeys. Při dalším startu se bude důvěřovat všem klíčům z managed-keys v konfiguraci. Velmi pravděpodobně ale váš server už dávno důvěřuje oběma klíčům i bez zásahu do konfigurace.
-
Dobrý den,
nejsem z toho moc moudrý, zkoušel jsem i aktualizovat bind, ale RedHat má pořád verzi 9.9.4:
bind-9.9.4-61.el7_5.1.x86_64
Vrací mi to tohle:dns=ok edns=ok edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns512tcp=ok optlist=timeout
EDNS - Unknown Version Handling (edns1)
dig +nocookie +norec +noad +edns=1 +noednsneg soa zone @server
expect: BADVERS
expect: OPT record with version set to 0
expect: not to see SOA
See RFC6891, 6.1.3. OPT Record TTL Field UseEDNS - Unknown Version with Unknown Option Handling (edns1opt)
dig +nocookie +norec +noad +edns=1 +noednsneg +ednsopt=100 soa zone @server
expect: BADVERS
expect: OPT record with version set to 0
expect: not to see SOA
expect: that the option will not be present in response
See RFC6891EDNS - Supported Options Probe (optlist)
dig +edns +noad +norec +nsid +subnet=0.0.0.0/0 +expire +cookie -q zone @server
expect: NOERROR
expect: OPT record with version set to 0
See RFC6891Mám napsat na RedHat? Nebo se to někde zapíná?
-
Petr Špaček (neregistrovaný)
Dobrý den,
pokud vím, tak to není potřeba zapínat, takže se může jednat o chybu v prastaré verzi která je v balíčcích.
Před hlášením Red Hatu bych zkontrolovat, že v cestě není příliš striktní firewall nebo load balancer, ty také mohou některé dotazy zahodit.
Přeji vám pěkný den.
