Dotaz: DNS failover

[Tomas3]

Zdravím všechny,

měl bych dotaz ohledně DNS failoveru. Mám dva servery s CENTOS 7, domény registrovány na Wedosu. Mám 3 připojení k internetu a od každého ISP pár veřejných IPv4 adres. Firewall mám nakonfigurován tak, že když vypadne jeden poskytovatel, přesměruje traffic na druhého. Ale jak docílit toho, aby když je nedostupná určitá IP z internetu, aby mi traffic z internetu šel na funkční veřejnou IP. Asi by se to dalo řešit DNS failoverem a tak mě zajímá, řešil jste to někdy někdo? nechci ručně měnit DNS záznamy u domén a tak bych potřeboval nějaký levný a spolehlivý automat. Děkuji Tom

Odpovědi

[MP]

Cloudflare.

[Nereknu]

Zrovna minulý týden jsem to řešil. A zatím jsem zvolil víc A záznamů u domény - sice druhá linka je slabší, ale pro to nejdůležitější to zas tak nijak extra nevytěžuje a ty méně důležité věci (které ale mají větší průtoky) prostě chvíli nepojedou.

[Tomas3]

Děkuji, to mě taky napadlo, ale nikde jsem nezjistil, jak přesně více A záznamů funguje. Znamená to, že když nebude dostupná první IP v A záznamu, že to zkusí znovu pod druhou IP adresou? Myslel jsem, že to funguje jako ping, když bych totiž dal ping na název domény (subdomény), náhodně mi najde jednu z IP v A záznamu a tu bude pingat, podle mě, když bude jedna IP adresa z DNS záznamů nedostupná a zrovna si ji ping vybere, tak ping na ní nebude fungovat. Nebo to nyní funguje už i tak, že když pošlu ping, tak mi bude odpovídat vždy jen dostupná IP? Nerad bych to nastavil a pak zjistil, že polovině uživatelů služby nefungují, když nebude fungovat jedna z IP v DNS záznamu.

[Pepan]

jak přesně více A záznamů funguje: roundrobin když bude jedna IP adresa z DNS záznamů nedostupná a zrovna si ji ping vybere, tak ping na ní nebude fungovat: ano

[Max]

Povolit u všech veřejných IP komunikaci s tím, že je dobré, aby i odchozí traffic odcházel směrem odkud bylo navázáno spojení.
Pro všechny veřejné IP nastavit shodné dns záznamy. Tzn. nasadit DNS Round Robin

Následně můžeš spoléhat na klientskou fci failoveru, kdy web browser když nenačte web z první IP v pořadí, zkusí další.
Toto se ale týká web prohlížečů a není to úplně ideální failover. Pokud budeš poskytovat něco jiného (jiné služby, než webové), tak těžko říci, jaká podpora pro dns failover tam bude.

Další možností je hodit si někam proxynu (např. haproxy). V rámci haproxy můžeš kontrolovat, zda zdroj žije (můžeš si na to napsat vlastní pravidla) a pokud ne, bude směrovat provoz na další server v pořadí, nebo dočasně server vyřadí z load balancing listu a až bude IP žít, zase automaticky bude směrovat provoz.

Další možností je využít nějakého poskytovatele proxy služeb, co toto bude dělat za tebe (odpadne ti VM s haproxy), tzn. třeba ten Cloudflare.

Další možností je použít DNS Round Robin v kombinaci s DynDNS. Tzn. že si budeš kontrolovat, zda IP žije, pokud ne, smázneš dns záznam pro tu konkrétní IP a zbytek necháš. Až IP bude žít, zase dns záznam přidáš. Wedos má nějaké API pro práci s DNS. Lze si to tedy naskryptovat.

Zdar Max

[Tomas3]

Děkuji, z vnitřní sítě do internetu to tak mám nastaveno. Ale řeším například SMTP server a další některé služby. Psal jsem v příspěvku výše, že jsem kdysi zkoušel více A záznamů, ale když jsem dal ping na název domény, tak mi to občas vybralo IP adresu, která byla nedostupná a ping mi neodpovídal, při dalším spuštění pingu to šlo na druhou IP, která zase fungovala. Dle tvého příspěvku to opravdu tak asi funguje, jen né v internetovém prohlížeči, který zkusí více IP adres, je to tak? Právě se mi zdá nejlepší zbůsob kontrola, jestli žije tato IP a když ne, nějakým API nebo službou změním IP adresu na funkční a jede se dál. Jenže i kdyby bylo v DNS TTL na 1 vteřinu, myslím si, že to není 100% způsob, protože většina poskytovatelů (ISP) bude mít nastavené cachování.

[Max]

Samozřejmě, minimálně ttl bývá 15min s tím, že existuje spousta routerů, které mají v sobě dns cache nastavenou natvrdo na třeba 24h.
Jak jsem napsal, řešením je malá haproxy na stabilní infratruktuře někde v housingu, případně komerční poskytovatel proxy řešení jako např. ten Cloudflare.
Zdar Max

[MP]

15min? To tezko :) Staci se podivat na TTL u apple/facebook a ruznych cdn. Taky jsme na to doplatili treba u Cisco ASA...

Pokud se jedna o sluzby mimo prohlizece, tak bych na klientsky dns failover nevsadil ani zlamany petnik, takze jedina cesta je reverzni L4 proxy v housingu ci Cloudflare apod., pokud se clovek nechce delat s PI.

[Max]

Tak 15min / 900s bývá nejnižší možná hodnota u poskytovatelů dns. Kdo má vlastní, může si nastavit menší ttl. Nebo si může najít poskytovatele, který to umožňuje.
Každopádně jak už jsem řekl a ty též, dns failover není bezpečné řešení a nemusí to být vůbec řešení pro nehttp služby.
Zdar Max

[alkoholik]

S 5 minutami nebyva sebemensi problem.

[PetebLazar]

Nebyl Internet navržen tak, že do jednoho bodu (IP adresy) nemusí vést jen jedna možná cesta?

[Max]

A jak to koncový uživatel asi tak ovlivní? Tebou popsané řešení je věcí ISP a poskytovatelů peeringů, ne?
Zdar Max

[PetebLazar]

Toho jsem si vědom. Zajímalo by mne, kolik by taková služba mohla dnes řádově stát.

[NN]

To ale neplati pro unicast..

[vencour]

Tak jako tak pokud je více uplinků tak musí jít odpověď v rozsahu toho subnetu, na kerý šel dotaz.

[j]

To pujde, ale nemusi jit tou linkou ze ktere dorazil request. Bydefault bez dalsiho totiz naprosto bez problemu projde pres libovolnej router paket s libovolnou src (a dst pochopitelne). Tudiz pokud mas IPcka A a B, a posles k providerovi A paket se SRC B, tak to minimalne v 50% naprosto vpohode projde. Opacne uz pochopitelne nikoli, protoze onen provider nezna cestu k B.

Parkrat sem takhle resil oblibene tema asymetrie linek ... ;D, tzn nastavil sem to tak zcela umyslne.

--- BTW: Je to mimo jiny jeden ze zpusobu jak prostrelit NAT zvenku, a primarni duvod toho proc NAT naprosto nijak neresi jakoukoli bezpecnost site, ba naopak, vyrazne ji zhorsuje, protoze napsat spravne pravidla v situaci, kdy se IPcka paketu kvuli NATu v prubehu routovani menej muze byt celkem slusny peklo.

[vencour]

To, že to ve většině případů jde, neznamená, že to půjde vždy.
Mimochodem fakt by mne zajímalo, jestli všichni asymetrický routing nebo kolizní subnet považují za malichernost.

[alkoholik]

To pujde, ale nemusi jit tou linkou ze ktere dorazil request. Bydefault bez dalsiho totiz naprosto bez problemu projde pres libovolnej router paket s libovolnou src (a dst pochopitelne). Tudiz pokud mas IPcka A a B, a posles k providerovi A paket se SRC B, tak to minimalne v 50% naprosto vpohode projde. Opacne uz pochopitelne nikoli, protoze onen provider nezna cestu k B.

Tak tohle je jeden z nejvetsich blabolu, ktere jsi tu kdy vyplodil.

[j]

Pise totalni trotl netusici ani zbla o fungovani IP.

[alkoholik]

Kolik BGP routeru spravujes? Tusis vubec, k cemu je mnt-routes v route objectu v RIPE db?
To, co popisujes, je normalni spoofovani adres a to zadny normalni ISP ve svoji siti nechce.

[trekker.dk]

To, co popisujes, je normalni spoofovani adres a to zadny normalni ISP ve svoji siti nechce.

normální příčetný. Bohužel bych řekl, že normálnímu ISP je to dost často fuk a ošetřené to nemá. Což samozřejmě neznamená, že by to někdo měl využívat nebo se na to dokonce spolehnout.

[alkoholik]

V zadnem pripade se na to spolehnout neda, protoze to stejne ustreli prvni BGP router na tranzitu.

[trekker.dk]

protoze to stejne ustreli prvni BGP router na tranzitu

Kdyby tohle byla vždycky pravda, tak nefungují syn flood apod. útoky ze spoofnutých adres.

[j]

To hodne zalezi na tom, ceho chces dosahnout. Pokud ti nevadi, ze se klienti budou ruzne pripojovat na ruzny IP, tak je naprosto koser proste uvest vic A/AAAA zaznamu. Normalne se to chova tak, ze DNS serviruje ty zaznamy v "nahodnym" poradi, a klient zacne tou prvni a pokud nefunguje, mel by zkusit druhou a dalsi.

Pokud mas svuj dns, tak muzes ovlivnit i to poradi, pripadne muzes nabizet ruzny IP podle toho odkud jde dotaz ...

Samozrejme ve vsech DNSlike resenich plati, ze v okamziku vypadku se spojeni rozpadne. Coz muze a nemusi byt problem.

----

Ovsem pokud to chces vyresit spravne, tak presne k tomu slouzi PI adresy. Jinak receno, tvoji ISP slouzi jako dorucovatele dat ... ale IPcka mas pro vsechny stejne. Oni jen vypropaguji tvuj rozsah a prohlasi, ze k nemu znaji cestu. Ktera se ve skutecnosti pouzije pokud jich funguje vic, zalezi na spouste okolnostech.

Rucni zmena DNS je ti uplne naprd, uvedom si, ze DNS se cachuje, a cache muze zit desitky hodin ale i dny.

[Tomas3]

Ano, to já chápu a proto to nechci dělat ručně a ani s ohledem na cachování DNS u poskytovatelů. Hledám možnosti. Obávám se, že mi poskytovatelé neproroutují IP adresu konkurence a naopak. Právě bych se nejraději vzdal i více A záznamů v DNS a raději to udělal tak, že bych měl nějakou adresu (CNAME), která by v případě výpadku šla na jinou IP adresu. Tento CNAME bych zadal k doménám do DNS. Takže kdyby vypadl první server, šlo by to přes druhou IP, která by se rychle v tomto názvu změnila, problém je, že jsme zase u DNS a jak to někdo z ISP nacachuje, tak to postrádá smysl :( Nastuduji ten cloudfare, jak by měla fungovat ona proxy. Děkuji

[j]

IP != PI = provider independent. Tzn mas SVOJE adresy (ale nejsi opravnen je poskytovat komukoli dalsimu = routovat je verejne, nejsi clenem ripe ...), a naprosto kazdej ISP ti je naroutuje. Samozrejem je tu hromada takyisp zamestnavajicich vsemozny trotly, a mezi nez muzes zaradit trebas toho o par postu vejs, ktery vubec netusej o cem je rec.

Kazdej ISP je pak schopen ti takovy adresy zaridit (neco za to pochopitelne zaplatis). Na 4ce to bude pochopitelne uz asi smolik, ale na 6tce naprosto vpohode.

Konkurencni adresu ti nenaroutuje predevsim proto, ze kdyby vypropagoval /32, tak ho nekdo prijde osobne zastrelit.

V DNS se NIC rychle nezmeni. Takhle to vubec nefunguje, a CNAME ti vubec nijak nepomuze. Cname je alias, pokud se zeptam rekneme na www.abclinuxu.cz, tak zjistim, ze je to CNAME pro abclinuxu.cz, a ten ma A 171.25.221.158.

A presne tohle si ulozi muj resolver do cache - na jak dlouho zalezi na SOA a taky na me, protoze to muzu klido zcela ignorovat (trebas proto, ze provozovatel primarniho NS je trotl a ma tam nesmyslne malo ... ). Obecne se ale bavime jiste o hodinach, kdy bude trvat nez se LIBOVOLNA zmena v DNS realne projevi vsude.

Muzes samozrejem vyuzivat proxy, cimz si jen vyrobis dalsi SPOF. Co budes delat, az ti pojde ta?

Jednoduse pocitej s tim, ze pokud chces zajistit nejaky sluzbe nejakou dostupnost, tak potrebujes internet, ne prijeni k necemu bez adres a routovani.

[alkoholik]

Konkurencni adresu ti nenaroutuje predevsim proto, ze kdyby vypropagoval /32, tak ho nekdo prijde osobne zastrelit.

Zadne strileni se neprovozuje. Jenom ti neblizsi pricetny router prefix delsi nez /24 odignoruje.

[vakus]

Skus sa pozriet u Hetznera na Failover IP.

[iwk]

Ides na to spravne. Ten update DNS sa da spravit automaticky - dynamicke dns (http://www.google.com/search?client=opera&q=dynamic+dns) Bud cez nejaku sluzbu (napr. noip) alebo aj priamo mikrotik ma vlastnu implementaciu (https://wiki.mikrotik.com/wiki/Manual:IP/Cloud). Pozri, ci nieco priamo nepodporuje tvoj firewall, ak je to nejaka krabicka. Asi najednoduchsie riesenie.

Fungovat to bude tak, ze domeny (www) si nasmerujes na nejaky ten alias (CNAME), ktory sa automaticky updatne, ked sa konektivta prepne na zalohu.

Druha moznost je si podobnu sluzbu na nejakej domene postavit sam. AWS route53 vie robit healtcheck a vracat IP iba pre dostupne resources. https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html.

Tu na blogu to jeden clovek vysvetluje aj obrazkami https://www.virtualtothecore.com/load-balancing-services-with-aws-route53-dns-health-checks/

Ako uz ini poznamenali, pri dns failovere moze byt delay kvoli TTL (minuta 1 minimum) a treba ratat s tym, ze niekomu kto ignoruje nastavenie tychto nizkych TTL, sa moze javit sluzba nedostupna aj dlhsie. Ale to uz je problem ignorantov :D