RIPE 61

Minutes from RIPE 61
DNS Working Group
Tuesday, 15 November and Thursday 17 November 2010
Rome, Italy

[Session 1] [Session 2]

Session 1- Tuesday, 15 November 2010

A. Administrative Matters

Jaap welcomed attendees and started by dealing with administrative matters.

B. Minutes of Last Meeting & Matters Arising

There were no comments on the RIPE 60 Minutes, so these were declared final - the webpage will be updated.

C. Review of Action Items

Action Items were reviewed. Currently, there remain no open issues.

(The action point page on the website needs to be updated)

D. RIPE NCC Report - Anand Buddhdev, RIPE NCC

http://ripe61.ripe.net/presentations/310-RIPE61_AnandBuddhdev_DNS_update.pdf

Jim Reid asked Anand to clarify plans for signing of the ERX space given a new provisioning system will be soon installed. Jim asked if holders of ERX space would be able to get their space integrated into a signed version of .arpa.

Anand replied that like some other RIRs, the RIPE NCC has signed its zones and is preparing its provisioning systems to handle DNSSEC material. Soon the RIPE NCC plans to accept DS records from other RIRs. He could not give an exact date, but felt it very likely to be possible sometime in the middle of 2011. George Michaelson of APNIC acknowledged the community need and confirmed all five RIRs are working to realise this within the next year.

Kostas Zorbadelos asked if Anand could explain more about how DS records for ipv6.arpa are currently accepted. Anand said LIRs should add a DS-R-ARPA to any objects submitted to the database where the DS needs to appear in the parent zone. The RIPE NCC provisioning system already allows for this.

E. IETF WG Reports - Johan Ihren, Netnod

http://ripe61.ripe.net/presentations/168-ripe61-ietf-update.slides.pdf

Joao Damas felt that Johan's presentation was somewhat skewed and offered personal opinion. He particularly disliked Johan's preferences for resolving issues around DNS server configuration and objected to the criticism of inline configuration over DNS. He felt that the solution backed by Johan is too complex and would lead to more problems. He suggested if the existing two solutions were unworkable, then a third solution should be investigated. Jaap asked that the discussion be taken offline due to time constraints.

Suzanne Woolf of ISC wished to clarify that the identical resolution draft on DNSEXT is not yet ready for last call. There will be a draft, but it currently needs more work to refine and clarify issues before a definitive problem statement can be made. She asked anyone interested to review the draft and contribute.

There was commitment also to send the KIDNS charter to the appropriate mailing list for comment in the near future. This process will be made easier to incorporate feedback.

Peter Koch commenting on what is perceived as a more personal style of report, asked that feedback on this style of reporting be given to the chairs either during the week or by email to dns-wg-chairs@localhost.

F. DNSSEC in the Root Zone. Signed TLDs -The ARPA Zones - Dave Knight, ICAN

http://ripe61.ripe.net/presentations/171-signing-the-root-ripe61.pdf

Dave gave a brief retrospective on the project to deploy DNSSEC in the root zone of the DNS, with an update on secured TLDs and work on the signing of .arpa and its children.

There were no questions.

G. Key Rollover in .cz - Jaromir Talir, CZnic

http://ripe61.ripe.net/presentations/126-NSEC3-20101116-JT-RIPE61.pdf

Jaromir's presentation described individual steps and experiences learned from the rollover from an RSASHA1 to RSASHA512 KSK.

Sam Weiler asked about the assessment of which resolver got things wrong. Given that BIND is RFC compliant, he is of the opinion that unbound is overly pedantic. While unbound uncovered a bug that BIND didn't find, it didn't need to do so.

Kim Min Kaplan asked how 10 iterations were decided for the NSEC3PARAM record. In APNIC the aim has always been to achieve lower numbers. Jaromir clarified that they took into account the current number of TLDs with NSEC3.

A discussion ensued about why Jaromir's team chose to move directly to RSASHA512 keys given that the guidelines for the size of hash functions might suggest this to be overkill that could leave to unworkable key lengths.

For example, with 2048 bit RSA keys, 256-bit hashes are seen as appropriate. The suggestion was to change the algorithm itself rather than simply increase key size.

Ondrej Sury clarified that the larger key was chosen to give room for growth, as the administrative overheads of the rollover were huge. It isn't something anyone wants to repeat soon.

Peter Koch added that the maximum length of RSA keys remains 4096 bits.

Jaap asked that the experiences be documented in relevant drafts.

H. GOST Cryptoalgorithms in DNSSEC Seamless Integration - Vasily Dolmatov, Garant Park Telekom

http://ripe61.ripe.net/presentations/81-RIPE61_DNSSEC.pdf

Vasily spoke about the real-life scheme based on current software implementations, which use GOST cryptography in DNSSEC. The arbitrary mix of cryptographic algorithms in DNSSEC trust chain is possible and the operation is smooth and seamless. The DNSSEC implementation based on certified GOST cryptographic software is available.

There were no questions.

I. DNSDB: What's up with the DNS? - Joao Damas, ISC

http://ripe61.ripe.net/presentations/172-DNSDB.pdf

Joao described DNSDB, a database that stores and indexes both the passive DNS data available via ISC's Security Information Exchange as well as the authoritative DNS data that various zone operators make available. DNSDB makes it easy to search for individual DNS RRsets and provides additional metadata for search results such as first seen and last seen timestamps as well as the DNS bailiwick associated with an RRset. DNSDB also has the ability to perform inverse or rdata searches.

At the end of the talk, Joao demonstrated the ISC DNSDB system.

A few questions followed, with Klaus Darilion asking about the sources of data. Joao replied that ISC has a mixture of probes given to customers. Many are in the US, but there are plans to extend this to Amsterdam next year. Klaus also asked what would happen with the service when the beta period ends. Joao commented that nothing was  decided on whether the service will remain open to all or become more commercial.

Kim Min Kaplan asked if there was a way to know from which RRSET data is recorded. Joao said this was not exposed through the web interface. On the subject of overhead, he noted it was very lightweight.

A comment was made that the University of Vienna has developed something similar and Joao was asked about how long data is retained. He said that for now, there are no plans to dispose of any data since the costs of keeping it are low. On the subject of investigating different usage patterns in varied communities, everyone agreed it would make for interesting research. Currently, ISC does not produce or collaborate with any third parties to produce visualisations based on the data. Joao was aware of the data being used by anti-virus companies to mine for evidence to control and isolate botnets.

In closing, Joao emphasised that the ISC offering does not initiate any queries itself; it more-or-less passively stores data and makes it available to outsiders who can investigate ways of using it.

Session 2 - Thursday, 18 November 2010

Peter Koch welcomed people to the second session (in Italian!) and recapped the agenda.

J. Status Report on IANA ITAR - Elise Gerich, IANA

http://ripe61.ripe.net/presentations/342-itar-20101118.pdf

Lars Liman expressed thanks for the retirement of the ITAR, acknowledging it was an intermittent link. Suzanne Woolf of ISC congratulated Elise on declaring victory and having ICANN in a position to move on. Elise acknowledged the support of those at ICANN who have been invested in the project.

K. BIND 10 Update - Jelte Jansen, ISC

http://ripe61.ripe.net/presentations/341-20101116ripe61.pdf

Jelte gave short overview of the status of the BIND 10 project. Topics included the general framework, and some details about the (python) DNS conversion library.

George Michaelson of APNIC commented that his investigations into BIND had confirmed issues with relative speeds were common. Misformed DNS queries make it necessary to test against packet decommission into DNS. George congratulated Jelte on a clean and welcome release.

L. IDN Reployment for .ru - Sergey Gorbunov, RU-CENTER

http://ripe61.ripe.net/presentations/258-18_Nov_Presentation_Gorbunov_RF.pdf

Sergey spoke about the organisational, legal and technical issues around the implementation of the first Cyrillic TLD.

There was a question about rumours that a blacklist of words that could not be used in domains based on offensive language included legitimate words. Sergey acknowledged this and hoped the registry would revisit the list.

Jim Reid asked if holders of existing .ru (Latin) domains were given automatic Cyrillic versions. Sergey said this was not the case. In response to another question, he also clarified that the domains did not permit a mix of Latin and Cyrillic characters.

Jaap Akkerhuis asked about what registration data was retained and published for the delegations. Sergey noted several: Verified/unverified (was a passport shown), identification number of organisation and information about the registrar. Jaap suggested this should be published. He also asked how many DNS servers were involved as he could find only 6, although Sergey said there were 11. Sergey offered to show him these on a map offline.

Another attendee, and a potential user of the domain, asked how many of those who registered are real users and how many are planning to use domains for advertising and such? Sergey noted that 30% of registered domains have already been delegated, obviously some big brands do redirect Cyrillic domains to their main sites.

Sergey also clarified that RU-CENTRE did take options on domains for its Latin domain name users for their Cyrillic equivalents. Doing this manually, in theory, prevented what happened in other TLDs during land rush periods. Cybersquatters have very sophisticated software that swoops in and grabs domains. The manual process bypassed this to a large extent.

M. Discussion Panel - Reverse DNS Considerations for IPv6
Kostas Zorbadelos, OTE
Dave Freedman, Claranet
Richard Barnes, BBN Technologies

http://ripe61.ripe.net/presentations/139-Ripe-61-rDNS-kzorba-freedman.pdf
http://ripe61.ripe.net/presentations/225-ReverseDNSApplications.pdf

The two presentations formed the basis for a panel session about the DNS challenges operators might face when deploying IPv6 to their customers. The presentations focused on scaling and security (i.e. DNSSEC) and provided example solutions. Following the presentation, the panel asked for input and questions from the audience.

George Michaelson feels that having this discussion is a good thing. He wondered if there exists a killer justification for having DNSSEC in reverse, something that would take it from being interesting to authoritative. From an RIR perspective, the cost of an NXDOMAIN response remains high while compliance is low. For IPv6 it gets proportionally larger, throwing up scaling implications.

Dave Freedman responded that responses in transit do indeed produce patchy responses due to a mix of signed and unsigned delegations. It appears to be part of a larger issue of how users manage their host resources.

When responding to Georg'e question, Richard Barnes noted that the two solutions he presented might form the basis of killer applications. Kostas pointed out that RIRs have different needs to ISPs. The latter rarely act unless they can identify benefits to their customers.

Shane Kerr commented that we are at the stage now where reverse DNS has the potential to become both interesting and useful. The size of the v6 address space certainly does make things harder, but he felt already some interesting applications are emerging. He compared the current situation to the emergence of v6 some years ago, when people buried their heads.

A year or so back, there was discussion at the IETF about producing some form of draft that identified when ISPs should provide reverse delegation. It was rejected. Prescription may not be the solution. Shane suggested a lighter approach, a simple proposal saying IPv6 reverse DNS is optional. There remain specific issues before this can happen, and he offered his support and help with resolving this, but did conclude that we may have to endure the current situation for a while.

Owen DeLong said that reverse DNS should be seen as important. Hurricane Electric maintain a website where tunnel brokers can log in and put their records into Hurricane nameservers for reverse DNS. It works well. Owen said that while wildcarding makes sense for NAPTR, it is less useful for static hosts.

Lorenzo Colitti of Google noted that Reverse DNS is largely unmaintained and rife with lame delegations. Its main use has been for geolocation. However, Lorenzo did caution that it is useful and added support for dynamic DHCP tie in with a wildcard approach because it keeps things with the admin boundary for an ISP.

Dave responded that ahead of the meeting, he had looked into how reverse DNS is being used and found the main application relying on it is IRC. He said most user cases need to decide if they need host or network information. There is administrative overhead and complexity if users go through the host without any obvious reason. Richard noted that times when this might happen is when a user wants to know which network they are in. He conceded that this does put extra load on query servers and agreed with Dave that wildcarding might open up a whole new can of worms.

Lars Liman warned against using wildcards at the network level as there exists a need to reap out functionality for NAPTR or other records. Dave agreed that if holes are punched, they must be within the correct resource types.

On the subject of putting a period between each HEX character, Kostas asked whether a distributed rDNS large scale setup was used in practice by any Provider, using also Dynamic DNS updates and if this would scale.

A fellow participant commented that it would certainly scale since distribution is an essential DNS feature.

Both speakers agreed that this all comes down to cost.

Alex Band, speaking on behalf of the RIPE NCC offered its services to host a Reverse DNS solution for DNSSEC if there is interest. Dave Freedman stated he would certainly be interested.

Peter Koch rounded up the discussion by asking the group to continue providing input and feedback on the presentations that had been given with the ultimate aim of producing agreed guidelines on Reverse DNS.

Z. A.O.B.

There was no other business.