Minutes

DNS operations SIG

Thursday 24 February 2005, Kyoto International Conference Hall

Meeting commenced: 2:10 pm

Chair: Joao Luis Silva Damas

The Chair introduced the session and explained the agenda.

Contents

  1. Review of previous open action items
  2. Deprecating ip6.int
  3. Improving reverse DNS lookup performance
  4. Lame delegation status report
  5. NS server monitoring
  6. DNSSEC: What, where and how
  7. ERX activity report
  8. BIND progress and F-root updates
  1. Review of previous open action items

  2. Joao Luis Silva Damas, ISC

    Presentation [ppt | pdf]

    dns-16-001: APNIC Secretariat to implement proposal "Lame delegation cleanup revised" (prop-004-v001).
    Update: Done. Implemented fourth quarter 2004.

    Top

  3. Deprecating ip6.int

  4. Geoff Huston, APNIC

    Presentation [ppt | pdf]

    The presenter reported on the background to the creation of the ip6.int delegation namespace and the reasons behind the decision to deprecate ip6.int. The speaker explained that it was confusing to have both ip6.int and ip6.arpa delegations active at the same time. The speaker noted that as of 1 June 2005, ip6.int would no longer be a part of the IPv6 standard.

    The presenter explained that RIRs have been requested to work with their communities to adopt a schedule to deprecate ip6.int delegations.

    Questions and discussion

    • There was a question about the status of 3FFE space in relation to ip6.int and ip6.arpa. It was explained that just because ip6.int would no longer be part of the IPv6 standard did not mean all networks had to drop it at that point. If a network operator wanted to continue for a while longer, it would be possible. It was suggested that APNIC could take action to deprecate ip6.int earlier since APNIC was not in the 3FFE space. The 3FFE will be occupied until June 2006, so ip6.int could be continued in that space until it is vacated.
    • It was questioned whether LIRs at JPNIC with existing ip6.int delegations should delete those and register ip6.arpa delegations. It was suggested that those LIRs should be advised to populate the ip6.arpa delegation space and that if any LIR wished to register new ip6.int delegations, they should be questioned why they would want to do this.
    • The four RIRs were asked if new ip6.int delegations were currently being accepted. LACNIC stated that both ip6.int and ip6.arpa are currently accepted. RIPE and ARIN representatives thought that both spaces were still possible but neither could not be certain. It was established that both spaces were still possible in the region.

    Action items

    • None.

    Top

  5. Improving reverse DNS lookup performance

  6. Kazunori Fujiwara, JPRS

    Presentation [pdf]

    The presentation outlined how JPRS changed the way of handling glue in June 2004, which resulted in some problems. The presentation discussed the impact of glue, and consideration of glue-related issues in forward and reverse-DNS.

    Questions and discussion

    • It was commented that while it was best to avoid glueless delegations, one problem is that the parent delegation information can become radically different to the child delegations over time. It was asked how that could be resolved.
    • It was noted that the same parent/child discrepancy happens in the forward DNS tree.
    • It was explained that most RIRs have lame delegation policies in place. However, it is an issue that also affects NIRs and LIRs.
    • An IANA representative noted that IANA/ICANN is working on a registry system that will have glue records for all zones it manages. He noted that if community discussion backs the system, it could implement it as a solution at the IANA level.
    • The Chair suggested it may be appropriate to use the mailing list for more discussion and possible recommendations on the glue records in the reverse DNS tree.

    Action items

    • None.

    Top

  7. Lame delegation status report

  8. Terry Manderson, APNIC

    Presentation [ppt | pdf]

    The presentation gave an update on the lame delegation project. The presenter explained that to test for lame delegations, nameservers were tested for 15 days from Brisbane and Tokyo. Following this, there are attempts to email the domain contact for 45 days. If the domain contact fails to update the delegation within this time, the lame delegation is removed from the zone.

    The speaker reported that lame delegations were taking an average of two days to be resolved.

    The presented explained that two issues had arisen from the policy. The first was IPv6 lameness. APNIC does not currently check for IPv6 lameness due to the emerging status of IPv6. The second issue was the fact that some contacts are responsible for many lame DNS delegations, so there is a need to devise a method to contact these people without sending an individual email for each and every lame DNS. Some contacts are responsible for up to 385 lame delegations.

    The presenter noted that while some servers are lame one day, they are fine the next. It was explained that lame delegations that alternate in this way would never progress beyond the initial 15 day period.

    It was reported that since the project was implemented in November, the percentage of lame delegations had reduced from 18 percent to 16 percent.

    The speaker explained that one of the major issues for networks identified during the project what that some networks did not know how to configure a nameserver to be authoritative.

    Questions and discussion

    • None.

    Action items

    • None.

    Top

  9. NS server monitoring

  10. Olaf Kolkman, RIPE NCC

    Presentation [ppt | pdf]

    The presenter gave an overview of the uses of DNS measurement s and the need for better measurements from multiple locations to average out the outlying effects of DNS.

    It was explained that the RIPE NCC did not measure DNS queries used for actual name resolution. Nor does RIPE NCC measure the total DNS service quality (the user experience).

    The speaker noted that DBSMON is used by a large cross section of Internet users, such as network operators and TLD operators, and the Internet community at large.

    Questions and discussion

    • The speaker was questioned if RIPE planned to deploy the DBMON service on non-TTN boxes. It was explained that the issue had not been discussed in depth at the RIPE NCC.
    • There was a question to add a function to DBMON to allow queries to see if all DNS managed by a network serve the same SOA record.
    • There was a comment that DNSMON is not real time and therefore cannot be used for real time monitoring. The delay in DBMON could be up to one hour. It was explained that RIPE NCC give access to the data to DSMON customers two hours earlier than general users to allow DNS operators to fix problems before they starting receiving questions from the public.

    Action items

    • None.

    Top

  11. DNSSEC: What, where and how

  12. Olaf Kolkman, RIPE NCC

    Presentation [ppt | pdf]

    The presenter explained how data flows through the DNS and where the flow can be vulnerable. DNS vulnerabilities allow attacked to impersonate the master, make unauthorised updates, or perform cache impersonation.

    The presenter explained how DNSSEC could provide data security in the DNS flow. It was reported that after 10-15 years of developing at the IETF, an RFC would be published soon.

    It was noted that while software is available for deploying DNSSEC today, it is difficult to use.

    It was reported that while the IETF was working on improvements, these could take a while to eventuate.

    The speaker explained that it might not be necessary to implement DNSSEC on all sites. For example, it may not be necessary when reading a newspaper online, but it may be necessary for online banking sites.

    The presented discussed problem areas in DNSSEC such as key management and NSEC walk.

    The speaker reported that the .se TLD hoped to implement DNSSEC by the end of this year, which would make it the first TLD to do so.

    Questions and discussion

    • None.

    Action items

    • None.

    Top

  13. ERX activity report

  14. George Michaelson, APNIC

    Presentation [ppt | pdf]

    The presented reported that the ERX project had been completed. The speaker explained some of the difficulties experienced, such as overlaps in resource records.

    The speaker noted that, within the APNIC region, the project had some overlap with two APNIC policies: the lame DNS policy and the protection of historical resources policy.

    The project explained that due to the ERX project, it was necessary to share zone management for the ERX space with the other RIRs and the NIRs.

    Questions and discussion

    • Comment: There was a question whether the ERX project could open the door to competing RIRs where networks could choose which one to register resources with? The speaker declined to comment.

    Action items

    • None.

    Top

  15. BIND progress and F-root updates

  16. Joao Luis Silva Damas, ISC

    Presentation [pdf]

    The presentation provided an update of recent developments in F-root nameserver operations and BIND developments.

    The presenter reported that a recently anycast site for the F-root was Osaka. Amsterdam would soon be added as an anycast F-root nameserver. The speaker explained that the F-root operators were still looking for other locations to host anycast F-root nameservers.

    The speaker noted that BIND has 3 new releases: 9.3.0, BIND 9.2.4 (a bug fix for 9.2.3) and BIND 8.4.5 (a bug fix for 9.4).

    The presenter reported that BIND 8 and 9.2.x were considered end of life. The new tree was now BIND 9.3.

    The speaker mentioned new features for BIND 9.3 such as DNSSEC bis and IPv6 extended support.

    Questions and discussion

    • None.

    Action items

    • None.

Meeting closed: 5:50 pm

Minuted by: Sam Dickinson

Top

Open action items

  • None.

Minutes | DNS operations SIG


Top of page
Programme | SIGs | Sponsorship | APNIC meetings | APRICOT 2005 | APNIC home
Last modified: Monday, 14-Mar-2016 10:53:25 EST | © 1999 - 2022 APNIC Pty. Ltd.
Contact us | Privacy statement