[sig-policy] prop-038-v001: Amending APNIC's lame DNS reverse delegation
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,
Toshiyuki Hosaka
Policy SIG
hosaka at nic dot ad dot jp
_______________________________________________________________________
prop-038-v001: Amending APNIC's lame DNS reverse delegation policy
________________________________________________________________________
Author: Terry Manderson, APNIC
<terry at apnic dot 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