Privátní adresy ve veřejném DNS, knot-resolver a apple.com

Ahoj všem,

chtěl bych se podělit o jednu nepříjemnou zkušenost z počátku tohoto týdne. Zřejmě v souvislosti s novym iOS release upravil Apple DNS tak, ze v NS záznamy ess.apple.com směřují na privátní adresy dle RFC1918. Stalo se tak 16.9. cca v 1:20.

dig -4  +trace ns ess.apple.com.

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> -4 +trace ns ess.apple.com.

---cut ---
ess.apple.com.          43200   IN      NS      a.ns.apple.com.
ess.apple.com.          43200   IN      NS      b.ns.apple.com.
ess.apple.com.          43200   IN      NS      c.ns.apple.com.
ess.apple.com.          43200   IN      NS      d.ns.apple.com.
ess.apple.com.          43200   IN      NS      usmsc2-extxfr-001.dns.apple.com.
ess.apple.com.          43200   IN      NS      mressext-axfrdnsvip.mr.if.apple.com.
ess.apple.com.          43200   IN      NS      pvessext-axfrdnsvip.pv.if.apple.com.
ess.apple.com.          43200   IN      NS      stessext-axfrdnsvip.st.if.apple.com.
;; Received 499 bytes from 204.19.119.1#53(c.ns.apple.com) in 8 ms

;; communications error to 10.52.192.140#53: timed out
;; communications error to 10.52.192.140#53: timed out
;; communications error to 10.52.192.140#53: timed out

ess.apple.com.          43200   IN      NS      a.ns.apple.com.
ess.apple.com.          43200   IN      NS      b.ns.apple.com.
ess.apple.com.          43200   IN      NS      c.ns.apple.com.
ess.apple.com.          43200   IN      NS      d.ns.apple.com.
ess.apple.com.          43200   IN      NS      usmsc2-extxfr-001.dns.apple.com.
ess.apple.com.          43200   IN      NS      mressext-axfrdnsvip.mr.if.apple.com.
ess.apple.com.          43200   IN      NS      pvessext-axfrdnsvip.pv.if.apple.com.
ess.apple.com.          43200   IN      NS      stessext-axfrdnsvip.st.if.apple.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 499 bytes from 204.19.119.1#53(c.ns.apple.com) in 8 ms

;; communications error to 10.52.200.235#53: timed out
ess.apple.com.          300     IN      NS      a.ns.apple.com.
ess.apple.com.          300     IN      NS      b.ns.apple.com.
ess.apple.com.          300     IN      NS      c.ns.apple.com.
ess.apple.com.          300     IN      NS      d.ns.apple.com.
;; Received 137 bytes from 17.253.207.1#53(b.ns.apple.com) in 8 ms



Ty tři poslední NS pro ess.apple.com jsou na privátních adresách. Smutné...

Pokud používáte knot-resolver a máte zapnutý dns rebinding protection - modules.load('rebinding < iterate'), knot-resolver, přestoze vlatní výsledek rezoluce nevede na privátní adresu, posílá REFUSED (rcode 5).

Pokud máte vytíženější DNS resolvery, vede to k masivní amplifikaci provozu. Apple klienti to pak zkoušejí stále dokola. Unbound toto zresolví.

A.



Podle mne to doporučení, že by ve veřejném DNS neměly být záznamy vedoucí na IP adresy z privátních rozsahů, neodpovídá dnešní realitě. To mělo smysl v době, kdy se ty IP adresy používaly opravdu pro privátní sítě. Ale dnes se masivně používají pro sítě, které by chtěly být v internetu, ale není pro ně dostatek IPv4 adres, takže se to flikuje NATem. Do toho se používá DNSSEC, je tlak na používání důvěryhodných certifikátů – což je vše v pořádku. A to omezení se holt do tohoto světa nehodí.

A ty jako pingneš 10.52.192.140? Kdo pingne,ať hodí routerem.
Tak to jejich dns nepoužívej  8)

Podle mne to doporučení, že by ve veřejném DNS neměly být záznamy vedoucí na IP adresy z privátních rozsahů, neodpovídá dnešní realitě. To mělo smysl v době, kdy se ty IP adresy používaly opravdu pro privátní sítě. Ale dnes se masivně používají pro sítě, které by chtěly být v internetu, ale není pro ně dostatek IPv4 adres, takže se to flikuje NATem. Do toho se používá DNSSEC, je tlak na používání důvěryhodných certifikátů – což je vše v pořádku. A to omezení se holt do tohoto světa nehodí.

S tím nemohu souhlasit. Vede to jen k potížím, nežádoucímu provozu v sítích a pod. Navíc, v tomto případě nechápu, čeho tím chteli docílit. Je to zcela nefunkční věc a DNS to rozbíjí.

My třeba používáme interní adresy ve veřejném DNS cíleně:
 - Servery často máme dual-stackové a tak jsou alespoň po IPv6 stejně dostupné.
 - Experimenty prohlížečů s DOH a dalšími novinkami nám zvedly množství problémů uživatelů s nedostupností služeb.
 - [souvisejicí] Všechny http služby už stejně jedou na https a chceme tam validní SSL certifikát

Interní DNS jsme tedy kompletně zlikvidovali, používáme jen veřejné domény a zmizela nám další věc, která v infrastruktuře může dělat problémy. Ono to vytvořilo jiné, ale o tom zas jindy.

Jako bonus tím snižujeme možnost sledování aktivity uživatelů a uživatelé ať si používají DNS resolvery jaké chtějí.