Portál AbcLinuxu, 5. května 2025 16:43
Spise se podivuji nad tim, ze dve miliardy jedincu vycerpaji tolik adres tak rychle.Vždyť na dvě miliardy jedinců je těch adres krutě málo :).
Opravdu? IPv4 adres jsou celkem 4 miliardy. Účinnost alokace nemůže být 100%, ale i kdyby, tak když na světě je 7 miliard lidí, z nich tak půlka ve světě, kde je elektřina a možná i Internet, a v „nejrozvinutějších“ zemích má kde kdo počítač, notebook, smartphone a televizi s připojením k Internetu, tedy 4 zařízení na jednoho člověka… jak to může stačit?
takze ve vysledku 99% poskytovatelu(jak internetu, tak serveroven) ma svych ip adres dostatek na dalsich 10let.
To nevím, 99% poskytovatelů jsem se neptal, ale mému lokálnímu ISP došly adresy už v době, kdy jsem tam pracoval (a to já sám mám pouhých 8 adres, což mi nestačí). Co se týče poskytovatelů obsahu, tak se topíme a chytáme posledních stébel. Zrovna teď řeším rozdělení našeho provider independent rozsahu na dvě serverovny. Jedna ze dvou našich serveroven už nemá ani jednu volnou ipv4. Chudáci BGP routery, když se to už teď seká na /24 rozsahy. Takže to imho bude docházet velice rychle.
nemuzou mit https
To není tak úplně pravda, jde to, ale není to úplně bez problémů (a musejí mít společný certifikát).
natoz domene odpovidajici reverzni zaznam
Pokud je to řešeno CNAME záznamem, tak není potřeba. Spíš je problém v tom, že je pro rozlišení webů potřeba analyzovat hlavičku, což je jednak neefektivní, jednak komplikuje např. možnost použít různý SW pro jednotlivé weby.
už samotnou identifikaci virtuálního serveru na základě něčeno, co se dozvím až z protokolu aplikační vrstvy považuji za nešťastnou.Mě to přijde zhruba stejně nešťastné jako samotné virtuální servery rozlišované jménem - pokud už používáme ty, nevidím důvod s nimi nepoužívat SNI/StartTLS.
Mě to přijde zhruba stejně nešťastné jako samotné virtuální servery rozlišované jménem
Tím "něčím, co se dozvím až z protokolu aplikační vrstvy" jsem myslel právě hodnotu položky Host
v hlavičce HTTP requestu.
Není to zbytečné dávat tam odpovídající počet IP adres a rozlišovat to podle nich?
To je právě to myšlení zdeformované životem ve světě, kde je IP adresa vzácný statek, kterým se musí úzkostlivě šetřit.
v DNS typicky hvězdička a aplikace pak doménové jméno používá pro svoji parametrizaci
Musím se přiznat, že wildcard záznamy považuji za velice nešťastný úlet. Většina z těch, kdo je {po,zne}užívají, má pouze mlhavou představu, jak opravdu fungují, což často vede k problémům. Takže tenhle use case mne moc nepřesvědčí.
byť někdy to jako nouzové řešení smysl má – pro případy, kdy nelze informaci o kódování předat jinak
Jenže aby to mělo vůbec šanci fungovat, je potřeba předpoklad, že text z ASCII bude kódován stejně jako v ASCII. Což ne všechna kódování splňují.
To je právě to myšlení zdeformované životem ve světě, kde je IP adresa vzácný statek, kterým se musí úzkostlivě šetřit.No, jenom, jestli není problém v tom, že se z DNS stalo v podstatě jenom něco pro zajištění funkčnosti vé vé vé něco cé zet. Jako je pravda, že představa hostingového serveru s tisícem IP adres je minimálně nezvyklá, ale proč ne.
Většina z těch, kdo je {po,zne}užívají, má pouze mlhavou představu, jak opravdu fungují, což často vede k problémům.A tady bych se zase rád nechal poučit, co se může stát, když nastavím
* CNAME někam
.
co může způsobit nešťastná kombinace wildcard záznamu a search domény v resolveru.A IPv6 a odděleného resolvingu IPv6 a IPv4? Že by popsali mojí oblíbenou chybu podmíněnou třemi různými okolnostmi? Neočekávané chyby prodokují i další RFC okolo resolvingu. Třeba současné getaddrinfo() podle RFC si téměř hází korunou, zda bude resolvovat lokální adresy (::1, 127.0.0.1, localhost, localhost4, localhost6) či nikoli. GLIBC to vylepšuje ještě o chybu v implementaci této chyby, takže se ta chyba v RFC kvůli té chybě v implementaci v některých případech neobjeví. Protože je ale to stejné RFC v jiném ohledu zcela nedomyšlené, ve Fedoře je do GLIBC patch, který tu chybu (v RFC) prozměnu rozšiřuje na linkové adresy. Krásná kombinace tří oblastí, kde se dá něco posrat, tedy ve standardu, v upstream implementaci a v distribučních patchích. Tentkráte úspěch hned trojnásobný.
A IPv6 a odděleného resolvingu IPv6 a IPv4? Že by popsali mojí oblíbenou chybu podmíněnou třemi různými okolnostmi?
Ne, tohle je starší věc, ke které IPv6 není potřeba. V podstatě jde o to, že když si někdo jako search doménu nastaví takovou, ve které je wildcard záznam, může se pak ten záznam aplikovat i na dotazy na jména z úplně jiných domén.
Do resolveru v glibc jsem se byl nucen ponořit zatím třikrát, z toho dvakrát do jeho nejděsivější části, funkce send_dg()
. Nemůžu říct, že jsem nikdy neviděl nic horšího, to bych zase přeháněl, ale zjištění, jaké hrůzy se mohou nacházet v tak základní komponentě systému, mnou hluboce otřáslo. Když jsem pak zjistil, že parser /etc/hosts
má zadrátováno, že hledá-li IPv4 adresu, tak si automaticky překládá "::1
" na "127.0.0.1
", a přečetl si tuhle diskusi, ztratil jsem poslední zbytky iluzí.
Ne, tohle je starší věc, ke které IPv6 není potřeba. V podstatě jde o to, že když si někdo jako search doménu nastaví takovou, ve které je wildcard záznam, může se pak ten záznam aplikovat i na dotazy na jména z úplně jiných domén.To je v podstatě to, co se děje v tom mém případě, takže by se to dalo chápat jako variace na ten stejný problém.
Když jsem pak zjistil, že parser /etc/hosts má zadrátováno, že hledá-li IPv4 adresu, tak si automaticky překládá "::1" na "127.0.0.1", a přečetl si tuhle diskusi, ztratil jsem poslední zbytky iluzí.Fascinující.
a search domény v resolveruBTW: používáte tohle někdo nějakým rozumným a zajímavým způsobem? Něco jiného, než že jsou uživatelé líní psát FQDN? Napadá mne třeba využití pro nalezení nejbližšího distribučního serveru – vždy se použije ten místní, podle toho, kde člověk zrovna je. Ale v praxi jsem to ještě neviděl (v praxi jsem viděl akorát bordel resp. zbytečnost, že jeden stroje dostupný pod dvěma názvy).
Napadá mne třeba využití pro nalezení nejbližšího distribučního serveru – vždy se použije ten místní, podle toho, kde člověk zrovna je.
To je zajímavá myšlenka. Jen by se asi musel dávat pozor na to, že takový notebook (nebo jiné mobilní zařízení) se občas vyskytuje i v cizí (tj. potenciálně nepřátelské) síti.
xxx
, resp. to zadal uživatel, tak se podle toho má i kontrolovat certifikát – nemá se kontrolovat xxx.example.com
. Pro tyhle interní účely není problém si vystavit certifikát platný pro oba tvary.
To ale není chyba těch aplikacíS tím souhlasím. Neexistuje na to žádný standardizovaný postup.
Adresy se neprideluji lidem, ale pocitacum, jeden clovek vyuziva dnes vic pocitacu - jeden doma, druhy v praci a navic dnes ma ethernetove pripojeni kazda druha spotrebni elektronikaNa druhou stranu v době, když nastoupil tento trend (spotřební elektronika s IP konektivitou), byly už IP adresy lehce nedostatkové zboží a domácí uživatel byl rád, když měl jednu veřejnou IP (a na ní si udělal NAT, za který schoval všechna zařízení v domácnosti). A v horším případě mu dělal NAT poskytovatel a uživatel neměl veřejnou IP vůbec. Takže tohle IMHO na vyčerpání IPv4 adres vliv nemělo (ale je to argument pro používání IPv6).
Ja sam (ac nejsem reprezentativni vzorek) pouzivam asi 8 verejnych IP adres.Ahá, tak tady ty adresy mizí
Ahá, tak tady ty adresy mizíMně to nepřijde tak nereálné - může mít počítač, notebook, smartphone, televizi, zabezpečovačku, IP telefon, IP kameru, počítač v práci, APčko, server… asi ne všechno najednou, ale těch 8 se klidně nasbírá. Nebo kdybych chtěl mít ve všech sítích, kde se vyskytuju, pevně alokovanou IP.
a v jeho internej sieti sa o IPv6 este ani nechyruje...To se mi tak úplně nezdá, oni řeší IPv6 z jiných důvodů.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.