APRICOT 2006

DNS operations SIG

Minutes

Thursday 2 March 2006, Perth Convention and Exhibition Centre, Perth, Australia

Meeting commenced: 4:00 pm

Chair: George Michaelson, APNIC (on behalf of Joe Abley, ISC)

The Chair introduced the session and explained the agenda. He passed on apologies from Joe Abley (Chair), who was not able to attend this meeting.

Contents

  1. Review of open action items
  2. Lame DNS policy status update
  3. ip6.int deprecation project report
  4. BGP anycast node requirements for authoritative name servers
  5. Reverse DNS lookup failure and its influence to JP community
  6. APNIC reverse DNS management roadmap
  7. DNSSEC, APNIC & how EPP might play a role
  1. Review of open action items

  2. George Michaelson, APNIC

    Presentation [ppt | pdf]

    Questions and discussion

    • Action dns-20-003: Secretariat to gather statistics about the extent of undelegated domains and report back to the DNS SIG at APNIC 21.

      Update: Open. Activities continuing. Report on activities to date to be presented later in the SIG.

    • Action dns-20-002: Secretariat to gather statistics revealing the breakdown of ip6.int lookups and report back to the DNS SIG at APNIC 21.

      Update: Done. Report to be presented later in the SIG.

    • Action dns-20-001: Pending approval at each remaining stage of the policy proposal process, Secretariat to implement proposal [prop-030-v001]

      Update: Open. Deprecation on schedule to occur on 1 June 2006.

    Action items

    • None.

    Top

  3. Lame DNS policy status update

  4. George Michaelson, APNIC

    Presentation [pdf]

    This presentation outlined the history of the lame DNS project. The speaker displayed a graph that indicated that APNIC had probably reached a maximum level of effectiveness in removing lame DNS delegations. Since the project began, there has been a reduction in lame delegations from 18 percent of all delegations to eight percent. The speaker reported that APNIC has still not moved on to deal with IPv6 lames.

    The speaker stated that the next steps for APNIC could include hosting secondary DNS services for APNIC account holders. Potential bases for these services were Hong Kong, Japan, Australia, and the USA. MyAPNIC could be the interface for APNIC account holders to manage their secondary DNS if APNIC chooses to pursue hosted secondary DNS services.

    Questions and discussion

    • There was a comment that even if APNIC offered to host secondary DNS, this would not solve all the lame DNS issues. It was explained that some DNS is lame because the delegate has incorrectly configured the server. When this is the case, APNIC may not be getting access to the master if APNIC acts as a slave DNS server for them.
    • It was noted that RIPE NCC acts as slave DNS for some networks, but that some organisations had requested RIPE NCC stop this service as it stopped others being able to offer a fee-paying version of the service.
    • The speaker confirmed that the lame delegations project included legacy space but not space managed by the NIRs at this time.

    Action items

    • None.

    Top

  5. ip6.int deprecation project report

  6. Sanjaya, APNIC

    Presentation [ppt | pdf]

    This presentation reported on the project to deprecate ip6.int. The presenter explained that use of ip6.int had been deprecated in RFC 3152 in 2001, that APNIC had stopped accepting new ip6.int delegations in 2004, but was still answering ip6.int queries. The speaker noted that most queries for ip6.int originated from faulty Linux implementations, or were related nameserver infrastructure queries that did not reflect end user requests (SOA refresh).

    The speaker summarised the coordination work APNIC had conducted for the project. APNIC had worked with the other RIRs to implement a program to cease ip6.int on the same date, 1 June 2006. The NIRs have also been contacted to ensure that the deprecation would not result in any scheduling conflicts. APNIC intends to try and contact the small remaining number of persistent ip6.int querying systems and advise them of the pending deprecation.

    In closing, the speaker suggested participants view an interesting presentation Kazu Yamamoto made in the IPv6 SIG that discussed the technical implications of deprecating ip6.int.

    Questions and discussion

    • It was pointed out that some of the queries visible in the ip6.int query statistics showed some early visibility of DNSSEC in use.

    Action items

    • None.

    Top

  7. BGP anycast node requirements for authoritative name servers

  8. Yoshiro Yoneya, JPRS

    Presentation [pdf]

    This presentation outlined the activity JPRS is undertaking to develop guidelines for ccTLD and other operators wishing to use IP anycast. The speaker explained that the intention is to target the IP anycast guidelines at TLD DNS servers since TLDs have highly visible zones and higher frequency updates than the root servers.

    The speaker reported that IP anycast is already widely deployed in root servers and that, currently, over 50 TLDs use anycast as well. In addition, DNS hosting services are also using anycast. The speaker explained that anycast in DNS increases reliability.

    The speaker explained that principles to use when deploying anycast include using known, mature techniques, and having each anycast node use the same consistent policy.

    The guidelines focus on issues such as selection of ISP to gain maximum geographical and topographical diversity, anycast node location, construction and maintenance costs, and measurement and monitoring methods.

    In closing, the speaker gave an overview of future work on the guidelines, including criteria for the selection of server hardware and software.

    Questions and discussion

    • Discussion in the meeting confirmed real-world experiences are reflected in this document. The author was encouraged to seek IETF DNSOP working group adoption of the document.
    • The flattening effect of layer 2 network structures such as MPLS and its impact on the apparent BGP best path and RTT was noted and suggested for inclusion in the document.

    Action items

    • None.

    Top

  9. Reverse DNS lookup failure and its influence to JP community

  10. Toshiyuki Hosaka, JPNIC

    Presentation [pdf]

    This presentation reviewed the issues arising from the 23 October 2005 reverse DNS failures for JP and KR networks and ERX networks from the APNIC region maintained in ARIN reverse DNS zones. Affected networks were denied connection and some email messages could not be relayed. The speaker noted that the impact varied depending on application settings.

    The speaker explained that there had been a delay between the initial discovery of the problem and the issuing of an official report from APNIC. In Japan, some ISPs suggested that networks be contacted by phone or fax, rather than email or web, as soon as possible by JPNIC when problems occur. It had also been suggested that JPNIC maintain a 24/7 contact to respond to emergencies.

    The speaker reported that improvements had already been implemented at both APNIC and JPNIC. These improvements include an escalation procedure defined between JPNIC and APNIC, and APNIC's commitment to increase visibility of service status. APNIC has also changed its scheduled maintenance to weekdays rather than weekend to make communication with technical contacts easier.

    Questions and discussion

    • None.

    Action items

    • None.

    Top

  11. APNIC reverse DNS management roadmap

  12. Terry Manderson, APNIC

    Presentation [ppt | pdf]

    This presentation gave an overview of the existing reverse DNS update processes and outlined how APNIC plans to make these processes less problematic in future by using XML web services. The major benefit of the changes would be the stable generation of DNS. The speaker outlined issues involved in the transition to the new processes.

    Questions and discussion

    • It was commented that 'in-bailiwick' nameservers (naming the nameserver inside the zone itself, which requires registration of 'glue' records) could be useful. It was however noted that there is not universal support for glue records and that APNIC would defer including glue records until there is wider agreement on the issue in the community.
    • It was acknowledged that, depending on the web browser used, there could be problems displaying XML with XSLT. It was explained that the prototype displayed in the presentation was developed for functionality rather than visual representation, and that representation issues would be addressed in the future.
    • It was noted that APNIC had considered using SOAP, but that given the framework of APNIC's services and how MyAPNIC works, the REST model was more appropriate. It was explained that APNIC needs to support multiple character sets, which is possible using REST and XML.

    Action items

    • None.

    Top

  13. DNSSEC, APNIC & how EPP might play a role

  14. Ed Lewis, NeuStar

    Presentation [ppt | pdf]

    This presentation explained how EPP, which was designed for provisioning the domain name registrar to registry dialogue, rather than IP address management, could be of benefit to the RIRs.

    The speaker noted that EPP has extensions for DNSSEC, which adds a means to transfer DNSSEC administrative data via the provisioning interface for domains. This would be useful for DNNSEC - the parent has to hold a DS record (about 20 odd hex character hash for the record). It was noted that, so far, only RIPE NCC has signed its reverse zones.

    The speaker noted that while DNS data does not need frequent updates, DNSSEC does require constant updates. The advantage of this approach is that live DNS update is simple to implement in this framework.

    The speaker completed the presentation by performing a live demonstration of EPP applied to reverse DNS management.

    Questions and discussion

    • The speaker clarified that the EPP/DNNSEC model was based on Scott Hollenbeck's draft.
    • It was noted that the job of a registry is to publish records not create the records.
    • When asked if source code was available, it was explained that it was internal code for demonstration purposes. However, the speaker was aware of others doing similar activities related to EPP and IP addresses, so considered this methodology to be viable.
    • APNIC is considering the implications of providing live updates in reverse DNS registrations.
    • It was noted that dynamic updates are already a key component of many TLDs because operators do not want to have to upload a whole new file just to add a few changes.
    • APNIC has the added burden of complexity introduced by managing 'shared zones' of historical space.
    • It was explained that whenever anyone submits a domain object to APNIC via auto-dbm, APNIC checks the nameservers first before processing the submission further. If APNIC changes the system and allows people to send updates via XML, it would be unlikely that APNIC would continue to check for nameservers. It was also noted that APNIC procedures currently are not dynamic.
    • There was a comment that whois should also be dynamic. It was stated that although RIPE software has NRTM, it is not perfectly dynamic.
    • There was a comment that dynamic updates could be utilised by spammers to inject DNS, send spam, and then remove the DNS.

    Action items

    • None.

    Top

Meeting closed: 5:45 pm

Minuted by: Sam Dickinson

Open action items

  • Action dns-20-003: Secretariat to gather statistics about the extent of undelegated domains and report back to the DNS SIG at APNIC 21.

    Update: Open. Activities continuing.

  • Action dns-20-001: Pending approval at each remaining stage of the policy proposal process, Secretariat to implement proposal [prop-030-v001]

    Update: Open. Deprecation of ip6.int reverse DNS service in APNIC is on schedule to occur on 1 June 2006.

Minutes | DNS operations SIG

Top

Last modified: | © 1999 - APNIC Pty. Ltd.
Contact us | Privacy statement