[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NIR Operational Draft - DNS
Dear Anne and all,
Regarding the third option for managing Reverse DNS delegations, I would like to ask couple of questions.
1. In case that x.x.in-addr.arpa Inverse DNS is converted to flat file,
does NS record has to include information about ISPs delegated in /24, or have only information about KRNIC and other sceondary organizations delegated in /16?
e.g.) the following is a flat file for registering 211.210.in-addr.arpa Inverse DNS.
======================================================================================
$TTL 43200
IN NS ns.krnic.net.
IN NS ns.kreonet.re.kr.
IN NS kr2nd.kornet.net.
IN NS kr2ld.dacom.co.kr.
IN NS kr2nd.hitel.net.
IN NS usns.dacom.co.kr.
240.211.in-addr.arpa. IN TXT "Generated at Tue Nov 28 12:00:26 2002 with 6 NS records."
======================================================================================
2. In the file generation for the authorization and checksum of Zone file,
1) If KRNIC provides FTP server for APNIC to download file, *.asc file(that is made of PGP key for e-mail authorization) is necessary?
2) In PGP key generation, do we have to make e-mail address as APNIC admin e-mail, or KRNIC admin e-mail?
3) Do we have to generate PGP key (generated in 2)) whenever flat file is created in /16, or just generate once as it is authorized e-mail address?
Regards,
Billy MH Cheon
> Dear Colleagues,
>
> At the recent Open NIR meeting during the APNIC meeting in Kitakyushu,
> APNIC proposed two methods of Reverse DNS management under the direct
> allocation scheme for NIRs. These proposals were accepted by the community
> subject to formal inclusion in the 'Operational Policies for NIRs in the
> APNIC region' document at:
>
> http://www.apnic.net/docs/drafts/apnic-draft-nir-policy-v003.html
>
> Since then, more thought and investigation has been gone into this issue.
> As a result, APNIC now wishes to propose a third option for managing Reverse
> DNS delegations, which it is believed is simpler and more manageable. It is
> based on the processes defined for the Early Registration Transfer Project
> (ERX). More details about this project can be found at:
>
> http://www.arin.net/registration/erx/
>
> This procedure uses simple flat files which can be directly converted to
> and from existing BIND DNS zonefiles, with additional external sign and
> checksum files for verification.
>
> In detail, the process would be as follows:
>
> 1) The NIR will generate a conforming flat file view of the zone,
> and place it in a publicly visible area on web, ftp, or ssh/rsync
> servers at the NIR. A description of the required "flat file"
> view is included below.
>
> 2) On an agreed cycle, APNIC will fetch this file, parse it and
> include its zone information in the parent /8 zonefile.
>
> Where duplicates exist, any APNIC object that results in a
> zonefile entry will override any matching NIR-asserted object.
> The NIR will be notified of any such overrides.
>
> Any NIR-asserted object that lies outside the ranges allocated
> to the NIR will be ignored. Again, the NIR will be notified of
> this.
>
> This method of managing reverse DNS has several advantages over the
> previously documented options. First, the current NIR zone generation
> process can remain substantially unaltered. That is, the NIR must cease
> to assert the zone (by removing it from named.conf) but all other processes
> can remain unaltered. This reduces the impact on unrelated third parties
> and reduces the overhead to the NIR.
>
> Second, APNIC can make code available which converts from the zonefile
> format to the exchange format, generates the checksum and signature files,
> and data transfer, using well understood methods already in use by APNIC
> and the NIRs.
>
> Finally, the process is resilient. Zone updates cannot apply if the
> checksum and signature do not match. Simple checks can prevent the entire
> zonefile from being accidentally deleted. The process will be performed
> under revision control, so any errors can be quickly fixed. Fully detailed
> operational procedures will be developed for this process in conjunction
> with the 1 December deadline.
>
> We welcome any comments, questions, and queries regarding this proposed
> addition to the methods available for managing Reverse DNS zones. Please
> send your feedback to the <nir-discuss> mailing list .
>
> Appendix - Details of flat file view of a zone
> ----------------------------------------------
>
> Each NIR should create a directory on its ftp site, from which the files
> will be downloaded, such as:
>
> - ftp://ftp.<nir>.net/pub/zones/<zero-padded-slash8>-<nir>
> - ftp://ftp.<nir>.net/pub/zones/<zero-padded-slash8>-<nir>.md5
> - ftp://ftp.<nir>.net/pub/zones/<zero-padded-slash8>-<nir>.asc
>
> The suggested format and content of the data to be provided by the NIR is
> as follows:
>
> o The data format should be in the format of DNS resource records, i.e.,
>
> $ORIGIN.
> <reverse IP>.in-addr.arpa. [TTL] NS <hostname>.
>
> o Initially, the transferred data should only include NS resource records.
> If other RR types are provided, APNIC may ignore them.
>
> o The file may also include BIND-style comments.
>
> o The last record should be as follows:
>
> <NIR>.<slash16>.in-addr.arpa. TXT "Generated at <ISO timestamp GMT> with<n> NS records.
>
> <NIR>.<slash24>.in-addr.arpa.TXT "Generated at <ISO timestamp GMT>with <n> NS records.
>
> Examples of data made in conformance with this specification are available
> at:
>
> ftp://ftp.apnic.net/pub/zones/
>
> Please note: APNIC only supports passive FTP connections.
>
> The format is legal BIND9 zonefile contents, except there is no SOA record,
> and there are restrictions on the DNS RR types permitted.
>
> The associated signature files for a given zone are called <zone>.asc and
> <zone>.md5. the MD5 file format is the BSD Unix format, which is *not* the
> same as the normal Linux MD5 format. This was deliberately chosen because it
> is actually a better format to show the MD5 information and is well defined.
>
> The code to generate these files is available from APNIC. Client side code
> to use the files, and generate complete zones is in development for ERX and
> will also be made available.
>
> Kind regards,
>
> Anne
> _____________________________________________________________________
> Anne Lord, Manager, Policy Liaison <anne@apnic.net>
> Asia Pacific Network Information Centre phone: +61 7 3858 3100
> http://www.apnic.net fax: +61 7 3858 3199
> _____________________________________________________________________
