Vlákno názorů k článku
CZ.NIC automaticky zapnul DNSSEC na prvních 160 doménách od kve - Jak se to chová v praxi? DNSSEC jsem...

Jak se to chová v praxi? DNSSEC jsem zatím nějak moc neřešil, ale tady z toho cítím problém. Mám DNS záznam sluzba.domena.cz, který mi z internetu DNS posílá na veřejnou IP dané sítě, kde se o to postará portforwarding a ve vnitřní síti si daný záznam nechávám lokálním DNS směřovat přímo na adresu serveru za NATem. Co se stane, když na dané doméně budu mít aktivní DNSSEC?

.local taky nemusi byt dobry napad - https://en.wikipedia.org/wiki/.local

Spravit si extra TLD domenu je v takomto pripade (ked pristupujem z toho isteho zariadenia na ten isty server, akurat niekedy idem z domacej wifi a niekedy z vonkajsej siete) zbytocna otrava pre uzivatela (a pri tej strate Wi-Fi signalu to nijako nepomoze).

Dalsie riesenie je pouzit NAT reflection (aka NAT loopback) a netreba ziadne specialne DNS odpovede pre requesty z internej siete.
V domacich podmienkach (maly pocet uzivatelov a rozumny objem dat) by to malo byt pouzitelne; vsetko vtedy sice musi ist cez router (teda aj pri pristupoch z internej siete), ale vo vacsine pripadov by to nemuselo vobec vadit - pretoze to cez ten router z Wifi vo vacsine pripadov chodi tak ci tak, vacsina ludi ma doma router+wifi ako jedno zariadenie, pripadne ma wifiAP priamo pripojeny do jedneho z LAN portov routra. (Myslim, ze len malokto to ma doma zapojene tak, ze medzi routrom a wifiAP je este aspon jeden dalsi switch, v takomto zapojeni by NAT reflection mohlo mat dopad na vykon.)

No, .local už rozmlouval kolega a .corp také je problémová, pořád se čeká, kdy s eobjeví jako oficiální TLD.

Ale sám toto řeším tak, že i interní DNS pro strje, které jsou definovány i ve vnějším DNS vrací stjné údaje/IPčka (aby s epředešlo zmatneí při přechodu mezi stíěma a občas zapomenutém flushnutí cache) a druhý krok je snaha podepisovat ii interní DNS pomocí DNSSEC stejnou sadou klíčů, ve stejné časy.
Jak pak doručit paket správně k cílovému stroji unvitř záleží na topologii. Pokud je to fakt v jendom interním segmentu, tak nějaká forma hairpin NATu, v rozlehlejší je tjeně server v DMZ/VLAN, takže normální routing.

.lan, .home ani .doma zatím jako oficiální TLD nehrozí.

TLD .home snad startuje už letos? Aspoň předregistrace už běží.
Jinak MS nějak zuřivě varoval před používáním vlastních TLD. Nějak nehezky vysvětlovali, že to v ne/dohlednu zaříznou resolving jen na platné tld, že mám vše dělat jako subdoménu existujícího.

Vy jste zřejmě nikdy neměnil doménu v síti, protože někdo použil TLD, která zatím nebyla použita, jenže to zatím pominulo, že? Vážně bych doporučil to udělat správně hned a neřešit rozbité úplně všechno později.

Používat nepřidělenou TLD je velmi špatný nápad, což ilustruje váš výběr TLD .local, která je ve skutečnosti přidělena a slouží pro mDNS, takže pokud do sítě dáte něco s Linuxem nebo macOS, tak tam nebude .local fungovat.

Doporučený postup je mít vyhrazenou poddoménu z vlastněné domény a buď ji v nadřazené doméně označit jako nepodepsanou, nebo ji podepisovat, a to klidně i vlastním klíčem (do nadřazené domény pak dáte DS). Případně existuje jedna vyhrazená TLD pro tyhle účely ( .test), ale i s ní mohou být problémy. Třeba to, že je v podepsané root doméně označena jako neexistující, takže validující resolver ji odmítne.

Můžete podepsat obě verze stejným klíčem. Ale views jsou obecně problematické a je lepší se jim vyhnout, protože klient může odpověď z jedné sítě nacachovat a používat v jiné síti.