Na tomto blogu vás pravidelně informujeme o postupu podpisu kořenové zóny (Už jen jeden!, Více než polovina, první, a úvod). Dnes došlo k podepsání posledního kořenového serveru: J.root-servers.net od dnešního dne nese kořenovou zónu podepsanou pomocí DNSSECu.
Kořenová zóna je stále podepsána klíčem a podpisy, které nelze validovat (tzv. DURZ). Ale i tak je podpis posledním krůčkem potřebným pro finální podepsání kořenové zóny validním klíčem, které má proběhnout 1. 7. 2010. Postupné nasazení DURZ – podepsané kořenové zóny na jednotlivé nameservery, bylo zapotřebí pro ověření, že zvětšení DNS zpráv nezpůsobí žádné velké operační problémy. Až na lehké zvýšení TCP provozu na kořenové nameservery po podepsání dvanácti nameserverů ze třinácti to zatím nevypadá, že by nějaké problémy měly nastat. Ale to ukáží následující hodiny.
Takže velké díky týmu, který pracoval na podpisu kořenové zóny a další velký úkol na ně čeká na začátku prázdnin.
Ondřej Surý
Jaký DNS server používáte pro DNSSEC?
V souvislosti s podpisem kořenové zóny, který bude používat novější algoritmy klíče (RSA-SHA256), o kterém jsem referoval já (zde) i kolega Ondřej Filip (tady a tady), a také především chybnou nebo neexistující podporou záznamů NSEC3 v nižších verzích serveru Bind, bychom se vás rádi zeptali, jaký DNS server a jakou verzi DNS serveru používáte pro poskytování DNSSECu na straně autoritativního serveru, a jakou verzi DNS serveru používáte pro validaci DNSSEC záznamů.
V anketě můžete zatrhnout i více voleb.
Jaký DNS server používáte pro DNSSEC?
- Bind 9.6.x (33%, 23 Votes)
- Bind 9.5.x (26%, 18 Votes)
- Bind 9.7.x (13%, 9 Votes)
- Unbound 1.4.x (12%, 8 Votes)
- Bind 9.3.x (12%, 8 Votes)
- Bind 9.4.x (9%, 6 Votes)
- NSD 3.2.x (9%, 6 Votes)
- Microsoft DNS (7%, 5 Votes)
- Unbound 1.2.x (1%, 1 Votes)
- NSD 3.0.x (1%, 1 Votes)
- Jiný (prosíme napište do komentářů jaký) (0%, 0 Votes)
- CNS (0%, 0 Votes)
- ANS (0%, 0 Votes)
- NSD 3.1.x (0%, 0 Votes)
- Unbound 1.3.x (0%, 0 Votes)
- Unbound 1.1.x (0%, 0 Votes)
- Unbound 1.0.x (0%, 0 Votes)
Total Voters: 81
Nahrávání ...Užitečné rozšíření DNS nebo cesta špatným směrem?
V poštovní konferenci pracovní skupiny DNSEXT, která se zabývá rozšiřováním protokolu DNS, aktuálně probíhá bouřlivá diskuze nad novým návrhem Client IP information in DNS requests (neboli Informace o klientské IP adrese v DNS dotazech). Tento návrh společně podaly společnosti Google a Neustar. Google před nedávnou dobou spustil svou službu Google Public DNS, a tudíž představuje zástupce provozovatele veřejného resolveru. Neustar stojí na opačném konci, kromě provozu několika TLD, provozují také autoritativní DNS servery, které získali akvizicí firmy UltraDNS. To jen tak na vysvětlenou, co mají tyto dvě firmy společného s DNS.
Tento návrh přidává do DNS zprávy volitelnou položku, která obsahuje IP adresu (resp. adresu sítě) klienta, který položil dotaz rekurzivnímu resolveru. Možná vás teď napadá otázka, k čemu je tato informace autoritativnímu DNS serveru dobrá? Obecně k ničemu. Tento návrh přinese užitek pouze malé skupině provozovatelů DNS serverů – hlavní využití by tento návrh měl při distribuci obsahu (CDN), kdy už v dnešní době dochází na základě IP adresy rekurzivního resolveru k přizpůsobení odpovědi, kterou poskytne autoritativní DNS server. Typickým příkladem je například právě Google.
Pokud se zeptám na adresu www.google.com ze svého pracovního počítače (tedy aktuálně s IP adresou přidělenou CZ.NICu), dostanu tuto odpověď:
www.google.com. IN CNAME www.l.google.com.
www.l.google.com. IN A 74.125.87.105
www.l.google.com. IN A 74.125.87.147
www.l.google.com. IN A 74.125.87.99
www.l.google.com. IN A 74.125.87.104
www.l.google.com. IN A 74.125.87.103
Pokud se zeptám z našeho DNS serveru v Londýnském LINXu, dostanu odpověď úplně jinou:
www.google.com. IN CNAME www.l.google.com.
www.l.google.com. IN CNAME www-tmmdi.l.google.com.
www-tmmdi.l.google.com. IN A 216.239.59.99
www-tmmdi.l.google.com. IN A 216.239.59.103
www-tmmdi.l.google.com. IN A 216.239.59.147
www-tmmdi.l.google.com. IN A 216.239.59.104
Náš DNS uzel v Kaliforni vidí opět jiné IP adresy:
www.google.com. IN CNAME www.l.google.com.
www.l.google.com. IN A 74.125.87.99
www.l.google.com. IN A 74.125.87.103
www.l.google.com. IN A 74.125.87.104
www.l.google.com. IN A 74.125.87.105
www.l.google.com. IN A 74.125.87.147
Těmito DNS triky se dá geograficky rozložit zátěž mezi různé lokality. S příchodem veřejných otevřených rekurzivních resolverů (provozovaných jako služba) ovšem nastává problém. Jak budou vypadat stejné dotazy ze stejných lokalit, když začnu používat například servery OpenDNS.
Z Čech:
www.google.com. IN CNAME google.navigation.opendns.com.
google.navigation.opendns.com. IN A 208.69.34.230
google.navigation.opendns.com. IN A 208.69.34.231
Z Kalifornie:
www.google.com. IN CNAME google.navigation.opendns.com.
google.navigation.opendns.com. IN A 208.67.219.230
google.navigation.opendns.com. IN A 208.67.219.231
Přesměrováním na vlastní server OpenDNS řeší problém, který představuje neschopnost předat informaci o lokaci DNS klienta autoritativnímu serveru, k přesměrování dochází teprve na úrovni HTTP protokolu. Mimochodem všimněte si, jak OpenDNS bez zeptání vstupuje do vašeho DNS provozu. O důvod více, proč používat DNSSEC a nepoužívat OpenDNS.
Google se svou službou Google Public DNS řeší stejný problém. Sám pro sebe by tento protokol nepotřeboval, protože informaci o klientovi má, nicméně dalším třetím stranám ji není schopný předat.
Návrh, o kterém se aktuálně diskutuje v pracovní skupině DNSEXT, tento problém řeší přidáním volitelné (EDNS0 option) informace o klientské IP adrese, jak v DNS dotazu, tak v DNS odpovědi. Bez hlubšího zamyšlení se může tento nápad jevit jako dobrý. Nicméně pokud se zamyslíme nad dalšími souvislostmi, tak objevíme několik důvodů, proč by tento návrh neměl projít.
Důvod první: Myslím si, že změny důležitých protokolů jako je DNS, by neměly probíhat kvůli zájmům malé skupiny uživatelů tohoto protokolu. Celý návrh je šitý na míru několika málo poskytovatelům veřejných DNS resolverů, které se ptají autoritativních DNS serverů, které používají (dle některých špinavé) triky pro distribuci různého obsahu. Vnímám tento návrh jako nekoncepční, protože se snaží dolepit do DNS protokolu funkci, na kterou nebyl tento protokol postaven.
Důvod druhý: Lokalizace obsahu dle IP adresy není příliš spolehlivá. Pravděpodobně funguje ve většině případů, ale například nerozumím tomu, proč mě stránka google.com tvrdošíjně přesměrovává na www.google.cz a mluví na mne česky i přesto, že mám v nastavení prohlížeče nastaveno, že chci zobrazovat stránky v jazyce anglickém. Při cestě do zahraničí mají některé stránky (nejen google.com) tendenci na mne mluvit jazykem země, ve které se aktuálně nacházím. A mnohdy bývá problematické z této lokalizační pasti uniknout a dostat se alespoň na anglickou verzi stránek.
Důvod třetí: Celý návrh je postavený jako opt-out. Pokud si klient nepřeje, aby resolver předával informaci o jeho IP adrese, může stejnou cestou předat speciální IP adresu 0.0.0.0/0, kterou by měl resolver ctít a předat ji v této formě dále. Bohužel to ovšem znamená, že pokud nechcete, aby se autoritativní server dozvěděl vaši IP adresu, musíte mít podporu pro tuto volbu implementovanou ve vašem operačním systému. Osobně tento důvod vnímám jako nejzávažnější, protože mění stávající stav a nutí všechny uživatele k aktualizaci, která ani nemusí být dostupná.
Důvod čtvrtý: Kolegyně Zuzana v předchozím příspěvku o Dni ochrany osobních údajů psala o tom, jak se soukromý prostor postupně mění v prostor veřejný. Tento návrh ubírá další kousíček soukromí, tedy předává informaci, kterou v tuto chvíli měl pouze resolver dalším třetím stranám (provozovatelům autoritativních DNS). Navíc o tom, zda-li dochází k tomuto předávání vaší IP adresy, se nemáte nikterak šanci dozvědět, alespoň současná verze návrhu žádné takové rozšíření neobsahuje.
Jak to bude vypadat dále? Pracovní skupiny v IETF pracují na principu konsenzu. Pokud už se musí hlasovat, tak se hlasuje hučením. Google je sice silný hráč, ale do pracovní skupiny IETF se může zapojit kdokoli a každý hlas má stejnou váhu. Ze stávající diskuze vyplývá, že návrh má více odpůrců než zastánců, a domnívám se tedy, že minimálně v této podobě schválen nebude.
Ondřej Surý
Kořenová zóna na serveru L-Root byla podepsána
Před časem jsem psal o plánu na podepsání kořenové zóny. První krok k podepsání kořenové zóny byl právě (asi před hodinou) učiněn a server L.Root-Server.Net začal jako první vracet podepsanou (ale nevalidovatelnou) kořenovou zónu. Takže velký potlesk pro kolegy pracující pro ICANN, a na výsledek jejich práce se můžete podívat sami:
; <<>> DiG 9.6.1-P2 <<>> +norecurse +multi IN DNSKEY . @l.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39000
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;. IN DNSKEY
;; ANSWER SECTION:
. 86400 IN DNSKEY 256 3 8 (
AwEAAa1Lh++++++++++++++++THIS/IS/AN/INVALID/
KEY/AND/SHOULD/NOT/BE/USED/CONTACT/ROOTSIGN/
AT/ICANN/DOT/ORG/FOR/MORE/INFORMATION+++++++
+++++++++++++++++++++++++++++++++++++++++++8
) ; key id = 23763
. 86400 IN DNSKEY 257 3 8 (
AwEAAawBe++++++++++++++++THIS/IS/AN/INVALID/
KEY/AND/SHOULD/NOT/BE/USED/CONTACT/ROOTSIGN/
AT/ICANN/DOT/ORG/FOR/MORE/INFORMATION+++++++
++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++8=
) ; key id = 19324;; Query time: 142 msec ;; SERVER: 2001:500:3::42#53(2001:500:3::42) ;; WHEN: Wed Jan 27 21:07:41 2010 ;; MSG SIZE rcvd: 439
Více informací o plánu nasazení na jednotlivé nameservery obsluhující kořenovou zónu najdete na speciálních stránkách Root DNSSEC.
A na závěr ještě jeden pěkný obrázek:
Ondřej Surý
S DNSSEC se ve světě roztrhl pytel
Není to tak dávno, co jsem zde psal o zavedení DNSSEC u domén Švýcarska a Lichtenštejnska. Skoro vzápětí ohlásil kanadský doménový registr CIRA na konferenci SecTor, že zahájil testovací provoz podepsané domény .ca.
Kompletní informace lze nalézt na stránkách registru CIRA, zde zmíním jen pár detailů. Testovací provoz probíhá na samostatných DNS serverech, tak aby nebyl narušen normální provoz. Pro podpis je použit algoritmus NSEC3 RSA-SHA1. Velikost zónového souboru vzrostla z 180MB na 670MB. Ještě doplním, i když určitě nechci naši roli přeceňovat ani nás nějak chválit, že s námi, s CZ.NIC správci kanadského národního registru některé důležité detaily konzultovali.
Pokud byste chtěli vyzkoušet, jak funguje DNSSEC v zemi javorového listu, máte dvě možnosti. První je použít rekurzivní DNS server unbound a nakonfigurovat v něm stub zónu takto:
stub zone:
name: “ca.”
stub-addr: 192.228.22.190
stub-addr: 192.228.22.189
stub-prime: “no”
Tento kousek konfigurace způsobí, že pro doménu .ca se budou používat jiné nameservery. Následně z výše zmíněné stránky musíte stáhnout soubor ca.conf a přidat jej do konfigurace:
server:
trusted-keys-file: "/etc/unbound/ca.conf"
Pro DNS server Bind 9 není možné nastavit konfiguraci tímto způsobem a proto byly připraveny forwardující DNS servery, které můžete použít takto:
zone “ca.” IN {
type forward;
forwarders { 66.241.135.248; 193.110.157.136; };
}
Tato část konfigurace způsobí, že se váš DNS server Bind bude pro dotazy směřující do domény .ca ptát speciálních rekurzivních DNS serverů.
Pro následné ověření, že jste konfiguraci provedli správně, můžete vyzkoušet kanadskou obdobu naší české domény http://www.rhybar.cz/ (tato stránka se při zapnuté DNSSEC validaci nezobrazí) na adrese http://broken.xelerance.ca/.
Ondřej Surý
DNSSEC v kořenové zóně
Když organizace ICANN přibližně v polovině tohoto roku ohlásila, že chce mít podepsanou kořenovou zónu do konce prosince 2009, zdálo se to být jako velmi ambiciózní plán. Po odhalení konkrétního plánu podepisování kořenové zóny na RIPE 59 v Lisabonu je nyní jasnější, jak k onomu letošnímu podepsání vlastně dojde, proč je letošní rok reálným termínem a proč se pro koncové uživatele ještě letos nic nezmění.
Na začátek příspěvku si nejprve řekneme, kdo všechno se okolo kořenové zóny motá:
- ICANN/IANA bude v rukou držet KSK klíče a bude přijímat změny v DS záznamech
- DoC NTIA je obdoba našeho ČTÚ a tato organizace bude schvalovat navrhované změny v DS záznamech a změny v klíčích kořenové zóny
- VeriSign bude spravovat ZSK klíče a podepisovat kořenovou zónu
Podle mne je důležité si říci, že se principiálně vlastně nic nezmění. ICANN/IANA doteď přijímal změny v nastavení jmenných serverů, dával tyto změny schvalovat DoC NTIA a Verisign změny implementoval do zóny. Schematicky to lze vyjádřit například takto:
S konkrétním časovým plánem nasazení vás ještě budu chvíli napínat a mezitím si pojďme říci, jaké budou technické parametry nasazení DNSSEC. KSK bude klíč o velikosti 2048 bitů. Použitý algoritmus bude RSA-SHA256, který byl ještě nedávno schválen jako internetový standard. Zajímavostí je, že do procesů okolo KSK bude zapojena i internetová komunita, jednak jako dohližitelé při aktivaci KSK jednak jako držitelé záložní kopie KSK klíče. KSK klíč se bude měnit jednou za 2 až 5 let pomocí mechanismu popsaného v RFC5011.
V případě ZSK je použit klíč se stejným algoritmem, jen bude o polovinu menší, tedy 1024 bitový RSA-SHA256 klíč, který se bude měnit každé tři měsíce.
Pevné body důvěry kořenové zóny (tedy KSK) budou publikovány na webových stránkách organizace ICANN jednak ve formě vhodné k automatizovanému zpracování a jednak v takové formě (PKCS#10), aby jej mohly podepsat externí certifikační autority.
Nyní se konečně dostáváme k již slibovanému plánu nasazení. Ač se na začátku zdálo, že plán podepsat doménu ještě letos se v žádném případě nemůže povést, tak ICANN představil velmi konzervativní a zodpovědnou strategii, jak začít podepisovat kořenovou zónu. Kořenová zóna se opravdu začne podepisovat 1. prosince 2009, nicméně se bude jednat pouze o interní procesy organizací ICANN a Verisign. Doména bude podepisována, bude probíhat rotace klíčů a všechny ostatní související procesy, ale samotná podepsaná zóna se nedostane ven.
Od ledna 2010 do začátku července bude probíhat postupné testování zátěže kořenových nameserverů. Pro tyto účely bude použit speciální klíč, který bude vypadat takto:
. 3600 IN DNSKEY 256 3 5 (
AwEAAa++++++++++++++++++++++++++++++
++THIS/KEY/AN/INVALID/KEY/AND/SHOULD
/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICA
NN/DOT/ORG/FOR/MORE/INFORMATION+++++
++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++/=
) ; Key ID = 6477
Anglický text uvnitř klíče říká, že tento klíč není validní, nemá se používat a pro více informací je možné kontaktovat organizaci ICANN. Aby se zajistilo, že tento klíč opravdu nebude nikdo používat, tak kromě toho, že v kořenové zóně bude publikován tento speciálně vytvořený klíč s varovným textem, budou také generovány nevalidní podpisy. Takto podepsaná zóna bude postupně nasazována na jednotlivé kořenové nameservery počínaje serverem L.root-servers.net, který je provozován právě ICANNem, a konče serverem A.root-servers.net, který je pravděpodobně z důvodů špatné implementace DNS protokolu u některých klientů nejpoužívanější.
Toto postupné nasazování je zapotřebí především pro klienty a DNS servery, kteří zaspali před rokem 1999, kdy bylo schváleno RFC2671. Tento standard umožňuje zvětšit velikost DNS zprávy nad původně povolených 512 byte. Celý DNS provoz bude pečlivě monitorován a pokud by se v průběhu testování vyskytly nějaké problémy, budou operativně řešeny. Proces nasazování bude zakončen v červenci příštího roku podepsáním kořenové zóny validními klíči, publikací těchto klíčů na stránkách organizace ICANN a zveřejněním validně podepsané kořenové zóny na kořenových nameserverech.
Ač k podepsání kořenové zóny DNSSECem letos z hlediska veřejnosti nedojde, nezbývá než ICANNu popřát hodně štěstí v implementaci jednoho z nejdůležitějšího milníku internetu od dob, kdy bylo zavedeno DNS. Důležité je řídit se především pravidlem číslo jedna v RFC1925 a žádné problémy by neměly nastat :).
Ondřej Surý
Conficker je stále s námi
Červ Conficker je stále na horních příčkách virových infekcí na celém světě. A autoři červa mají pod kontrolou pravděpodobně největší síť botů (napadených počítačů). Samotný červ v sobě neobsahuje žádný „škodlivý“ kód. Celý koncept je postaven spíše jako stroj na vydělávání peněz. Conficker v sobě obsahuje mechanismus, kterým může „aktualizovat“ lokální počítač libovolným dalším programem. Lidé stojící za touto masivní infekcí vydělávají na pronájmu strojového času napadených počítačů. Vím o případech, kdy si autoři jiného počítačového červa, který nepoužívá tolik agresivní taktiku šíření, pronajali botnet Confickeru pro šíření vlastního kódu na již napadené počítače. Také jsou známy případy, kdy byl tento botnet pronajat pro rozesílání nevyžádané pošty, či rhybaření.
Každopádně, proč tento zápisek píšu. Výzkumníci ze SIE (Security Information Exchange) poskytují platformu pro sběr a výměnu dat týkajících se červa Conficker. Pokud jste ISP, CERT, případně jste jinak angažováni do internetové bezpečnosti, můžete dostat přístup do databáze, která obsahuje data týkající se tohoto nebezpečného botnetu. Projekt naleznete na adrese ISC SIE Conficker.
Ale i pokud jste jen normální uživatel a chtěli byste vědět, zda-li váš počítač není červem Conficker napaden, můžete to zjistit na lokálním zrcadle stránky Conficker Eye Chart, které pro vás připravily Laboratoře CZ.NIC. Tato stránka obsahuje šest obrázků, z nichž některé jsou blokovány červem Conficker. Pokud se vám nezobrazí obrázky v horní řadě, ale obrázky v dolní řadě ano, tak jste pravděpodobně infikování některou z variant červa Conficker.
Ondřej Surý
Další ovečky do DNSSEC ohrádky
V úterý (21. září 2009) došlo k podpisu dalších dvou národních TLD. Organizace SWITCH, správce národních domény Švýcarska a Lichtenštejnska, oznámila podpis domén .ch a .li. Obě tyto národní domény jsou podepsány pomocí technologie DNSSEC. Neexistence domény je řešena pomocí standardu NSEC3, bez možnosti opt-out. Klíče obou domén můžete zjistit příkazem dig +multi IN DNSKEY CH. a dig +multi IN DNSKEY LI.. Ke zveřejnění klíčů a jejich vložení do registru ITAR by mělo dojít během několika málo dní.
Každý měsíc teď už přicházejí zprávy o zavedení DNSSEC v další a další doméně nejvyšší úrovně. Český registr již eviduje více než 1 000 domén, které DNSSEC chrání. Nedá mi tedy než se nezeptat: „A co vy? Už jste také podepsali?“
Ondřej Surý
A je to tady zase… aneb vzdálený DoS na Bind9
Včera (chtěl jsem napsat dneska, ale to už jsem o nějakých 40 minut nestihl), přibyla v systému na sledování chyb, který provozuje Debian, nová chybka. Bohužel se nakonec ukázalo, že to nebyla ani chybka, ani chyba, ale přímo velechyba (vzor ryba :)).
Tudíž pozor – ve všech verzích Bind9 je chyba, která umožní útočníkovi pomocí speciálně vytvořené DNS zprávy (a kód na vytvoření takové zprávy byl rovnou přiložen v hlášení chyby) shodit váš DNS server. Tedy za předpokladu, že takový DNS server obsahuje alespoň jednu autoritativní doménu, která je útočníkovi známa.
Aktualizace: DNS serveru musí pro konkrétní zónu být master. A mimochodem do toho spadají i rekurzivní servery, které se řídí RFC1912 sekcí 4.1, a obsluhují zóny localhost, 0.0.127.in-addr.arpa, 255.in-addr.arpa a 0.in-addr.arpa.
Obrany jsou dvě, z toho jedna preventivní. První obranou je použít aktualizovanou verzi Bind9 (9.4.3-P3, 9.5.1-P3 nebo 9.6.1-P1). Druhou obranou, která je i prevencí, je neprovozovat DNS monokulturu. DNS je vcelku odolný protokol a tak mu většinou stačí, když běží alespoň jeden DNS server. Proto je obranou provozovat serverů více a používat různý DNS software. Pro autoritativní server je to například NSD. Tím zvýšíte pravděpodobnost, že podobný útok nepostihne všechny (což jsou u normálních doménových jmen většinou dva) autoritativní DNS servery, ale pouze jeden.
Podobná nebo jiná chyba se stejným způsobem může objevit u NSD, Bind9 může být pro změnu v pořádku. Jen je důležité nemít zranitelné všechny (oba) servery stejnou bezpečnostní chybou.
Ondřej Surý
Anycast, kam se podiváš… aktualizace
V jednom z předchozím příspěvků jsem psal o rozšiřování politiky RIPE iniciované CZ.NICem na přidělování anycast bloků pro TLD operátory.
Dneska mi přišel e-mail, který ve stručnosti říká, že změna politiky byla schválena a bude implementována během jednoho měsíce:
PDP Number: 2008-05
Anycasting Assignments for TLDs and Tier 0/1 ENUMDear Colleagues
Consensus has been reached, and the proposal described in 2008-05 has
been accepted by the RIPE community.The related RIPE policy documents have now been updated, published and can be found at:
IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region:
http://www.ripe.net/ripe/docs/ripe-471.htmland
IPv6 Address Allocation and Assignment Policy:
http://www.ripe.net/ripe/docs/ripe-472.htmlThe proposal is now archived and can be found at:
http://www.ripe.net/ripe/policies/proposals/2008-05.html
The RIPE NCC will implement this new policy within one month.
Thank you for your input.
Regards
Ingrid Wijte
Policy Development Officer
RIPE NCC
Takže se můžete těšit na postupný přechod našich unicastových DNS serverů na anycastové, což bude znamenat zase o krok lepší dostupnost a odolnost proti výpadku.
Ondřej Surý