Dear SIG members

The proposal "Amending APNIC's lame DNS reverse delegation policy" has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 22 in Kaohsiung, Taiwan, 4-8 September 2006. You are invited to review and comment on the proposal on the mailing list before the meeting.

The proposal's history can be found at:

http://www.apnic.net/docs/policy/proposals/prop-038-v001.html

Regards

Kenny Huang Policy SIG huangk@alum.sinica.edu

_______________________________________________________________________

prop-038-v001: Amending APNIC's lame DNS reverse delegation policy ________________________________________________________________________

Author: Terry Manderson, APNIC terry@apnic.net

Version: 1

Date: 7 August 2006

Introduction ------------ This is a proposal to modify APNIC's existing method for identifying and removing lame DNS reverse delegations, by adopting a definition of lameness that is consistent with generally-accepted best practice and other RIRs (where relevant).

This proposal supersedes the previously adopted proposal, "prop-004-v001: A proposal for sweeping lame DNS reverse delegations".

Proposal summary ---------------- The APNIC Secretariat will check DNS reverse delegations to ensure that:

- a delegated nameserver provides a valid answer for a SOA record of the domain - the answer returned is authoritative (AA bit set)

The APNIC Secretariat will monitor all delegated nameservers in all relevant zones for lameness by way of UDP DNS query using the checks described above. If these checks fail then the delegation will be removed from the parent zone after reasonable attempts have been made to contact the domain contacts.

Situation in other RIRs -----------------------

LACNIC

LACNIC is actively monitoring and correcting reverse delegations in its region, according to the following test:

"A DNS server registered in LACNIC's system shall be considered to have Lame Delegation problems if a query of the SOA record of the DNS server does not provide an authoritative answer for said record."

http://www.lacnic.net/en/politicas/lame.html

ARIN

ARIN is actively monitoring and correcting reverse delegations in its region, according to the following test:

"A name server is tested by asking for data that has to be present in a zone, the script requests the SOA resource record. If the name server responds with a positive answer and claims to be authoritative, the name server is okay for that zone. Any other answer indicates that the name server is lame for the tested zone."

http://www.arin.net/reference/lame_delegations.html

RIPE NCC

The RIPE community is currently discussing the issue of monitoring and correcting reverse delegations in its region:

http://www.ripe.net/ripe/wg/dns/r52-minutes.html

AfriNIC

No activities or policies on lame delegations have been published by AfriNIC.

Proposal details ----------------

APNIC already has an active lame DNS policy; this proposal is to amend the existing policy by adopting a definition of lameness that is consistent with generally-accepted best practice and other RIRs.

Under this proposal, a DNS reverse delegation will be considered lame if a delegated nameserver for a domain fails to return a valid authoritative answer for the domain's SOA.

Two weeks after EC approval the APNIC Secretariat will apply a reverse delegation monitoring procedure which checks that:

- a delegated nameserver of a domain provides a valid answer for the SOA record - the answer returned is authoritative (AA bit set)

The data in the SOA will not be checked for consistency between nameservers (that is, the zone serial will not be checked to see if it is synchronised with other nameservers).

Once the delegation has been identified as lame, the Secretariat will follow a procedure which includes:

- confirming the delegation is lame - making reasonable attempts to contact the domain contacts

This operational procedure will be posted on the APNIC website prior to implementation and updated by the APNIC Secretariat as required.

Once the delegation has been removed it can only be re-enabled by an authorised resource holder. Advantages and disadvantages of adopting the proposed policy ------------------------------------------------------------

This policy brings APNIC in line with the majority of other RIRs on the view of lame DNS and what is currently considered best practice.

Effect on APNIC members -----------------------

Members will not see any adverse effects of this policy.

Effect on NIRs --------------

NIRs may need to consider their current mechanisms for maintaining and checking DNS delegations.

References ----------

APNIC, A proposal for sweeping lame DNS reverse delegations http://www.apnic.net/docs/policy/proposals/prop-004-v001.html