Administrace komentářů

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