Knot DNS 1.4 är släppt i tid. De har online-signering med DNSSEC. Väldigt simpel DNSSEC-hantering just nu.
Pågående arbete för 1.5 är något som de kallar för dynamiska moduler, som man kan hooka in på bra ställen, kan vara användbart. En massa annan refaktorering också. Release-kandidat snart. I version 1.6 kommer ännu mer DNSSEC-hantering.
Dynamiska moduler tillför dynamisk processning av frågor och anpassa svaren. De kan också generera svar i farten, efterfrågat av en stor operatör. Man kan t.ex. dynamiskt generera PTR-svar för reverse-frågor, både IPv4 och IPv6. Inte DNSSEC-signering av detta ännu, det kommer i version 1.6. Detta borde vara av stort intresse för operatörer som kör IPv6.
De har också radikalt minskat minnesutnyttjandet för många zoner från version 1.4 till version 1.5, och samtidigt ökat antalet frågor de kan hantera per sekund rejält. Nu kan de förmodligen inte optimera mer, det är så nära hårdvarans gränser man kan komma.
DNSSEC-koden i version 1.6 är separerad bättre i Knot DNS, så att det ska gå att återanvända den i annan programvara. De jobbar också på att byta up OpenSSL till GnuTLS. PKCS#11-stöder i GnuTLS är också bättre. De har också Key and Signing Policy inspirerat av OpenDNSSEC.
Shane Kerr ger sin personliga syn på BIND 10-projektet. BIND har funnits väldigt länge, och alltid varit öppen källkodd. Historien här börjar vid BIND 4, men förmodligen har det också funnits version 1, 2 och 3. Bind 8 ersatte BIND 4, och BIND 9 ersatte BIND 8.
I projektets start började man definiera projektet, och det var viktigt att det blev ett community-projekt. Så det sattes upp som ett open source-projekt, med wiki, öppna mötesanteckningar, öppet källkodsrepository osv.
Under första året gick allt bra, man hade en enkel auktoritativ server, all infrastrukturen och DNS-biblioteket, och målen uppnåddes under budget.
Sedan började problemen. En massa "technical debt" (teknisk skuld), dvs allt man borde ha gjort i början men sköt upp på framtiden. En del sponsorer hade problem med att första året vad under budget, och ville ha tillbaks pengarna. Andra ville inte alls ha tillbaka pengarna, och en del brydde sig inte alls.
Andra problemet var att antalet programmerare inte ökade snabbt nog, och antalet sponsorer ökade inte. En sponsor ville driftsätta programvaran i andra halvan av år två, och man beslöt att splitta upp teamet i två delar, en del som skrev en resolver, och en del som skrev på den auktoritativa servern. Dvs, man ändrade planerna en del.
År tre hade man en ännnu högre teknisk skuld. Den lilla enkla resolvern fungerade fortfarande inte riktigt. Man fick inget internt stöd inom ISC heller, och ISC började arbeta "mot" projektet. Den nya VD:n var mer entusiastisk över BIND 9. Och genom arbetet med BIND 10 hade annan DNS-programvara blivit mycket bättre, PowerDNS hade implementerat DNSSEC osv.
Sedan slutade Paul Vixie, och en av hans vänner blev VD. Han kickades av styrelsen, och de var utan VD i tre månader. Sedan anställdes en riktig skitstövel som VD, och det var svårt att bli av med honom. Kunderna började hata ISC osv, och till slut anställdes Jeff Osborn och situationen började bli bättre. Men medlemmar i teamet började under den här tiden säga upp sig. Och hälften av sponsorerna hade också till stor del börjat dra sig ur, och man bestämda sig för att lägga ner projektet.
Nu BIND 10-projektet släppt helt utan tygar, och ligger på GitHub, de har en webbsajt, och det är ett helt informellt arbete. De ska ha en BoF senare under RIPE-mötet för att möta upp intresserade i projektet.
Det var en dålig idé att underhålla två stora programversioner samtidigt (BIND 9 och BIND 10). Det slukar dubbelt så mycket resurser, och användarna är tveksamma om vilken version man ska använda. Det är bättre med inkrementella förbättringar.
BIND 10 hade fler än 10 sponsorer, och de hade en styrkommitté. Men det visade sig vara en dålig idé, de hade var för sig en helt egen agenda och kom aldrig med en gemensam åsikt.
Release early release often funkar bäst om man faktiskt har några användare. Och ät din egen hundmat, och se till att du verkligen gör det ordentligt. Man måste köra programvaran för att se om den funkar som man tänkt sig, även fast det innebär en liten risk. Vågar man inte själv är det svårt att övertyga andra att använda den.
Valet av Python var också tveksamt, Python befann sig i en extremt lång övergång mellan version 2 och version 3, och har inte prestanda för att vara en DNS-server. Dessutom hatar systemadministratörer att administrera större system med Python-kod, det krävs så mycket dependencies osv.
Jim Reid säger att det här påminner väldigt mycket om hur utvecklingen av BIND 9, och att ISC inte verkar ha ett institutionellt minne för att lära sig av tidigare projekt. Shane kommenterar att ingen som jobbade på BIND 10-projektet tidigare hade jobbat på ISC, så det fanns helt enkelt inget sådant minne i teamet.
I princip samma presentation som på DNS-OARC.
TLS DANE och SMTP medgör att det går att validera certifikaten genom DNS. SMTP-servern indikerar att den klarar TLS, och klienten kan besluta att uppgradera till TLS. Certifikatet som då kommer tillbaka kan klienten validera genom motsvarande SMTP-namn i DNS.
Man behöver en resolver som klarar DNSSEC, t.ex. BIND, Unbound eller Windows 2012. Postfix stödjer DANE-validering, och inom Exim-projektet pågår den utvecklingen nu.
I måndags slog en större tysk e-postleverantör på validering av DANE för SMTP.
Kommentar från Olaf Kolkman: det här är ett väldigt viktigt steg för att säkra upp internet, i synnerhet av ljuset av "pervasive monitoring" (Snowden-avslöjandena).
Om man ser att det saknas stöd i någon programvara som har nytta av detta, kontakta utvecklarna. Eller ta dig lite tid och utveckla själv. Det är inte så svårt.
Tomek har tidigare skrivit Dibbler, en DHCPv6-server.
Öppen källkod, men med slutet repository, och semislutet bugghanteringssystem, "manageed open source". Första versionen släpptes 1997.
Varför en ny DHCP-implementation? Den gamla koden är 18 år gammal, och nätverk och hårdvara har förändrats, och användarfallen har förändrats.
Nackdelar med ISC DHCP är att koden är väldigt komplex och svår att utvidga. Dokumentationen är inte tillräckligt, och prestandan är inte heller tillräcklig. När man förändrar konfigurationen måste man starta om servern, inte särskilt praktiskt.
ISC har utvecklat BIND 10 sedan 2009, och de började med en ny DHCP-impelenmtation i mitten av 2011. Sedan slutade ISC med utvecklingen i april 2014.
Översikt av Kea: DHCPv4-server, DHCPv6, DNS-uppdateringar och perfdhcp för att mäta prestanda. All huvudsaklig kod finns i libdhcp++.
Den nya koden kan göra allt som man kan förvänta sig av en DHCP-server, adressutdelning och expirering, alla standardoptions, och en del annat inkl vendor-options (inklusive DOCSIS3.0). De hanterar prefix-delegering i DHCPv6, och dynamiska DNS-uppdateringar.
Man kan byta backend i Kea, just nu stöd för MySQL, PostgreSQL, Memfile och det finns möjlighet att lägga till sin egen lagring.
Det finns ett Hooks-API. För varje steg i processningen kan man registrera en funktion som tar del av informationen och tillåter att man inför anpassad funktionalitet.
Kea 0.8 släppt i april 2014, och 0.9 kommer sommaren 2014 där man tar bort BIND 10-ramverket. 0.9 kommer också tillåta omladdning av konfiguration online. Fullt stöd i Linux, och till 0.9 ska det också fungera på FreeBSD.
1.0 beräknas släppas Q2 2015, och 2.0 också under 2015, 3.0 under 2016. 2.0 kommer att stöda failover för HA, statistik och så vidae. Under 2017 räknar man med att ISC DHCP kommer vara EOL.
De söker sponsorer.
Vad är ONIE (Open Network Install Environment)? http://onie.github.io/onie/ - liknande som att installera ett OS på en server, installeras på en switch.
Många hårdvaruleverantörer tillåter att man köper switchar utan OS installerat, Dell, Broadcom osv.
Hjälp från UTSA OCP Lab, som kommer att hjälpa till med testplaner, utarbeta hårdvarucertifiering, och förbättra kvaliteten på projektet.
Stödjer många CPU-arkitekturer, PowerPC, x86 (inkl vm:ar), planerat stöd för ARM och MIPS.
I framtiden kommer man att lätt kunna välja vilket OS man vill köra på sin switch.
Rummet är för litet, de har ett overflow-rum med projektor.
K-Root: business as usual med 17 noder. Vissa kommande arkitekturförändringar, mindre "DNS-in-a-box"-servrar, med mer modesta krav för en host. Fem globala noder kommer att underhållas. Gradvis migrering över till den nya modellen, och högre diversitet med BIND, Knot och NSD.
De kör också autkoritativ DNS för andra zoner. Som primär bl.a. ripe.net, e164.arpa och de top-level reverse-zoner för IP-adressutrymmet from RIPE hanterar. En hel del andra zoner som sekundär, in-addr.arpa och ip6.arpa, 77 ccTLD:er, samt forward- och reverse-zoner för andra RIR:ar, och en del annat.
Två aktiva sajter, Amsterdam och London. En tredje sajt är redo, och de håller på att arrangera transit-trafiken. Stockholm-sajten kommer att vara backup och sekundär distributions-sajt, och den kommer att vara igång i slutet av maj.
Sekundärtjänsten för ccTLD är stabil, men saknar avtal och SLA:er.
Fram till nu har RIPE NCC endast kört BIND - men miljön är mogen, och använder inte mycket minne, osv. Men nedsidan är att klustret är sårbart, och alla argument med en ökad diversitet framförs.
De har en del krav för valet av ny NS-programvara, och de har tittat på Knot, NSD 4, Nominum ANS, BIND 10 och YADIFA.
- NSD 4 uppfyller kraven, och det finns aktiva utvecklare som svarar snabbt på frågor.
- Knot DNS är också stabil och uppfyller kraven, och även deras utvecklare är snabba och tillmötesgående.
- Nominum ANS kommer att eventuellt att köras på Stockholm-sajten.
- BIND 10 är nedlagt, inte tittat mer på den.
- YADIFA behöver mer arbete, inte aktuell just nu.
De har även testat minnesnyttjandet och startup-tider på de olika programvarorna. De har också hittat en del buggar i NSD 4 och Knot-DNS, men som rättats fort.
För att hantera diversiteten använder de Ansible för automatisk konfiguration - inventory berättar för servern vad den har för roll, och rollerna är "mutually exclusive", och det är lätt att byta ut programvaran för en server. Det är bara att byta roll för servern, och det tar ett par minuter att helt byta ut programvaran.
Diversitet i hårdvara och operativsystem är lite mer komplext, och de kommer inte att göra det just nu. De kör CentOS-linux nu. Men de är öppna för mer diversitet, men svårast blir hårdvaran.
Universitetet har attackerats, och blackholade en IP-adress. Den som utförde attacken bytte, och den nya adressen blackholades, och processen upprepades ett antal gånger.
Universitetet har 5 sajter med ca 10000 studenter och 850 anställda. 1Gbps på HQ, och 1Gbit mellan sajterna.
Attacker som har en enda avsändaradress är lätta att spåra. LOIC hanterar bara IPv4 idag.
Universitetet kör PowerDNS, och en proprietär brandvägg. De bytte dock till pfsense efter en vecka in i attackerna.
Loggarna i pfsense innehöll TTL för DNS-svaren. Det visade sig att attack-frågorna innehöll tre olika TTL:er, och de flesta poster var för A-frågor. De flesta paketen kom från Tyskland, och mycket från USA.
De slog på EDNS0 subnet-optionen, och såg en del informationen den vägen också.
Den högsta trafiklasten de såg genom pfsense-brandväggen var 36Mbit/s.
DNS är osäkert, och DNSSEC är lösningen. Nicholas har använt RIPE NCCs Atlas-plattform för att utföra mätningar av DNSSEC-deploymnet, och idag består Atlas-nätet av ca 5000 aktiva prober över hela världen, men mest koncentration runt Europa.
Atlas-proberna kan prata med en lokal resolver som kan ställa frågor till en namnservrar. Namnservern är under Nicolas kontroll, och spelar in alla paket. En del utmaningar är att IP-adressen som ses av proben är 8.8.8.8, och adressen som ses av namnservern är en helt annan. Lösningen på detta är att försända en fråga med ett ID, och använda wildcards. Probe 1234 frågar efter 1234.example.com.
En begränsning är att Atlas inte är internet.
Processen:
- Lista alla aktiva prober.
- Starta paketinspelningen på namnserver.
- Starta mätningen på Atlas-proberna.
- Vänta på mätresultat.
- Stoppa paketinspelningen.
- Repetera steg 2-5 tills alla prober har använts.
De har testat mot olika zoner, secure, insecure, badlabel, badrrsigs och norrsigs.
Resultaten visar att mot fungerande DNSSEC sätter 88,23% av resolvrarna DO-biten och 92,73% frågar efter DS-post. Autentiserade frågor är 30,41%. De 40 vanligaste resolvrarna var Google (38) och OVH (2).
Cirka 29% av uppslag för de trasiga domänerna gav SERVFAIL. Lite skillnad mellan varianterna av fel.
Slutsatsen är att vi har en väldigt hög nivå av namnservrar som kan hantera DNSSEC, DO indikerar 87% och DS indikerar 93%. AD-bit indikerar ca 30% validering, och de trasiga zonerna indikerar på 27-29% validering. Största problemet är att validering av wildcars inte fungerar så bra.
Den verkliga frågan när vi mäter DNSSEC-deployment är egentligen "Hur många användare kan göra <x> med DNS?".
- Hur många användare kan hämta URL med IPv6?
- Hur många användare genomför DNSSEC-validering när de resolvar ett namn?
- Hur många användare är kapabla till att resolva namn med DNS över TCP?
- Hur många användare kan följa DNAME-kedjor i DNS?
- osv.
Det viktiga är att veta hur många användare som berörs. Användare vs infrastruktur. När man tittar i kärnan av nätet är du väldigt långt från användaren. Till exempel DNSSEC, vi kan titta i en zonfil och räkna antalet signerade zoner. Men det säger inget om antalet användare.
Om man har tillräckligt populära tjänster som t.ex. Google har är det lättare att mäta användning. Annonser finns överallt. Och alla använder Youtube. Geoff pratar som vanligt om att använda Flash-annonser för mätning av olika saker. Flash kan hämta ytterligare resurser på nätet, och det kan man använda till olika typer av mätningar. Begränsningen är dock till port 80.
Med den här typen av mätningar ser man både klientens IP-adress och resolverns IP-adress. En annan fördel med annonser är att annonsnätverken inte vill visa samma annons för samma användare flera gånger. Man kan också begränsa annonseringen till vissa länder eller till och med regioner. Man har inte lika mycket flexibilitet som med Atlas, men man har en mycket bredare användarbas.
Googles annonsnätverk lär sig också med automatik att få en jämn utspridning över dygnets timmar, men det tar några dygn. Men varje gång man vill utföra ett nytt experiment måste man vänta på att annonsen godkänns av Google. För att undvika detta kan man anpassa annonsen till att hämta resurser dynamiskt genom att hämta en lista med tester på nätet.
Testmiljön har nu tre mätservrar, identiska maskiner placerade i USA, Europa och Australien. Servern kör BIND, Apache och tcpdump. Experimentet dirigerar användaren till den "närmaste" servern baserad på en /8-karta över klientadresser. Det som spelas in är HTTP-loggen, dns-frågeloggen från BIND och paketdumparna.
Att mäta IPv6 per annons:
Klienten ges 5 URL:ar att ladda:
- Dual Stack object
- Endast v4-objekt (DNS-namn)
- Endast v6-objekt (DNS-namn)
- v6-adress
- Rapporterings-URL
All DNS är dual stack.
Att hitta Routing-filter per annons:
Klienten ges 3 URL:ar att ladda:
- DNS-namn som resolvar till ett test-prefix
- DNS-namn som resolvar till ett kontroll-prefix
- Rapporterings-URL
Att mäta DNSSEC per annona:
Klienten ges 4 URL:ar att ladda:
- DNSSEC-fungerande signerad URL
- DNSSEC-trasig signerad URL
- Osignerad URL (för kontroll)
- Rapporterings-URL
Resultat från december 2013, fungerande DNSSEC-validering på 6,8%. DNSSEC-validering men med hämtning också över trasig DNSSEC 4,7% - och ingen DNSSEC alls, 88,5%.
70% av användarna i Yemen validerar, och Sverige 67%, tredjeplatsen innehas av Slovenien med 51%. Sist på hela listan av länder är Sydkorea med 0,3% validering - märkligt för ett land med så utbyggt bredband.
Nu har de även gjort en interaktiv karta.
Men varför är det så att de 7% DNSSEC-validerande användare är tre gånger fler än användare som använder sig av IPv6?
Hur har DNSSEC-deployment lyckats så mycket bättre än IPv6?
Är Google Public DNS en faktor? Av de som validerade DNSSEC, hur många använder Google? I Yemen eller Sverige använder man inte Google.
I Polen (där mötet är) slog någon på DNSSEC-validering i februari. På den interaktiva kartan kan man se dessa saker mer i detalj. Klicka gärna på Sverige.
Vid SERVFAIL med trasig DNSSEC ser man att antalet frågor ökar rejält. Vissa resolvrar försöker panikartat få igenom en lyckad validering. Det beror mest på att DNSSEC-signaleringen för felaktigheter är bedrövlig, och består enbart av SERVFAIL. En bättre signalering behövs.
Från tidigare presentationer på samma tema har Geoff sagt att 10% av användarna använder Google Public DNS. Detta har nu ökat till 16%. Och vi oroar oss över statlig övervakning... Det är en av sex användare där Google ser alla DNS-frågor.
En fortsättning på en diskussion som var på Aten-mötet, om hur RIPE NCC ska hantera DNS-hostning av ccTLD:er. Anledning till diskussionen är att RIPE NCC inte borde konkurrera med de komersiella aktörerna.
RIPE NCC har publicerat en budget och aktivitetsplan för 2014, och den innehåller ett stycke om att RIPE NCC inte ska tillhandahålla DNS-tjänsten för väletablerade TLD:er.
The RIPE NCC offers a secondary name service to the other RIRs, along with some country code Top-Level Domain (ccTLD) operators, who are in the start-up phase of their operations . The RIPE NCC no longer provides this service to well-established ccTLDs. In 2014, the RIPE NCC will work on clarifying its policy for hosting secondary ccTLD name servers, as well as developing documentation on the procedures and requirements for receiving the service. Benefits for RIPE NCC members / RIPE community: Supports the stability of the global DNS by offering a professional service to the other RIRs and developing ccTLD operators that require it.
- RIPE NCC borde alltså bara förse ccTLD:er (enligt ISO-3166) och IDN ccTLD:er med tjänsten.
- RIPE NCC ska utbyta brev med ccTLD-operatörerna.
- Överenskommelsen om att erbjuda en sekundär DNS-tjänst ska ha en begränsad livslängd, som ses över med nya utbytta brev.
Sedan finns det ett antal kriterier för att köra tjänsten:
- Storleken på zonfilen
- Antal och diversitet på namnservrar
- användandet av andra komersiella DNS-tjänster.
För de ccTLD:er som redan använder RIPE NCCs DNS-tjänst kommer dessa villkor inte att gälla förrän om minst två år.
Vad innehållet i breven som ska utbytas exakt ska innehålla är arbete som ska göras, men en av anledningarna till att utbyta dessa brev är att "pinga" ccTLD:n för att se att det faktiskt finns någon ansvarig. Någonting som beskriver ansvarsförhållandena mellan båda parter måste finnas med i brevet, enligt de församlade deltagarna.
Nominet har insett att de suttit på en föråldrad infrastruktur, och använt ett föråldrat sätt att hantera den.
De vill snabbare kunna lansera nya tjänster, och använda all utrustning de har tillgänglig. De vill också ha automatisk provisionering och monitorering.
De använder sig av två moderna datahaller, med de skydd som finns tillgängliga för den här typen av drift. De har också en tredje datahall nu, på en neutral plats i bergen, där de pratar franska och tyska.
För lagring använder de 3PAR från HP, och CPU från HP. VMWare för virtualisering, brandväggar från Juniper i en hall, och från Cisco i en annan för diversitet.
Mellan hallarna DC1 och DC2 så har de 10gb kapacitet, för replikering av lagring och databaser. De kan med dätta sätta upp nya tjänster med automatik på båda sajterna.
För de kritiska tjänsterna som EPP och Whois kör de lastbalansering mellan sajterna. Om en sajt går ner flyttar ena halvan över till den andra automatiskt.
De monitorerar sina center med VCOPS (VMware vCenter Operations Management Suite). Fina dashboards som berättar det mesta om hälsan hos de virtuella tjänsterna. Eventuella larm går till deras "Service Now", direkt in i incidenthanteringen för jouren.
Kalaset kostade £4M, och projektet blev färdigt i tid och enligt budget.
Jag har tidigare bloggat om händelserna i Turkiet här.
De flesta regeringar gillar inte att bli kritiserade. Genom domstolsbeslut beslöt man att censurera bort Twitter och Youtube från Turkiet, och operatörerna gjorde detta genom att filtrera ut frågör rörande dessa tjänster. Redan tidigare har de använt samma metoder för att censurera spelsajter och liknande.
På Istanbuls gator klottrades information om hur man kunde komma runt dessa spärrar genom att exempelvis använda Google Public DNS (8.8.8.8), så att de ändå kunde komma åt tjänsterna.
Sedan började operatörerna filtrera ut dessa alternativa DNS-tjänster, men den 29:e mars började operatörerna injicera 8.8.8.8/32 för att dirigera om trafiken till falska namnservrar. Detta är inte längre "enkel censur", utan ett sätt att lura användarnas datorer att använda falska servrar för att förse dem med falsk information.
De falska resolvrarna slutade ljuga 4:e april, och BGP-kidnappningen upphörde 7:e april.
Vilka bevis finns det för detta då? Google Public DNS använder inte NSID, och det går att förfalska ändå. I övrigt finns Turk Telecoms Looking Glass-tjänst för att se BGP-routen. Vi har 10 Atlas-prober som också kan göra mätningar. Det finns också många turkar som kan felsöka manuellt, som har rapporterat hur det ser ut. Traceroutar är inte så trovärdiga, men att mäta latensen till 8.8.8.8 visar ett mer riktigt avstånd till resolvern - plötsligt minskade latensen till 10ms till 8.8.8.8, och det hade bara varit möjligt om Google faktiskt hade maskiner i Turkiet. Det har de inte. Ingen i Turkiet har erkänt BGP-hijacking, utan detta har skett helt i smyg.
DNSSEC hade hjälpt mot BGP-hijacking om användaren validerat DNSSEC, och twitter.com varit signerad. Med signerad twitter.com hade man ändå kunnat bevisa att resolvern förfalskat svar.
Det går idag inte att autentisera resolvern, men man hade kunnat använda exempelvis TSIG, SIG(0) eller DNScrypt. Det finns dock inga utbredda metoder för att göra detta idag, och detta borde DNS-gemenskapen arbeta vidare med.
RPKI hade inte hjälpt då kidnappningen av prefixed skedde internt i Turkiet (eller dess operatörer), inuti IGP. Ingen routing-säkerhetsmodell hade fungerat här.
Och att upptäcka lögnen är en sak, en annan att försöka gå runt den. Här hjälper ju egentligen inte autentiseringen.
Alternativa lösningar till detta var att:
- Använda en mindre känd öppen resolver
- Att köra en lokal DNS-resolver (port 53 blockades inte)
- Tunnlar, t.ex. Tor
Kommentar: Om man måste göra filtrering, var är bästa platsen att göra det på? Ska diskuteras i Collaboration-arbetsgruppen. Där ska även en anticensurteknik presenteras.
RIPE NCCs DNSMON-tjänst har funnits sedan 2003, och övervakar "viktiga" DNS-tjänster, t.ex. root och de "klassiska" gTLD:erna, och infrastrukturzonerna.
Det är hög tid att förnya DNSMON-plattformen. Datainsamlingsinfrastrukturen (TTM) är beslutad att läggas ner, backen är föråldrad och svår att hantera. Det nya blir byggt på Atlas-plattformen.
Ny URL: atlas.ripe.net/dnsmon
Rå-formatet blir RIPE Atlas JSON, och det är tillgängligt över API:er. Inbyggt stöd för TCP-frågor och traceroutes. Visualiseringen är interaktiv, och görs på klient-sidan (webbgränssnittet).
De nya mätningarna sker mot hostname.bind, och SOA över både UDP och TCP, samt traceroute och version.bind.
Utvecklingen av det nya systemet skedde primärt det senaste halvåret, med interna tester genomförda i januari. Den publika betan pågår april-maj (på URL:en ovan), och går i full produktion i juni. De båda systemen körs parallellt fram till sista juni, och datainsamlingen i gamla DNSMON pågår fram till slutet av juli. Data från båda systemen ska dock sparas "för evigt".
Användaren bestämmer själv tröskelvärden i användargränssnittet.
Gränssnittet demonstreras ordentligt. Och för att få publiken att prova gränssnittet utlyses en tävling för att få folk att testa och lära sig. Man ska hitta en vy som ser ut som en flagga, och den URL:en ska skickas in, och vinnaren annonseras på fredag.
Kommentar från Peter Koch: det är lite sorgligt att de gamla visualiseringarna försvinner, de länkas förmodligen till en hel del, inte minst från RIPE NCCs egna artiklar.
I panelen: Lars-Johan Liman, Netnod, Michael Daly, Nominet, Ondřej Surý, CZ.NIC, Robert Kisteleki, RIPE NCC.
Netnod har krav från kunder på vad de behöver för statistik, och de har intern statistik, och det finns olika möjligheter för olika programvaror i vad de kan ge för statistik. DNS-OARC har satt upp en mailinglista (dns-stats@dns-oarc.net) och en wiki för att diskutera gemensamma saker att enas kring.
RIPE NCC har också en massa mätsystem, och erbjuder gärna data till den som behöver det.