abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 4
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 22
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 3
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 1
2.12. 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 2
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 771 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Autoritativní DNS server zároveň kešujícím

17.9.2006 10:59 Lukáš Zapletal | skóre: 42 | blog: lzapův svět | Olomouc
Autoritativní DNS server zároveň kešujícím
Přečteno: 168×
Potřebuji nastavit autoritativní DNS servery pro providera, ale jako požadavek mám, aby na těchto serverech jel i caching DNS server.

Obecně se nedoporučuje toto spojení dvou (rozdílnch) služeb. Jaký máte na to názor? Můžu to udělat? S dalšími mašinami se totiž tak nějak nepočítalo...

Odpovědi

17.9.2006 11:14 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
Udělat s bindem to (prý) můžete, s djbdns to udělat nemůžete, a obecně se to nedoporučuje :-)

Další mašiny netřeba, stačí jednomu rozhraní přidělit dvě IP adresy, na jedné poběží DNS server, na druhé DNS cache. Vyzkoušeno s djbdns, funguje to k plné spokojenosti :-)
17.9.2006 11:24 Lukáš Zapletal | skóre: 42 | blog: lzapův svět | Olomouc
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
Ano, tak jste mi potvrdil, že to tak lze udělat :-) Už to nastavuji. Btw jak se pojmenovávají standardně autoritativní dns servery? ns1.firma.cz?
17.9.2006 11:50 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
Třeba :-) djbdns je standardně pojmenovává a.ns.example.com, b.ns.example.com atd.
17.9.2006 12:48 R
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
S BINDom sa to da aj oddelit - ze ako rekurzivny sa bude tvarit len pri pristupe z vnutornej siete alebo z urcitej IPcky.
23.9.2006 21:33 Ondřej Čečák | skóre: 33
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
Motivaci neni aby se to tvarilo oddelene, ale aby to fakt oddelene bylo. ;) Celkem elegantne se to da vyresit pomoci dvou instanci BINDu s cachovaci na privatni, s autoritativni na verejne adrese.
-- "Ja vim, on vi, ty pico!"
17.9.2006 13:27 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
Obecně se nedoporučuje toto spojení dvou (rozdílnch) služeb. Jaký máte na to názor? Můžu to udělat? S dalšími mašinami se totiž tak nějak nepočítalo...

Что такое »obecně«? Kdo konkrétně to nedoporučuje? Čím to zdůvodňuje?

17.9.2006 13:46 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
Konkrétně to nedoporučuje např. DJB – viz The importance of separating DNS caches from DNS servers. Odkazy na další, kteří to nedoporučují, jsou tamtéž.

Zdůvodňuje se to tím, že jsou to dvě různé služby, které, mají-li být bezpečné, musí být v programu stejně striktně odděleny – no a pak už je jedno, jsou-li oddělené i instance toho programu. No a pokud se jedná fyzicky o dva různé programy, jako je tomu u djbdns, nehrozí ani to, že by se data pomíchala nějakou chybou v programu.

U webového serveru a webové proxy cache taky asi nikoho nenapadne provozovat obojí najednou na jedné IP adrese na portu 80, a uvnitř serveru teprve provoz rozdělovat…
17.9.2006 13:57 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
Konkrétně to nedoporučuje např. DJB

Ach so. Tomu se říká "obecně"? Že to nedoporučuje jeden člověk, navíc člověk, který je pověstný svým přezíravým postojem k jakémukoli standardu, který mu nepadl do oka?

Zdůvodňuje se to tím, že jsou to dvě různé služby

To nejsou dvě různé služby. V jeho implementaci možná ano, ale obecně to neplatí.

U webového serveru a webové proxy cache taky asi nikoho nenapadne provozovat obojí najednou na jedné IP adrese na portu 80, a uvnitř serveru teprve provoz rozdělovat…

To není dobrý příklad, HTTP a DNS fungují naprosto odlišně. HTTP je protokol, u kterého jsou cache pouze jakýmsi přívažkem navíc, dokonce bych se nestyděl říci, že dnes už spíš historickým reliktem, který dělá víc škody než užitku. DNS je protokolem, který je už od základu postaven na tom, že se většina klientů neptá autoritativních zdrojů, ale zprostředkovatelů. A i když by čistě teoreticky mohlo DNS fungovat bez použití cachovacích nameserverů, prakticky žádná implementace klienta to neumí a silně pochybuji, že by to zvládly třeba takové kořenové nameservery.

17.9.2006 15:44 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
Konkrétně to nedoporučuje např. DJB

Ach so. Tomu se říká "obecně"? Že to nedoporučuje jeden člověk, navíc člověk, který je pověstný svým přezíravým postojem k jakémukoli standardu, který mu nepadl do oka?

V odkazovaném článku jsou citace dalších 3 lidí od BINDu… A to "nepadnutí do oka" standardů, které jsou na tom špatně s bezpečností se zatím docela vyplácí, jeho programy se ve výčtech bezpečnostních chyb v sw objevují zřídka… To moje "obecně" byla narážka na původní dotaz, obecně se bohužel opravdu považuje za normální mít cahovací i autoritativní nameserver na jedné IP adrese; obecně se taky považuje normální mít všechny autoritativní servery jedné domény na jednom fyzickém stroji s jednou konektivitou, dvě IP adresy jsou přidělené jen aby to prošlo testem správce TLD; záložní mail server se taky obecně považuje za přežitek.
Zdůvodňuje se to tím, že jsou to dvě různé
služby

To nejsou dvě různé služby. V jeho implementaci možná ano, ale obecně to neplatí.

Implementace, která by se chovala stejně k autoritativním záznamům i ke kešovaným záznamům, by nestála za moc. Třeba přepisovat autoritativní údaje zadané adminem tím, co jako cache někde splaší na internetu, a pak to dál publikovat jako autoritativní údaje, to by asi nebylo moc šťastné.
U webového serveru a webové proxy cache taky asi nikoho nenapadne provozovat obojí najednou na jedné IP adrese na portu 80, a uvnitř serveru teprve provoz rozdělovat…

To není dobrý příklad, HTTP a DNS fungují naprosto odlišně. HTTP je protokol, u kterého jsou cache pouze jakýmsi přívažkem navíc, dokonce bych se nestyděl říci, že dnes už spíš historickým reliktem, který dělá víc škody než užitku. DNS je protokolem, který je už od základu postaven na tom, že se většina klientů neptá autoritativních zdrojů, ale zprostředkovatelů. A i když by čistě teoreticky mohlo DNS fungovat bez použití cachovacích nameserverů, prakticky žádná implementace klienta to neumí a silně pochybuji, že by to zvládly třeba takové kořenové nameservery.

Ale to, jestli se s cache počítá nebo nepočítá v návrhu protokolu ještě nevypovídá nic o tom, jestli je primární zdroj dat a cache to samé, nebo jsou to dvě různé služby. Ostatně standard HTTP s proxy cache počítá, jenom se v praxi používají o něco méně. Historickým reliktem nejsou v žádném případě, a škodu dělají pouze pokud jsou špatně implementovány, nebo je špatně implementována zdrojová webová aplikace.
17.9.2006 17:07 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
A to "nepadnutí do oka" standardů, které jsou na tom špatně s bezpečností se zatím docela vyplácí

Ale no tak, vážně mi chcete namlouvat, že všechno, co se panu Bernsteinovi nelíbí, je problematické z bezpečnostního hlediska? Co si tak matně vzpomínám, třeba RFC 2317 (reverzní lookup pro classless rozdahy) nebo záznamy pro IPv6 jsou bezpečnostně problematické?

jeho programy se ve výčtech bezpečnostních chyb v sw objevují zřídka

To je sice pravda, ale na druhou stranu jsou také ve své čisté podobě většinou prakticky nepoužitelné, takže většina uživatelů je nucena používat verze upravené třetími stranami - a od těch už samozřejmě DJB dává ruce pryč, takže mu nekazí statistiky. Navíc jeho produkty kvůli licenčním problémům nenajdete v distribucích, což dále omezuje jejich nasazení. V tomto konkrétním případě jsem navíc hodně alergický na porovnávání BINDu a djbdns, kdy se BINDu jako přitěžující okolnost přičítají problémy verze 4, což byl de facto úplně jiný program, navíc v době, kdy žádný djbdns ještě neexistoval. V okamžiku, kdy se začne porovnávat porovnatelné, už ty statistiky tak efektně nevypadají.

obecně se taky považuje normální mít všechny autoritativní servery jedné domény na jednom fyzickém stroji s jednou konektivitou

To se rozhodně obecně za normální nepovažuje, většina systémáků, pokud takovou věc nasadí, dělá to spíš z donucení manažery.

záložní mail server se taky obecně považuje za přežitek

Záložní mail exchanger se nepovažuje za přežitek, ale v současné době, kdy je několikadenní výpadek konektivity záležitostí naprosto mimořádnou, je jeho potřeba podstatně nižší než dříve. Navíc (na rozdíl od NS záznamů) nevím o žádném RFC, které by nařizovalo, že doména přijímající poštu má mít aspoň dva MX záznamy. A konečně, pokud se sekundární mail exchanger nenasazuje, nebývá to důsledek neznalosti nebo odmítání standardů, ale výsledek logické analýzy problému. Jde např. o to, že zatímco finální příjemce pošty může mail pro neexistující schránku hned v reakci na 'MAIL From:' rovnou odmítnout s pětkovým kódem, záložnímu nezbývá než ho přijmout a zkusit doručit na primární; ten mu ho teprve omlátí o hlavu a chudák záložní, chce-li se chovat korektně, navíc nějakého nevinného chudáka obšťastní nesmyslným hlášením o nedoručitelnosti. Proto velká část spammerů posílá své výtvory rovnou na záložní mail exchanger; sice tím podle mne nic nezískají, ale reálná pozorování ukazují, že to tak je. Bohužel, SMTP protokol je v dnešní době svou koncepcí naprostým anachronismem, ale v dohledné době lze jen těžko očekávat jeho nahrazení něčím, co by více odpovídalo současným podmínkám.

Implementace, která by se chovala stejně k autoritativním záznamům i ke kešovaným záznamům, by nestála za moc. Třeba přepisovat autoritativní údaje zadané adminem tím, co jako cache někde splaší na internetu, a pak to dál publikovat jako autoritativní údaje, to by asi nebylo moc šťastné.

To ale nemění nic na tom, zda se jedná o dvě různé služby. Jedná se o jednu službu, která používá jeden protokol, je definována jednou sadou RFC a má přidělen jeden rezervovaný port (OK, dva, jeden UDP a jeden TCP). Stejně jako nejsou dvě různé služby MTA fungující jako relay pro poštu odcházející z lokální sítě a MTA přijímající poštu pro doménu jen proto, že tyto role lze oddělit a mnohdy tak oddělené jsou. Celý protokol je postaven na principu, že se kteréhokoli nameserveru a priori můžete zeptat na jakýkoli záznam (samozřejmě to neznamená, že vám odpoví), u vámi zmíněného HTTP je to úplně jinak.

Historickým reliktem nejsou v žádném případě, a škodu dělají pouze pokud jsou špatně implementovány, nebo je špatně implementována zdrojová webová aplikace.

Některé škody páchají proxy zcela systémově (např. výrazně komplikují snahy o traffic control, jiné jsou skutečně většinou chybou implementace, ale na rozdíl od vás vídám chyby nejen na straně webových aplikací). Např. nedávno jsem tu s někým absolvoval poměrně dlouhou debatu, kde dotyčný tvrdošíjně obhajoval deklarování HTTP/1.0 v hlavičce dotazu kvůli proxy, a to i u dotazů, obsahujících prvky HTTP/1.1 (např. hlavička Host:), přestože se jedná o jednoznačné porušení RFC. A pak jsou tu škody morální, kdy proxy pomáhá v uživatelích deformovat představu, co je to vlastně Internet - např. tento týden jsem zrovna školil ve firmě, kde mne předem tvrdili, že učebna je připojena na Internet; realita byla taková, že byl přístup pouze na web, a to ještě přes proxy (autentizovanou). Historicky měly proxy smysl hlavně kvůli omezení datového toku, dnes už je podle mých zkušeností tento efekt zanedbatelný, takže zbývá jen použití k filtraci nebo auditování HTTP provozu.

17.9.2006 17:11 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
…kde mne předem tvrdili…

Samozřejmě "mi", původně jsem tam měl jiné sloveso a opravil jsem jen půlku.

17.9.2006 20:20 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
Co si tak matně vzpomínám, třeba RFC 2317 (reverzní lookup pro classless rozdahy) nebo záznamy pro IPv6 jsou bezpečnostně problematické?
Existuje spousta doplňujících RFC okolo DNS, ale snad nemusí každý DNS server tato rozšiřující RFC implementovat? A záznamy pro IPv6 djbdns IMHO umí.

To je sice pravda, ale na druhou stranu jsou také ve své čisté podobě většinou prakticky nepoužitelné, takže většina uživatelů je nucena používat verze upravené třetími stranami - a od těch už samozřejmě DJB dává ruce pryč, takže mu nekazí statistiky. Navíc jeho produkty kvůli licenčním problémům nenajdete v distribucích, což dále omezuje jejich nasazení. V tomto konkrétním případě jsem navíc hodně alergický na porovnávání BINDu a djbdns, kdy se BINDu jako přitěžující okolnost přičítají problémy verze 4, což byl de facto úplně jiný program, navíc v době, kdy žádný djbdns ještě neexistoval. V okamžiku, kdy se začne porovnávat porovnatelné, už ty statistiky tak efektně nevypadají.
Upravené verze djbdns neznám a nenapadá mne nic, kvůli čemu by bylo pro většinu uživatelů nepoužitelné. Rád se nechám poučit, co neumí. BINDu jsem jako přitěžující okolnost nepočítal verzi 4, ale několik dní starý problémy a druhý.
Záložní mail exchanger se nepovažuje za přežitek, ale v současné době, kdy je několikadenní výpadek konektivity záležitostí naprosto mimořádnou, je jeho potřeba podstatně nižší než dříve.
To jsme si myslel taky, ovšem po zkušenostech provozování serveru za ADSL jsem to přehodnotil – týdenní výpadek vznikne třeb atak, že ČTc zavádí ADSL linku někomu novému a omylem stávající linku přepojí k jinému operátorovi. Ale případ je to doufám ojedinělý…
Jde např. o to, že zatímco finální příjemce pošty může mail pro neexistující schránku hned v reakci na 'MAIL From:' rovnou odmítnout s pětkovým kódem, záložnímu nezbývá než ho přijmout a zkusit doručit na primární;
Záložní mail server může porovnat adresáta s replikou databáze účtů z doby, kdy byl ještě primární server on-line, a odmítnout ho stejně jako primární.
To ale nemění nic na tom, zda se jedná o dvě různé služby. Jedná se o jednu službu, která používá jeden protokol, je definována jednou sadou RFC a má přidělen jeden rezervovaný port (OK, dva, jeden UDP a jeden TCP). Stejně jako nejsou dvě různé služby MTA fungující jako relay pro poštu odcházející z lokální sítě a MTA přijímající poštu pro doménu jen proto, že tyto role lze oddělit a mnohdy tak oddělené jsou. Celý protokol je postaven na principu, že se kteréhokoli nameserveru a priori můžete zeptat na jakýkoli záznam (samozřejmě to neznamená, že vám odpoví), u vámi zmíněného HTTP je to úplně jinak.
HTTP je taky jedna služba, jeden protokol, jeden port, a přesto bývá zvykem oddělovat jednotlivé způsoby využití tohoto protokolu do různých programů.
Některé škody páchají proxy zcela systémově (např. výrazně komplikují snahy o traffic control, jiné jsou skutečně většinou chybou implementace, ale na rozdíl od vás vídám chyby nejen na straně webových aplikací).
Proxy se dnes daleko víc než dříve používají i na serverové straně, kde rozhodně mají svůj význam. Komplikace s traffic control je IMHO jenom v tom, že příslušná proxy na tohle není připravená - systémový problém v tom nevidím. Ale rád se nechám poučit. Že jsou chyby v implementaci i na straně proxy serverů máte pravdu, zapomněl jsem na všechny ty proxy pro Windows…
Např. nedávno jsem tu s někým absolvoval poměrně dlouhou debatu, kde dotyčný tvrdošíjně obhajoval deklarování HTTP/1.0 v hlavičce dotazu kvůli proxy, a to i u dotazů, obsahujících prvky HTTP/1.1 (např. hlavička Host:), přestože se jedná o jednoznačné porušení RFC.
Porušení RFC to není, RFC 1945 připouští existenci experimentálních a testovacích hlaviček sémanticky odpovídajících prvkům hlavičky HTTP. Ostatně hlavička Host: se používala už před vznikem HTTP/1.1. Ona taky implementace HTTP/1.1 není zrovna triviální a často se používá naopak verze HTTP/1.1, aniž by dotyčný program tuto verzi skutečně implementoval. Nicméně zrovna proxy by měla být schopná akceptovat co nejvíc různých možností a tedy by jí HTTP/1.1 nemělo překvapit…
A pak jsou tu škody morální, kdy proxy pomáhá v uživatelích deformovat představu, co je to vlastně Internet - např. tento týden jsem zrovna školil ve firmě, kde mne předem tvrdili, že učebna je připojena na Internet; realita byla taková, že byl přístup pouze na web, a to ještě přes proxy (autentizovanou).
Pokud to byla proxy autentizovaná, nemohla být transparentní, a tudíž ten element, který deformoval představu o internetu, byl firewall, nikoli proxy :-)
17.9.2006 21:35 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
To jsme si myslel taky, ovšem po zkušenostech provozování serveru za ADSL jsem to přehodnotil

Mám-li být upřímný, provozovat server na ADSL - a zvláště na ADSL od ČTc - mi připadá daleko zvrácenější než mít jen jeden MX záznam.

Porušení RFC to není, RFC 1945 připouští existenci experimentálních a testovacích hlaviček sémanticky odpovídajících prvkům hlavičky HTTP. Ostatně hlavička Host: se používala už před vznikem HTTP/1.1. Ona taky implementace HTTP/1.1 není zrovna triviální a často se používá naopak verze HTTP/1.1, aniž by dotyčný program tuto verzi skutečně implementoval.

RFC 2616 a 2145 o tom ovšem říkají něco jiného.

17.9.2006 22:02 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
Mám-li být upřímný, provozovat server na ADSL - a zvláště na ADSL od ČTc - mi připadá daleko zvrácenější než mít jen jeden MX záznam.
Ono to mělo složitou historii. Původně to bylo bezdrátové připojení (Breezenet), ale ADSL bylo výrazně levnější, a ve školství rozhoduje cena především. A vzdálenost cca 200 metrů od ústředny vypadala, že by to mělo bez problémů fungovat. Mimo tohoto skoro týdenního výpadku (způsobeného nejspíš ČTc, al enáš ISP se taky zrovna nepředvedl) se však ADSL linka ukázala jako dobrý indikátor počasí (když bylo dlouho sucho, nebo dlouho pršelo, modem nedokázal udržet spojení).

No a hostovat někde okolo 300 e-mailových schránek, kde každá má minimálně jeden alias a okolo 70 schránek se za rok změní (vzniknou nebo zaniknou), to by asi byla taky pěkná zábava…
Porušení RFC to není, RFC 1945 připouští existenci experimentálních a testovacích hlaviček sémanticky odpovídajících prvkům hlavičky HTTP. Ostatně hlavička Host: se používala už před vznikem HTTP/1.1. Ona taky implementace HTTP/1.1 není zrovna triviální a často se používá naopak verze HTTP/1.1, aniž by dotyčný program tuto verzi skutečně implementoval.
RFC 2616 a 2145 o tom ovšem říkají něco jiného.
A co o tom říkají? RFC 2145 definuje HTTP/1.1, HTTP/1.0 se netýká. A RFC 2616 doporučuje, kdy se jaká verze protokolu má použít – ovšem ani tam nevidím, co by na použití hlavičky Host: v HTTP/1.0 bylo špatného. Neznám ta RFC zpaměti, ale nenapadá mne nic, v čem by byl problém…
23.9.2006 21:38 Ondřej Čečák | skóre: 33
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
"záložnímu nezbývá než ho přijmout a zkusit doručit na primární; ten mu ho teprve omlátí o hlavu a chudák záložní, chce-li se chovat korektně, navíc nějakého nevinného chudáka obšťastní nesmyslným hlášením o nedoručitelnosti."

Zalozni nemusi byt prece jenom tak nestastny, muze si predem dorucitelnost overit a pak dokonce odesilateli odpovedet kodem se stejnym dopadem. Ano, sice to nebude fungovat v pripade vypadku primaru, ale to nas trapit nemusi -- porad budeme radi za emaily u nas ve fronte ... Nemluve o tom, ze zalozni mailserver take muze umet dorucovat primo. Ale to jen tak na okraj. ;)
-- "Ja vim, on vi, ty pico!"
17.9.2006 21:26 jm
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
Konkrétně to nedoporučuje např. DJB
No, tak v tom pripade to beru jako vrele doporuceni. :-D
17.9.2006 21:34 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Autoritativní DNS server zároveň kešujícím
OK, používám djbdns, Gentoo Linux a programuju v Javě – ale jinak jsem úplně normální :-)

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.