DNSSEC at the root zone – Joe Abley
- ICANN – Manges the Ket-signing-key (KSK) – accepts DS records from zone operators – sends update to DoCfor auth and to veriSign for implimentation
- DoC auth changes and Verisign impliments the change
- New process has Verisign signs the keys. V gets a few weeks of of KSKs that Doc signs in batches beforehand
- DNSSEC Practice Statement – describes procedures, currently drafts
- Around 20 Community Trusted Representative ( TCR ) have an active roll in the mangement of the KSK
- 2 copies of the Keys, west coats and east coast. Plus distributed backup
- “ceromony” for each step in procedure, required what you do and how many people and which people are present.
- Similar to what x.509 CAs do
- KSK is 2048 RSA key rolled every 2-5 years ( RFC 5011 but not all have that support) – Signature using SHA-256
- ZSK is 1024 RSA key – signed with NSEC – rolled 4 times year – Signature is SHA-256
- Time cycle every 90 days – ZSK overlap of a couple of weeks
- Root trust Anchor – published in XML document with constant URL – plain DNS record – PKCS#10 cert CSR , as self signed pub key, signable by others if they want
- DO=1 part of EDNS0 – says client wants DNSSEC – many clients set bit even though most won’t really want them right now – will cause all queries to jump in size
- Hard to sign root and then rollback
- Staged deployment – Start servering DNSSEC for 1 root server at a time – L-Root first, then A, then the others with J last
- DURZ – Unverifiable key published as placeholder
- Measurement – Packet captures , diologue with operators – wide range of pre-testing with various software – test with clients that drop large packets
- DS change requests – TLD procedure to be decided – DS requests 1-2 months before zone published
- http://www.root-dnssec.org
- Timeline – Test key signing Dec 2009 – Jan 2010 . Jan – July 2010 roll out signed roots . July 2010 Full Production
- Lots of documentation on website
- Indication of big jump in tcp queries presumably because udpreplies are too big
ENUM – Jay Daley
- Why Doesn’t telephony work like email?
- Email you choose how to published your email record, where to host, what emails to accept, can outsource, totally in control
- So IP telephony should be easy too?
- Unfortunately not
- Non site-local numbers MUST go to telcoto get delivered
- Missing – single , global directory linking telephone nmbers to voip numbers
- This is ENUM . Telephone Number -> Domain Name – Simple Algorithm – e164.arpa – 04 931 6970 -> 0.7.9.6.1.3.9.4.4.6.e164.arpa
- Won’t be typed, Translation done by a device – people still type out over fashon numbers
- Register your number, create zone. Add NAPTOR records to DNS zone. Special records to specifiy endpoints (usually sip records), receive calls
- NAPTO records do interesting stuff . eg “dig +short nsrs.tel naptr”
- how? Option 1- enable on your VOIP PBX that is internet connected
- Option 2 – on session border controller – “enterprise”
- Option 3 – ENUM proxy ( if existing SBC doesn’t handle enum)
- Registration process – not same as for domains since numbers already registered – needs authentication
- Various methods of authentication in different places
- No ENUM in NZ . Available in UK, Holland, Ireland, Germany, Austria but not significant takeup
- Reasons for lack of takeup in those countries – lack of mindshare – hostility from telcos
- Why not in NZ – TCF 2006 report – Privacy issues (but only publish what you like) – Emergancy services access (no idea where callers are) (but all VOIP has problem ) – Polcy/Goverance – “Carrier Issues”
- ENUM isabout control – movingit from carrier to you
- Key users – Call centres , ENUM instead of 0800 – Large supply chains (mandate VOIP ) – Multiple sites , simplyfy provisioning
- Won’t happen without demand
- “On the Internet voice is just another application”
- Significant political and commercial resistence from Telcos
Day in the Life of the Internet – Sabastian Castro
- 4 years of DNS data
- DITL motivation – network measurement – collection of data from DNS root servers – yearly since 2006
- More and more root servers, Alt root servers, gTLDs etc passive traces, 48-72 hours
- concentrate on root server data
- Pick best 24 hours out of total window
- 4-8 billion queries, 3-6 million unique clients – sm5-12% recursive queries
- Mostly A queries, AAAA increasing due to gluerecords being added (why are IPv4 clients sending AAAA queries when they probably won’t/can’t use)
- 70% of clients are EDNS are capable ( 90% of these are D0 enabled )
- However clients sending lots of of queries (probably broken) have good support – But clients that query less have lover level of support
- 10 invalid TLDs represent 10% of queries ( .local , .localdomain , wpad , invalid , home , belkin , corp , lan )
- Impossible to track down
- Most queries from NZgoing to Auckland root and Brisbane root but some going to overseas servers (those might be use simple round-robin picking)
- Lessons – Data collection is hard – clock skew , dat loss , wrong command line options , bad network taps
- Data management – moredat , more participants – more formats – big effortto normalize data , fill gaps , fix clock skew .
