July 2011 - dns-wg - mailman.ripe.net

DOMAIN attributes review
by Denis Walker 19 Jul '11

19 Jul '11

[Apologies for duplicate emails.] Dear Colleagues, At the RIPE 62 Meeting we were asked to consider the attributes in DOMAIN objects. With the removal of any hierarchy in reverse delegations and the removal of forward domain data there is no longer any use case for the "mnt-lower:" attribute. Other attributes that are considered to be used only for forward domains are: - "refer:" - "sub-dom:" - "dom-net:" The statistics listed below show how many of the above attributes have been added to reverse delegations and ENUMs. The RIPE NCC would like to ask the community if anyone sees any justification for the use of these attributes in reverse delegations or ENUMs. If there is no justification, all four of these attributes can be removed from all DOMAIN objects when the last two TLD operators move their data out of the RIPE Database. This is anticipated to occur by the end of 2011. To keep any discussion focussed please send any comments or feedback to the DNS Working Group Mailing list. Regards Denis Walker Business Analyst RIPE NCC Database Group Statistics ---------- Number of each attribute used in reverse delegations or ENUMs and the number of unique maintainers who manage these objects. "refer:" = 6 unique maintainers = 1 "sub-dom:" = 271 unique maintainers = 23 "dom-net:" = 2219 unique maintainers = 140 "mnt-lower:" = 46485 unique maintainers = 4208

2 1

Increased Query Load on Root Name Servers
by Mirjam Kuehne 13 Jul '11

13 Jul '11

[apologies for duplicates] Dear colleagues, The RIPE NCC experienced an increased query load on K-root and other root name servers. Please find some analysis and graphs on RIPE Labs describing this increase. http://labs.ripe.net/Members/wnagele/increased-query-load-on-root-name-serv… Please note that we did not see any noticeable degradation of any Internet services caused by this. Kind Regards, Mirjam Kuehne RIPE NCC

3 6

Response size of JP's DNSKEY was changed
by Masato Minda 13 Jul '11

13 Jul '11

Folks In RIPE 62, I had a presentation about response size of DNS with DNSSEC. Somebody was interested about reply size of JP's DNSKEY. (slide 9) In this slide, the response size of JP's DNSKEY was 1203 octets. Last week(July 7), we have changed it. $ dig +dnssec jp dnskey | grep SIZE ;; MSG SIZE rcvd: 893 Here is the size of packet. ----------------------- KSK of DNSKEY 276 ZSK of DNSKEY 148 RRSIG by KSK 290 RRSIG by ZSK 162 ----------------------- ---------------------- DNS Header 12 Question section 8 JP:4 class:2 type:2 EDNS0 11 ---------------------- Before July 7, response of DNSKEY had 1 KSK, 3 ZSK, 1 RRSIG by KSK, and 1 RRSIG by ZSK. 12 + 8 + 11 + 276*1 + 148*3 + 290*1 + 162*1 = 1203 After July 7, response of DNSKEY has 1 KSK, 2 ZSK and 1 RRSIG by KSK. 12 + 8 + 11 + 276*1 + 148*2 + 290*1 + 162*0 = 893 It is current result. * KSK rollover In KSK rollover, we will use the double signature key rollover. 12 + 8 + 11 + 276*2 + 148*2 + 290*2 + 162*0 = 1459 Of course, IP and UDP header are needed in real packet, IPv4 IPv6 IP 20 40 UDP 8 8 -------------------- total 28 48 The size of packet in KSK rollover, IPv4 is 1487, IPv6 is 1507. 1507 is bigger than traditional MTU. :-( If the ZSK is only one when KSK rollover, its response size is 1311. 12 + 8 + 11 + 276*2 + 148*1 + 290*2 + 162*0 = 1311 In this condition, IPv4 is 1339, IPv6 is 1359. It's ok. :-) It is a bit trouble. But, we will do our best. Unfortunately it is impossible to less than 1280 in current condition. I think that ECC (Elliptic Curve Cryptography) can clear under 1280. Regards, -- minmin / Masato Minda <minmin(a)jprs.co.jp> Research and Development Dept. Japan Registry Services Co., Ltd. (JPRS)

2 1