[DNSOP] 答复: An Automated Synchronization Mechanism forConfiguration Data of DNS (Domain Name System) Name Serve

["Ning Kong" <[e-mail]>]

Hi Jay,

Apologies for the late response. Thanks for your attention and feedback.

> I've read this draft now and my feedback is:
> 
> 1. the linkage to domain names is defined by the briefest of paragraphs,
to
> quote:
> 
> >    For example, there is a clause used to specify the "example.com" zone
> >    that the name server needs to support, and the mechanism of zone
> >    transfer for this zone is AXFR.  Then the NAME of a CZ for this
> >    clause is "example.com", the CLASS of this kind of CZs can be defined
> >    as "Zone", the type of a CR for the mechanism of zone transfer can be
> >    defined as "zone_transfer", and the RDATA will contain the following
> >    characters "AXFR"."
> 
> This needs a clear and unambiguous definition.
> 
> it also needs a definition of a) how the name matching is meant to work
and b)
> how the service is to be located.

The 01 version of this draft definitely needs a further improvement. I'm
planning to update this draft before IETF 80, and I'm sure to make these
paragraphs more clear.

> 2.  the use of DNS as a transport is not thought through and does not work
as
> specified.  DNS is a binary format and yet some key fields of this
proposal are
> text based and no transformation to the binary format is given.  For
example,
> the doc says:
> 
> >  TYPE: A type of the requested CR.  This fields are represented as
> >       a sequence of labels, where each label consists of a length octet
> >       followed by that number of octets.
> 
> but in DNS this is a two octet field.

A new OpCode is required by this draft to identify a queries or responses
message of the automated synchronization mechanism for the configuration
data of multiple DNS name servers. The format of Configuration Record is
based on the section 3.2.1 of [RFC1035], with some fields (such as TYPE
field) redefined by this draft.

> 3.  If a two octet type code was defined for TYPE, then either this is
chosen
> without regard to DNS RRtypes, and so the same set of data sent over the
wire
> (i.e. a DNS packet using a particular RR and a packet in this protocol
using the
> same two octet identifier as that RR) can only be understood when the
context
> of where that data was used in known.  Or if the two octet code is defined
> with regard to DNS RRtypes to avoid conflict, then this is creating RRs by
a
> backdoor.

A new OpCode is used, so I think there won't be any confusion you mentioned.

> 4.  I don't agree with the principle implicit in this draft that DNS can
be used
> to hold configuration data for nameservers that is not related to DNS.
For
> example this could theoretically include telling the nameserver to restart
or
> turn on logging, which is a fundamental change of use of DNS and one to
> which it is unsuited.

This draft only focuses on providing an automated synchronization mechanism
for configuration data of DNS name servers. What kinds of configuration data
needed to be synchronized should be decided by others (such as DNS
administrators or DNS experts of DNSOP WG). 
Actually, the principle implicit in this draft is that DNS can be used to
hold configuration data for nameservers that is related to DNS name servers
(not related to DNS). IMO, turning on logging within your example is one
configuration item for DNS name servers, so it might be supported by this
automated synchronization mechanism. But I think restarting of DNS name
servers within your example belongs to Control not to Configuration. As you
know, management operations are divided into four categories by the
requirement draft [draft-ietf-dnsop-name-server-management-reqs-05]. These
are control, configuration, monitoring and alarms. So far, this draft only
focuses on solving the problems belong to the second category (Configuration
category).


> 5.  The approach of leaving others to define the CRs renders this
unusable.
> The feature set of nameservers is well known and any protocol must attempt
> to enumerate those and provide a well thought out framework for
> representing them to provide minimum usable functionality and to prevent
> inconsistencies appearing later.

+1. I definitely agree with you at this point. I think the 01 version of
this draft is still in a very early stage. A lot of further work needs to be
done in future.


Cheers,
Ning