> I finished a draft to propose an automated synchronization mechanism for > configuration data of DNS name servers. My apologies for cross-posting, coz > I'm not sure which WG is more suitable for this draft.
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. 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. 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. 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. 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. Jay -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
