DNS round robin a gyakorlatban nem működik

Hálózatok általános

A világ legegyszerűbb dolga - gondolnád. Egy rekord mögé felveszel több IP-t, és a DNS elbalanszolja, két IP esetén nagyjából fele-fele arányban.

A gyakorlatban ez valamiért nem működik. A szolgáltatás teljesen lényegtelen. Bár elvileg semmi köze nincs hozzá a TTL-nek, de már az is le lett véve 1 percre. De teljesen mindegy. Ha egy bizonyos gép egy adott IP-re csatlakozik, utána újra és újra csak arra csatlakozik, kb. akárhányszor próbálom elérni a szolgáltatást. Akár egy sima telnet-tel is reprodukálható. Egyaránt tapasztalom Windows és Linux kliensekről. Most pl. két konkrét gépet nézek, ami hajnal 3 óta ugyanarra a szerverre próbál csatlakozni. Úgy is, ha cronból megy, úgy is, ha kézzel indítom.

Látott már valaki ilyet? WTF?

( godot v | 2023. 09. 04., h – 13:34 )

Pontosan hogyan teszteled, kérdezed le?

A DNS cachelés kavar be a kliensen ilyenkor általában, sajnos ez is több szinten bekavarhat  pl OS dns cache, böngésző dns cache stb. Ha több kliensed van akkor lesz értelmezhető elosztás.

Ha simán "dig"-el lekérdezed pl a digitalocean.com-ot két A rekorddal,akkor általában jó látszik, hogy kb fele/fele arányban dobja az egyik vagy másik rekordot először.

dig +short digitalocean.com
104.18.154.42
104.18.155.42
 dig +short digitalocean.com
104.18.155.42
104.18.154.42

Értem, a dig-gel a névszervert kérdezem, aki a válaszában forgatja az IP-ket. Az app meg az OS-től kéri a feloldást, az meg cacheből adja. De amikor az összes TTL érték 10x lejárt már, az OS-nek, az appnak, az akárminek ugyanúgy újra meg kéne kérdezni a DNS-t, szóval valami halvány rotációnak csak lenni kéne.

"Sose a gép a hülye."

( PunishR v | 2023. 09. 04., h – 13:40 )

Eloszor is ne hasznalj loadbalance-ra DNS RR-t:) a debugolashoz erdemes megnezni, hogy a ket gep milyen resolvereket hasznal azok hogyan es mit cachelnek el, valamint a gepek onon maguk mit cachelnek el. Az 50-50 tudhat mukodni, de nem feltelenul egy gep osszes requestje fog 50-50% ide-oda menni.

pedig a loadbalancolasnal altalaban az az egyik nagy megoldando problema, hogy ugyanaz a kliens mindig ugyanarra a szerverre legyen routeolva, a sessionok stb kezelese miatt. tehat a kliensek legyenek elosztva a szerverek kozott, de az adott kliens bindelve 1 szerverhez (amig az a szerver mukodik persze) - ezt a haproxy eleg jol tudja amugy.

( ricsip v | 2023. 09. 04., h – 14:01 )

Szerkesztve: 2023. 09. 04., h – 14:01

A DNS (round-robin) loadbalancing rákfenéje, hogy az endpointra van bízva a megfelelő viselkedés.

( joco01 v | 2023. 09. 04., h – 14:08 )

Két okból is rosszak az elvárásaid. Egyrészt a DNS egyszerűen nem load balancer. Másrészt ha csak pár gépről nézed, akkor totál semmi értelme nincs. Ha rengeteg kliensed van, talán közelítőleg hasznos eredményt produkál.

( Proci85 v | 2023. 09. 04., h – 14:22 )

Szerkesztve: 2023. 09. 04., h – 14:23

Sok számú kliensnél oszlik 50%-ban. 1 gépen nézve a kliens kap egy IP-t, mindig azt fogja használni. Ha a végponti IP lehal, lyukra fut az a kliens. Tudtommal így nem lehet failovert csinálni.

Nem failovert akarok csinálni, illetve nem a klasszikus értelemben. OK, lehal az IP. Connection failed, timed out, akármi. Nem probléma.

De 10 perc, fél óra, 6 óra, 12 óra múlva is miért megy mindig ugyanarra az IPre?

"Sose a gép a hülye."

Szerintem meg nem, a kliensnek illene figyelembe vennie a TTL-t, sőt vannak kliensek, akik már képesek a több visszaadott IP-t kezelni, és kliens oldalon ilyenkor loadbalance-ol újabb DNS lekérdezés nélkül is. Az OP megoldása egy teljesen standard megoldás, múködnie kellene, valószínüleg valami hiba van a háttérben.

( hnsz2002 v | 2023. 09. 04., h – 16:28 )

Szóval elcsesztem ma vele sok időt, most az a tippem, hogy valami IPv6-tal kapcsolatos bug, mert ha csak v4-es címekkel nézem, akkor úgy működik ahogy várom. Egyelőre kivettem a név mögül a v6 címeket, csak a v4-ek vannak bent, pár nap és kiderül remélhetőleg.

"Sose a gép a hülye."

Nem ignorálok semmit.

De csináltam egy teszt rekordot a következő IP-kel:
1.1.1.1
2.2.2.2
2a01::1
2a01::2

És tökéletesen működik az adott gépről is, telnettel is, ahogy várod: hol az egyik, hol a másik cím jön. Majd ezek lettek cifrázva még pár módon (más vég, lett köztes oktett, több IP), ugyanígy működött. Egészen addig, amíg az éles rekordon lévő két IPv6 címeket fel nem vettem ehhez a teszt domainhez, mert onnantól a teszt is ugyanazt a v6-ot adta fixen, mint az éles: 2a01:4f8::..... (A másik cím 2a01:4f9-cel kezdődik) Amint a 4f8-at átírtam 4fa-ra, innentől a 4f9-re ment fixen. Szóval valami olyasminek tűnik, mintha a v6-os címeket bizonyos esetben sorbarendezné a DNS válaszától függetlenül.. Aminek semmi értelme. De ez volt.

Ezt mivel magyarázod?

"Sose a gép a hülye."

All-in-all lehet egy szerver oldalon tökéletesen beállított megoldás de mivel a klienseken (azok hibájából de ez tökmindegy) változatosan lesz többé vagy kevésbé rossz ezért ez a megközelítés rossz.

Ha már megoldás irányba akarunk menni (és nem ezt tákolni tovább) akkor én floating IP és heartbeat környékén nézelődnék  - bár nem vagyok infrastructure architect.

Gábriel Ákos

Szerintem a kliensed nem egy faék egyszerűségű dolog.

Ha ennyire le akarjuk egyszerűsíteni, fogj egy MCU-t 256KB RAMmal, tolj rá egy minimál kódot, ami semmi mást nem csinál, csak amire szükséged van és teszteld azzal.

OS independent lesz, az garantált. OSI modell megvan? Ha feljebb megyünk a szinteken, egyre több a nehezen követhető esemény.

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Szerintem nem rohogtek fel sem a blogflare-nel sem a google-nel, ha hasznaltal mar anycast-et "internet" oldalon, nem csak siman egy lokacion belul, akkor tudod, hogy bar megold egy csomo dolgot, de ehhez egyeb dolgoknak is meg kell lennie. Persze egy 8.8.8.8/1.1.1.1-et viszonylag egyszeru anycast-el behirdetni, mert UDP es mukodni fog.

Egyebkent bar blogflare-nek van a legnagyobb ugyfelbazisa (reszben a free csomagjunak), de a kiszolgalt forgalmuk elegge eltorpul pl a fastly-tol, persze ettol jo ez a szakma, hogy ugyanazon problemara tobb jo valasz is lehet.

Cloudflare-nek hívják, nem blogflare.

Régebben nagyon büszkén hírdették yt-os előadásokban, hogyan állítanak meg 100Gbps - 1 Tbps-es ddos-okat is, szóval már ezelőtt 10 évvel is ilyen nagyságrendű forgalmakat kezeltek. Azóta ez csak tovább nőhetett. Szóval annyira nem picik szerintem.

Iszonyú fárasztó a teljesen magyartalan, ékezet nélküli szövegedet olvasni. Mondom, ékezetes billentyűzet már huszonéve is létezett, de ha gondolod, küldök neked szép színes pöttyöket, hogy a zongora mellett a magyar nyelven történő írást is színes billentyűkkel tudd megtanulni.

Ha magyarul írsz, akkor ékezetesen tedd - vagy sehogy. Attól, hogy a hazádat elhagytad, az anyanyelvedet még nem kell lábbal tiporni - legfeljebb ne használd, ha már elfelejtetted vagy soha nem is tudtad rendesen...
A helyesírás értelmes embereknél nem kedv kérdése, hanem alapvető dolog. Aki igénytelen, annak persze mindegy...

a kettő hogy van egyébként egy lapon? Az anycast arra való, hogy siteok között adjon terheléselosztást*, és failovert, a floating IP meg helyi redundanciát biztosít. Mondjuk a javaslatból valóban hiányzott egy helyi loadbalancer a szolgáltatás elé.

*és ugye az csak annyit tud, hogy a klienshez legközelebbi élő locationhoz routeolja a forgalmat. Persze biztos meg lehet csinálni egy siteon belül is, hogy összeharákolod a bgpt meg valami natokat, hogy a végén ugyanott legyél a gyakorlatban, mintha használtál volna vrrpt. (és közelében sem annak, amit egy klasszikus LB tud). Meg persze az anycasthez egész sok olyan dolgot meg kell tudj csinálni, amit nem biztos, hogy meg tudsz egy adott infrában. Jó dolog, de messze nem a silver bullet, hello.

Hát, akkor a valódi bejövő router valahogy majd dönt arról, hogy merre routeol a teljesen egyforma távolságra levő szerverek között, ha tippelnem kellene, akkor pézfeldobással dönt az egyikről, és mindig ahhoz fog menni.

Cserébe futtathatok valami full blown routing protokollt az összes szerveren is, baszakodhatok a rendes routereken azon, hogy szűrjem a hírdetéseket, ilyesmi. Nyilván lehet, de őszintén szólva én nem látom a fene nagy gaint a Nagyz által lekilencvenévesezett vrrphez képest, ahol ráadásul valamivel direktebb kontrollom van afelett, hogy mi történik.

Elhiszem, hogy ahol egyébként is van valami SDN, ahol tunelekkel meg bgpvel dobálozunk, ott adott esetben ez az egyszerűbb / jobb, de ez messze nem mindenhol van, és ha el kell dönteni, hogy egy keepalivedt keverek pluszba bele emiatt, vagy egy komplett ilyen routeolásos lófaszt... hát szóval én lehet inkább az előbbire szavaznék.

Vendor/OS fuggo hogy ki lesz a next-hop (pl.: a nagyobb IP nyer), es igen igy alapbol meg nem fog load-balance-olni ahhoz altalaban kulon engedni kell az ECMP-t es akkor majd megy per flow alapon a load balance (srcIP+port,dstIP+port plus protocol) kb mint az LACP-nel.

A mellett hogy valoban 90-es evek, a VRRP-vel hogyan load-balance-olsz? Szerintem egy bird/frr futtatasa a hoston azert nem egy rocket science.

A mellett hogy valoban 90-es evek, a VRRP-vel hogyan load-balance-olsz?

Azzal önmagában sehogy, mert az rendundancyt biztosít. 

Szerintem egy bird/frr futtatasa a hoston azert nem egy rocket science.

Nem az, de azért összességében szerintem az egész bonyolultabb, hogy össze van növesztve a többi routinggal. Továbbá egyáltalán nem biztos, hogy erre könnyen lehetőség van az adott környezetben, ehhez kell az, hogy az org képes és hajlandó legyen ezt így csinálni. 

> Mondjuk a javaslatból valóban hiányzott egy helyi loadbalancer a szolgáltatás elé.

Így.

> 2023-ban egy bgpd futtatasa bonyolult? Nemar.

És nem, az önmagában nem bonyolult, de egyrészt aztán itt lejjebb te is beismerted, hogy ja, hát persze a bgpd mellé kellene még más is, pl valami, ami monitorozza a backendeket, és basztatja a bgp konfigot. Sőt az is kiderült, hogy tulajdonképpen ha nincs igény a horizontális skálázásra (márpedig sima in-house megoldásoknál sokszor nincs, HA kell), akkor jó az a vrrp+ipvs (ami mellé egyébként nem nagyon kell más körítés, felrakod, bekonfolod, és köszöni, jó lesz).

Másrészt pedig nem a futtatás bonyolult, hanem van, amikor ez "lletve van helyzet amikor nem akarod atforgatni meg a bejovo forgalmat sem plusz gepeken, mert minek?" pont fordítva egyszerűbb. Azért, mert nincs a helyszínen dinamikus routing, a szolgáltatás lehelyezője nem fér hozzá a helyi networkhöz, a gazdája pedig rohadtul nem fog tőle pl hirdetéseket átvenni, meg részt venni a napi üzemeltetésben. Ilyen esetekben egyszerűbb letenni egy keepalived szerű megoldást.

És akkor arról még nem is beszéltünk, hogy az ECMP az csak fabuta round robint tud, ami egy csomó modern workloadnál teljesen jó, egy csomónál meg nem az igazi.

Meg a session stickiness is szükségszerűen megáll L4nél, az sem mindig elég (és igen gyanús, hogy azt már nem triviális mindenféle nw eszközön jól csinálni).

Az van, hogy egyértelmű winner, mindkét megközelítésnek vannak előnye/hátránya/faszsága/létjogosultsága és az ilyen "bruhaha kilencvenes évek, boomer" igazából inkább a szűk látókörű kijelentőjéről állít ki bizonyítványt.

"Így." => a topic eredendoen DNS RR-rol indult.

Keepalived-nel nem kell korites?

"Azért, mert nincs a helyszínen dinamikus routing, a szolgáltatás lehelyezője nem fér hozzá a helyi networkhöz, a gazdája pedig rohadtul nem fog tőle pl hirdetéseket átvenni, meg részt venni a napi üzemeltetésben."
Lehet csak en vagyok szerencses helyzetben, de nalunk egy "PoP" min. par rack, de inkabb cage amibe kapunk aramot meg N darab XC-et a MMR-ba es minden mas hozzank tartozik. Igy azt csinalunk ami nekunk a legjobb.

Az ECMP nem csak RR, lasd lentebb NagyZ kommentjet.

> "Így." => a topic eredendoen DNS RR-rol indult.

És ezért írtam, hogy az LB hiányzott a mondásból?

> Keepalived-nel nem kell korites?

Nem igazán, milyen körítés kell hozzá, amit nem old meg? A vrrp felveszi az IPt, az IPVS része meg elirányítja a trafficot.

> Lehet csak en vagyok szerencses helyzetben, de nalunk egy "PoP" min. par rack, de inkabb cage amibe kapunk aramot meg N darab XC-et a MMR-ba es minden mas hozzank tartozik. Igy azt csinalunk ami nekunk a legjobb.

Igen, abban vagy, ilyen esetben és méretben nyilván megvan hozzá a tapasztalat, az idő kiépíteni, teljes infrát tudtok tervezni, és még oka is van. NagyZ is ilyeneken dolgozik, aztán megy a fikkantás, ha valaki nem az erre való ágyút használja, mikor rohadtul nem is ezt kell neki összerakni.

> Az ECMP nem csak RR, lasd lentebb NagyZ kommentjet.

Melyiket?

A resilient hashingnak nem az RRhez van köze, hanem a stickynesshez, hogy amikor megváltozik a next-hopok száma, attól meglevő kapcsolatok ne rebalancolüdjanak. Attól még az round robin lesz, az új kapcsolatokból jó eséllyel egy ide, egy oda.

Oké lehet, hogy a valóságban nem RR van, hanem a hash algoritmusnak van szép egyenletesen elosztott kimenete, a lényegen nem változtat: egyenletesen tudod szétkenni a bejövő kapcsolatokat az endpointok között. Nem hiszem, hogy fog menni mondjuk egy least connection vagy egy valami csúszóablakos response time, de szerintem még súlyozni se lehet. (És nyilván nem lesz semmi L7 se)

DNS RR-nel minden keresedre RR valasz jon, ECMP-nel per flow tortenik ez, nem per packet, bar egy idoben pl a linux-nal per packet volt a default beallitas.

L7 nem lesz, de cserebe Tbps szinten load-balance-olok egy 1U-os switch-el, es ha kell akkor UCMP-vel finomhangolva a flowkat.

Szerintem nem nagyon értetted a mondandóm lényegét.

Persze, hogy per flow történik ez (ha ez nem lenne, akkor az egész dolog next-to használhatatlan lenne, leszámítva a nagyon egyszerű egy kérdés -- egy válasz udp protokollokat, mint pl a DNS), mert szétfosná a tcp csatornát. A DNS RR meg azért nem (feltétlen) csinál ilyet, mert ott connection szinten használja az eredményt jellemzően a kliens. Illetve ha "folyamatosan" kérdez, akkor a cache miatt ugyanazt fogja kapni. Vedd észre, hogy ott nem a routing csinálja ezt, hanem gyakorlatilag a kliensek hozzáragadnak egy endpointhoz hosszú időre.

A mondandó nem arról szólt, hogy most konkrétan RR, vagy nem, de az ECMP (amennyire az én igen korlátolt tapasztalataim, illetve a doksi alapú megértésem mutatja) csak annyit tud, hogy egyenletesen osztja szét az új connectionoket, ennél többet nem nagy. Tudhatna, de láthatólag éppen az a cél, hogy gyors legyen, és cserébe Tbps szinten load balancolehass egy 1U-s switchel. Ami baromi nagy királyság (tényleg), csak rohadtul nem mindig van ám igény rá.

az, hogy az alap filterek sincsenek fent, es hianyoznak, az nem azt jelenti, hogy nehez oket megcsinalni, csak azt, hogy kurvara lustak voltak megirni rendesen a filtereket.

sok helyen kezzel csinaljak, a helyett, hogy valami toolbol generalnak, hogy ne legyen eselye ennek. 

hat ezert.

Azért még kell health checking is a bird/frr önmagában kevés lesz. Lásd:

https://github.com/unixsurfer/anycast_healthchecker

és akkor még ezeket a problémákat is meg kell oldani (ami persze nem lehetetlen):

https://blog.ipspace.net/2021/05/tcp-anycast-hard.html

A "keepalived" nem véletlenül van elterjedve az L4 LB megoldásokban. all-in-one megoldás vrrp+ipvs+healtcheck egy csomag felrakva + linux kernel és megy mögé egy-két-sok L7 haproxy és kész az LB "stack".

Amellett hogy egyébként az ECMP-nek meg a pure L3 megoldásoknak sok előnye van az L2-es "hackek" (VRRP MAC mizéria  GARP problémák hello) ellenében, nem annyira out-of-the box az "élmény" jelenleg ha te rakod össze az egészet.

Ezt a cikket is érdmes elolvasni gondolatébresztőnek:

https://vincent.bernat.ch/en/blog/2018-multi-tier-loadbalancer

Persze hogy kell korites is melle, a vrrp+ipvs melle is kell ami persze nem rossz, de azt is kell egy ido utan skalazni aminel mar az ECMP jon a kepbe, illetve van helyzet amikor nem akarod atforgatni meg a bejovo forgalmat sem plusz gepeken, mert minek?

Koszi a linket, ismerem Vincent blog-jat valoban jo cikk annak aki meg nem latott/epitett ilyet, mas temaban is erdemes olvasni.

Tisztában vagyok vele. Én is itt hagyok hármat. :)

https://www.juniper.net/documentation/us/en/software/junos/interfaces-e…

https://community.cisco.com/t5/service-providers-knowledge-base/xr-ncs5…

https://docs.kernel.org/networking/nexthop-group-resilient.html

Röviden: Gondold végig, nézz utána, hogy mit garantál a DNS RR és mit nem.

Egyetlen egy dolgot garantál: a DNS szerverre beeső DNS lekérések esetén visszaadja az összes megfelelő rekordot, lekérésenként más-más sorrendben.
Ha az alkalmazás nincs felkészítve erre, akkor nem tud profitálni a DNS RR-ből. Sőt, inkább csak gondot fog okozni - timeout esetén alkalmazásfüggő, hogy az alkalmazás próbálkozik-e a 2., 3., n. rekorddal, esetleg egy új DNS lekérést indít.
Személyes tapasztalatom, hogy az alkalmazások amit "látnak" indításkor, ahhoz fognak ragaszkodni - pl: Java alkalmazás szerver + benne lévő app.
Bármiféle debugot is csak megnehezít a DNS RR.

Igen, de a te esetben arról van szó, hogy elindul az app, csinál egy névfeloldást, majd egy kapott IP-re csatlakozik. És mi történik, ha megszakad a kapcsolat? Igen, ez programozás függő...

De a mi esetünkben arról van szó, mint ahogy a telnetnél is, hogy az app elindul, próbál csatlakozni, ami vagy sikerül, vagy nem, majd megáll. Szóval app szinten esélye sincs cachelni bármit is, és nem kérdés hogy ugyanaz lesz a folyamat a következő indulásnál is, és a tesztek is azt mutatják, hogy valami OS-beli furaság.

"Sose a gép a hülye."

Pedig kéne neki és teszi is.

Tettem egy próbát az index.hu-val (saját DNS serverem van, bind9)

Az ns.index.hu az index.hu DNS servere, magának az ns.index.hu-nak 300-as a TTL-je az authoritatív DNS serveren, az index.hu A rekordnak pedig 60.

És ha a saját serveremen át kérdezem le (ami egyébként az alap), akkor ugyanez van, az első lekérdezésnél az index.hu 60-nal indul, az ns.index.hu 300-zal, és amikor lemegy nullára, ismét az eredeti 60 illetve 300-ról indul. De ha a google DNS-ét kérdezed le, az index.hu-nál ott se látsz 60 felettit.

Ha pedig több lépcsőn jutsz el a DNS lekérdezésig (ritka, de céges hálón előfordulhat, hogy van belső és DMZ DNS), akkor is ez a helyzet.

Mellesleg ha a caching DNS serverek nem vennék át az authoritatív server TTL-jét, akkor nem működnének rendesen a dyndns és hasonló holmik sem, nem lehetne rendesen GSLB-t kialakítani, és nem működne az sem, hogy ha előre tudjuk, hogy DNS-t kell módosítani majd valamikor egy 86400-as TTL-jű rekordon, akkor a gyors átállás miatt egy nappal korábban csökkentsük le a TTL-t.

Arról nyilván nincs részletes információm, hogy az egyes OS-ek cache-ei hogyan kezelik a TTL-t, de azoknak is igazodniuk kéne, lásd a fentieket.

Azért van ennek korlátja.

The default min-cache-ttl is 0 seconds. min-cache-ttl cannot exceed 90 seconds and is truncated to 90 seconds if set to a greater value.

A max-cache-ttl állításával pedig az alacsonyabb TTL nem lesz felülírható, legfeljebb az történik, hogy a cache time alacsonyabb lesz, mint az eredeti TTL érték. 

Nem tudok ilyen helyrol, de pl maga a min-caching-ttl sem volt sokaig resze a kodnak, csak a debian verziojat patcheltek meg, hogy legyen, de mint irtam mas appokkal pl unbound vagy knot nincs ilyen jellegu limit. Szoval a lehetoseg adott es nem tudod mint end-user vagy service operator azt befolyasolni.

Azért van ennek korlátja.

The default min-cache-ttl is 0 seconds. min-cache-ttl cannot exceed 90 seconds and is truncated to 90 seconds if set to a greater value.

A max-cache-ttl állításával pedig az alacsonyabb TTL nem lesz felülírható, legfeljebb az történik, hogy a cache time alacsonyabb lesz, mint az eredeti TTL érték. 

Ezt ajánlom megnézni:

https://youtube.com/playlist?list=PL1Z-ihu8ShDK4rE2xXyPqYywWjmqOyyx-&si…

A part2-t, ill. a teljes DHCP szekciót galád módon azóta letörölte (vagy elrejtette, nem tudom, az a lényeg h. már nem látható publikban). De ha megnézi valaki az elejét és úgy dönt érdekli a folytatás, nekem megvan minden ;)

(Senkit nem érdekelt, felajánlás visszavonva.)

Mit értesz 'aktuális számláló' alatt?

Ha van egy caching DNS server, amelyik közvetlenül hozzáfér a kérdéses zóna DNS serveréhez, akkor a cache-be természetesen a rekord maximális TTL értéke fog bekerülni, elvégre az authoritatív server mindig azt adja vissza. Aztán ezt az értéket fogja csökkenteni.

Viszont ha van egy másik DNS server - mondjuk egy belső caching server -, és ez kérdezi le az előbb említettet - mondjuk már egy csökkentett értékkel - akkor az meg már onnan fog számolni visszafelé.

Ahogy erre egy hasonló topikban próbáltam rávilágítani, csak ott a DNS failover volt felhype-olva, a TTL-re nem szerencsés alapozni. Mi használtunk DNS RR-t több projektben, és remekül működött. A TTL-t 5-10 perc körülire állítottuk, azt szerették már bőven mindenhol, mint minimumot. A valóban nagy számú kliens miatt szépen oszlott el a terhelés az N darab szerver között. Biztosan volt néhány kliens, aki valamit rosszul csinált, de hogy 100 000 userből 99500-nál megy, akkor a többi majd csatlakozik ahova gondolja az N darab IP-ből, nem számít.

A bónusz feature egyébként az, hogy a még béna failovert is kapsz, mert ha kapott IP lista első elemére nem tud csatlakozni, akkor timeout után továbbhalad.

Ha a DNS loadbalance kevés, akkor nézd meg a Cloudflare vonatkozó történetét, mert "egyéniben" ugyan neki lehet fogni, de a loadbalancer rögtön egy szűk keresztmetszet lesz.

Lasz@R-OS cache.

Soha se feltételezd, hogy a túloldal majd azt csinálja a kapott adatokkal, amit elvársz tőle.

Webes fejlesztésnél alap, hogy a szerver küld valamit (header, content), a kilens meg majd a saját defaultjai, user beállításai, meg a felpakolt kiegészítők közös katyvasza alapján majd csinál vele valamit.
De még a "kutya közönséges" DHCP-ben is, ha kicsit több dolgot küld, mint az Ip/netmask/gateway, akkor jó esély van rá, hogy valamelyik kliens nagy ívben tesz rá...

( Adamyno | 2023. 09. 07., cs – 08:00 )

Ha ilyen "furcsa" dologra akadok a hálózaton, az az első, hogy megfogom a Wiresharkot és megnézem, hogy mi történik. Megvolt?

Mert ennek itt a nyomát nem látom.

Ez kellett volna, hogy legyen az első.

A kliens egyáltalán megkéri a DNS szervertől az IPv6 címet? Innen lehet elindulni. Ha nem, miért? Ha igen, mit kap vissza? Miért?

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

( kassaiviktor | 2023. 09. 07., cs – 11:13 )

nekünk volt hasonló. mi a következőt vettük észre:

ha valamire több ip-t kaptunk, akkor az egyiket kiválasztja, és mindaddig azt az ip-t használja, amíg a dns kérés eredményében benne van az az ip is.

hiába vettük le 1 percre a ttl, akkor tényleg indított egy kérést, de az eredményben menne volt a korábban erre használt ip, így azt használta. ha kivettük az addig használt ip-t, akkor már a következő eredményben nem volt benne, akkor hirtelen a másikat kezdte használni. visszaraktuk a régit, és továbbra is a másodikat használta, amivel működött

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

( hnsz2002 v | 2023. 09. 21., cs – 07:49 )

Szerkesztve: 2023. 09. 21., cs – 07:50

Nos pár nap alapján a tapasztalat a következő.

Csak IPv4 címek vannak a név mögött. Emögött jelenleg 2 valós szerver, illetve egy harmadik "kamu" IP cím, szimulálva a halott szervert.

Végignéztem az összes output: az elmúlt pár napban senki de senki meg sem próbált a harmadik kamu IP-re konnektálni.... Teljesen mindegy hogy hol van fizikailag, milyen net mögött, hogy windows vagy linux...

Kurvára nem értem.

"Sose a gép a hülye."

Továbbra is ugyanez a helyzet.

A kérdéses domain DNS kiszolgálása a cloudflare-en van.... Amire még gondolni tudok, hogy emögött van valami csodás algoritmus, vagy valami kliens ip alapján geolokáció, vagy tököm se tudja. Szóval át kéne pakolni valami fapad DNS szerverre (vagy csinálni sajátot) és úgy megnézni.

"Sose a gép a hülye."