reply: reply: [Opendnssec-develop] signed serial > unsigned serial?

[wangguodong]

-----邮件原件-----
发件人: Jakob Schlyter [mailto:jakob at kirei.se] 
发送时间: 2013年9月11日 15:27
收件人: wangguodong
抄送: 'Yuri Schaeffer'; opendnssec-develop at lists.opendnssec.org
主题: Re: reply: [Opendnssec-develop] signed serial > unsigned serial?

>On 11 sep 2013, at 09:15, "wangguodong" <wanggd at conac.cn> wrote:

>> Because in the NEWG TLD applicant Guidebook, the registry's zone file 
>> should be accessed by a third party.( AGB SPECIFICATION 4,P43)

>Is the 3rd party zone access for an unsigned or signed zone?


The AGB mentions the unsigned zone should be accessed by a third party. I
have copy the relative content below:

2. Zone File Access
2.1. Third-Party Access
2.1.1. Zone File Access Agreement. Registry Operator will enter into an
agreement with
any Internet user that will allow such user to access an Internet host
server or servers designated by
Registry Operator and download zone file data. The agreement will be
standardized, facilitated and
administered by a Centralized Zone Data Access Provider (the “CZDA
Provider”). Registry Operator
will provide access to zone file data per Section 2.1.3 and do so using the
file format described in Section
2.1.4. Notwithstanding the foregoing, (a) the CZDA Provider may reject the
request for access of any
user that does not satisfy the credentialing requirements in Section 2.1.2
below; (b) Registry Operator
may reject the request for access of any user that does not provide correct
or legitimate credentials under
Section 2.1. 2 or where Registry Operator reasonably believes will violate
the terms of Section 2.1.5.
below; and, (c) Registry Operator may revoke access of any user if Registry
Operator has evidence to
support that the user has violated the terms of Section 2.1.5.
2.1.2. Credentialing Requirements. Registry Operator, through the
facilitation of the
CZDA Provider, will request each user to provide it with information
sufficient to correctly identify and
locate the user. Such user information will include, without limitation,
company name, contact name,
address, telephone number, facsimile number, email address, and the Internet
host machine name and IP
address.
2.1.3. Grant of Access. Each Registry Operator will provide the Zone File
FTP (or other
Registry supported) service for an ICANN-specified and managed URL
(specifically,
<TLD>.zda.icann.org where <TLD> is the TLD for which the registry is
responsible) for the user to
access the Registry’s zone data archives. Registry Operator will grant the
user a non-exclusive, nontransferable,
limited right to access Registry Operator’s Zone File FTP server, and to
transfer a copy of
the top-level domain zone files, and any associated cryptographic checksum
files no more than once per
24 hour period using FTP, or other data transport and access protocols that
may be prescribed by
ICANN. For every zone file access server, the zone files are in the
top-level directory called
<zone>.zone.gz, with <zone>.zone.gz.md5 and <zone>.zone.gz.sig to verify
downloads. If the Registry
Operator also provides historical data, it will use the naming pattern
<zone>-yyyymmdd.zone.gz, etc.
2.1.4. File Format Standard. Registry Operator will provide zone files using
a subformat
of the standard Master File format as originally defined in RFC 1035,
Section 5, including all the
records present in the actual zone used in the public DNS. Sub-format is as
follows:
1. Each record must include all fields in one line as: <domain-name> <TTL>
<class> <type>
<RDATA>.
2. Class and Type must use the standard mnemonics and must be in lower case.
43
NEW GTLD AGREEMENT SPECIFICATIONS
3. TTL must be present as a decimal integer.
4. Use of /X and /DDD inside domain names is allowed.
5. All domain names must be in lower case.
6. Must use exactly one tab as separator of fields inside a record.
7. All domain names must be fully qualified.
8. No $ORIGIN directives.
9. No use of "@" to denote current origin.
10. No use of "blank domain names" at the beginning of a record to continue
the use of the domain
name in the previous record.
11. No $INCLUDE directives.
12. No $TTL directives.
13. No use of parentheses, e.g., to continue the list of fields in a record
across a line boundary.
14. No use of comments.
15. No blank lines.
16. The SOA record should be present at the top and (duplicated at) the end
of the zone file.
17. With the exception of the SOA record, all the records in a file must be
in alphabetical order.
18. One zone per file. If a TLD divides its DNS data into multiple zones,
each goes into a separate
file named as above, with all the files combined using tar into a file
called <tld>.zone.tar.
2.1.5. Use of Data by User. Registry Operator will permit user to use the
zone file for
lawful purposes; provided that, (a) user takes all reasonable steps to
protect against unauthorized access to
and use and disclosure of the data, and (b) under no circumstances will
Registry Operator be required or
permitted to allow user to use the data to, (i) allow, enable, or otherwise
support the transmission by email,
telephone, or facsimile of mass unsolicited, commercial advertising or
solicitations to entities other
than user’s own existing customers, or (ii) enable high volume, automated,
electronic processes that send
queries or data to the systems of Registry Operator or any ICANN-accredited
registrar.
2.1.6. Term of Use. Registry Operator, through CZDA Provider, will provide
each user
with access to the zone file for a period of not less than three (3) months.
Registry Operator will allow
users to renew their Grant of Access.
2.1.7. No Fee for Access. Registry Operator will provide, and CZDA Provider
will
facilitate, access to the zone file to user at no cost.

>> So if a third party get an unsigned zone, the unsigned zone's serial 
>> is higher than the current signed zone(can be dug from the internet), 
>> this may be a problem.

>I don't think is a real problem, but I do agree it might look strange. I
also believe the signed zone serial should always be equal or higher than
the unsigned version.

>> So as this, I think it's better to ensure the signed zone's serial 
>>higher than the unsigned zone.

>I agree.


>	jakob