DNS Workshop

Monday May 11, 2009

Notes from DNS Working Group at RIPE 58, Part 1

My notes from the RIPE 58 DNS Workinggroup (DNS-WG) sessions:
  • Shane Kerr (ISC) - BIND 10

    Shane gave some insights in the goals of the new BIND 10 project at ISC. BIND 9 is getting old and has some issue with performance and maintainability. The process model used for BIND 9 has been "en vouge" when BIND 9 was designed, but it has proven to be non-optimal for a server daemon that is handling a huge amount of small request packages. The goal with BIND 10 is to getting closer in performance with NSD and unbound. Another issue with BIND 9 is that the sourcecode is hard to understand and to change for new project members. This has been an issue hindering interested parties to do their own customizations to the BIND 9 sourcecode. Although BIND 9 is an open source project, only programmers for ISC have worked on the code and almost no outside contribution has been seen. BIND 10 source code is planned to be more modular and more easy to understand, to attract outside developers to contribute and customize BIND 10.

    BIND 10 is planned to have APIs and interfaces to integrate with existing provisioning systems and workflows. Integration into Microsoft Windows Operating Systems will worked on.

    The BIND 10 project timeframe is set for 5 years, with the 1st test version to be due in April 2010.

  • Anand Buddhev (RIPE NCC)- RIPE NCC Reverse Tree Lame Delegation Reports

    Anand gave a report on the reverse DNS tree lameless check done by RIPE NCC. The RIPE NCC is checking for lame delegations in the reverse DNS tree (the "in-addr.arpa." and "ip6.arpa." namespace). The presentation (linked above) contains the definition of a non-lame answer:

    • Every name server of each zone is resolved into A and AAAA records - several attempts are made in case of temporary failures
    • Every IP address found is queried for the SOA record of the associated zone - several attempts are made in case of temporary failures
    • The query is done over UDP and is non- recursive
    • if there was a response:
      • Response from the same address that the query was sent to
      • RCODE is "NOERROR"
      • Response has AA bit set
      • QNAME in the response and query is the same
      • Only one SOA record is returned

    The RIPE NCC has an DNS lameness FAQ online: http://www.ripe.net/info/stats/dns-lameness/faq.html

    Any answer that is not matching the criteria is seen as an lameless error, and an E-Mail is send to the contact person owning the IP Address space for this part of the reverse DNS delegation.

    Initially the lameness for the RIPE part of the reverse DNS tree was about 6%. After some runs in February and March 2009 the number of lame delegations has gone down to 5%.

    Although the DNS lameness checks where done on request from the RIPE DNS WG in 2006 (see RIPE-400), there was a controversial discussion in the group on the usefulness of the tests. Some participants were arguing that the lameness mostly effects the party receiving the delegation. Other said that the instruments to measure the effect of lameness must be improved first to be able to measure the effect of the checks and the lameness on the DNS System. Other participants found the service useful, as did most of the DNS delegation owners that received E-Mail from RIPE NCC. Further discussion on this topic will take place on the DNS WG Mailinglist.


Post a Comment:
  • HTML Syntax: Allowed