[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-dnsext-axfr-clarify-06
[ Moderators note: Post was moderated, either because it was posted by
a non-subscriber, or because it was over 20K.
With the massive amount of spam, it is easy to miss and therefore
delete relevant posts by non-subscribers.
Please fix your subscription addresses. ]
Hello,
I'd like to submit a few comments on the Internet-Draft
authored/edited by you, draft-ietf-dnsext-axfr-clarify-06,
addressing textual flaws I found in that memo, and pointing
out other areas of concern.
The items below are presented in textual order.
To give more context, sometimes I quote larger blocks of text
literally and show the replacement proposed using the shorthand
notation:
<original draft text>
---
<modified text>
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Quoted original (still un-indented text) will be indented by one
character position to distinguish it from my comments.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate. I also try to accomodate published
RFC-Ed policy on style and punctuation etc. in my proposals.
(0) General comment
I really appreciate resuming this effort. That was overly due now!
(1) Section 1.2 -- textual improvements
I suggest to apply the following changes to correct and improve
the language of the 4th paragraph of Section 1.2 :
"Turnkey" DNS implementation refers to custom made, single use
implementations of DNS. Such implementations consist of software the
use the DNS protocol message format but does not conform to entire range
of DNS functionality.
---
"Turnkey" DNS implementation refers to custom made, single use
implementations of DNS. Such implementations consist of software
| that uses the DNS protocol message format but does not conform to the
^^ ^ ^^^^
entire range of DNS functionality.
(2) Section 1.4 -- textual improvement
I suggest to apply the following change to improve the language
of Section 1.4 :
[...]. This document will update those sections,
invalidate at least one part of that definition. The goal of this
document is define AXFR as it exists, or should exist, currently.
--- vvvv
| [...]. This document will update those sections, and
invalidate at least one part of that definition. The goal of this
document is to define AXFR as it exists, or should exist, currently.
^^^
(3) Section 2
(3a) 3rd paragraph
I suggest to make the style of quotations to other RFCs consistent
within the document and with common use:
- no embedded spaces in ref. tags,
- one space between "RFC" and the number in prose.
I.e.: s/[RFC 1996]/[RFC1996]/
^
s/ RFC1996/ RFC 1996/ etc. ...
Furthermore, although linguistically considered as poor style,
refering to RFCs by only giving the ref. tags might in fact
enhance the readability of the text.
Additionally, I suggest to not forget the DNS IANA Considerations
document, BCP 42, RFC 2929, as the source of reserving OPCODE=3 ;
perhaps this detail is not even worth being mentioned, just listing
[RFC2929] might suffice -- an entry for RFC 2929 needs to be added
to section 12.1 anyway.
Therefore, I suggest to change the current text,
The basic format of an AXFR message is the DNS message as defined in RFC
1035, Section 4 ("MESSAGES") [RFC 1035], updated by the following
documents: RFC3425 [RFC3425], RFC1996 [RFC 1996], RFC2136 [RFC2136],
RFC2671 [RFC2671], RFC2845 [RFC2845], RFC2930 [RFC2930], RFC4035
[RFC4035], RFC4635 [RFC4635]. In addition, one change is credited to
IANA, the reserving of OPCODE = 3.
to either:
The basic format of an AXFR message is the DNS message as defined in
RFC 1035 [RFC1035], Section 4 ("MESSAGES"), updated by the following
documents: RFC 3425 [RFC3425], RFC 1996 [RFC1996], RFC 2136
[RFC2136], RFC 2671 [RFC2671], RFC 2845 [RFC2845], RFC 2930
[RFC2930], RFC 4035 [RFC4035], RFC 4635 [RFC4635], and the related
IANA considerations in BCP 42 [RFC2929].
or:
The basic format of an AXFR message is the DNS message as defined in
[RFC1035], Section 4 ("MESSAGES"), updated by the following
documents: [RFC3425], [RFC1996], [RFC2136], [RFC2671], [RFC2845],
[RFC2930], [RFC4035], [RFC4635], and the related IANA considerations
in BCP 42 [RFC2929].
Similar changes should be applied to other parts of the text in a
self-consistent manner.
Finally, I suggest moving the second pararaph (with message length
considerations) behind this paragraph or to the end of the section,
because it contains more specific information.
(3b) final paragraph -- typo
Please correct the typo in the last paragraph of Section 2:
Field names used in this document will correspond to the names as the
appear in the IANA registry for DNS Header Flags [DNS-FLAGS].
---
Field names used in this document will correspond to the names as
| they appear in the IANA registry for DNS Header Flags [DNS-FLAGS].
^
(4) Section 2.1.1
(4a)
I generally suggest to avoid too much terse, telegram like style,
and to use more expressive language instead.
For instance, update Note 2.1.1.b as follows:
Current text:
Note 2.1.1.b The value in this field has no meaning in the
context of AXFR. For the client, RECOMMENDED that the value be zero.
For the server, RECOMMENDED ignoring this value.
New text:
Note 2.1.1.b. The value in this field has no meaning in the context
| of AXFR. For the client, it is RECOMMENDED that the value be
| zero. For the server, it is RECOMMENDED ignoring this value.
or even shorter:
Note 2.1.1.b. The value in this field has no meaning in the context
| of AXFR. The client SHOULD set that field to zero, and the server
| SHOULD ignore its value.
(I will not mention/correct similar occurences below unless the
affected text needs to be quoted for other reasons as well.)
(4b)
IMHO, the text regarding the 'Z' bit is inappropriate.
In the early days of "The Net", unused fields customarily
have been labelled 'Z', as a mnemonic for "SHOULD be set to
Zero and ignored on receipt"; this was not meant as a name
or identifier for a field.
The terminology used in the IETF generally has evolved since
the publication of RFCs 1034/1035 to use the term 'reserved'
for such fields with (still) unassigned semantics dedicated to
possible future use by protocol extensions. Hence, in current
parlance, this field is not perceived as being 'assigned', and
assigning a name and semantics to it should be left to future
standardization -- cf. BCP 42, RFC 2929, Section 2.1 (p.3).
The IANA entry listing this field as 'reserved' IHMO therefore
perfectly reflects the status of this field, and the draft should
not complain about it.
I therefore suggest to change the draft text,
Note 2.1.1.c The Z bit is no longer registered with IANA (no document
cited for change). RECOMMENDED client set to 0, server MUST ignore.
to say:
| Note 2.1.1.c. The bit labelled 'Z' in legacy DNS RFCs is currently
| unassigned and reserved. Clients SHOULD set it to 0, servers MUST
| ignore it.
(5) Section 2.1.2 -- textual improvement
I suggest changing:
The Query section of the AXFR query MUST conform to section 4.1.2 of RFC
1035 contain the following values:
---
The Query section of the AXFR query MUST conform to section 4.1.2 of
| RFC 1035, and contain the following values:
^^^^^
(6) Section 2.2.1
(6a)
Regarding the 'Z' bit, I suggest to apply (4b) above to Note 2.2.1.d.
(6b)
I suggest the following textual enhancements, including the
application of "rational quoting".
Note 2.2.1.e If the implementation is implementing DNSSEC [RFC4033-5],
this value MUST be set according to the rules in RFC 4035 [RFC4035],
section 3.1.6, "The AD and CD Bits in an Authoritative Response." If
the implementation is not implementing DNSSEC, then this value MUST be
set to 0 an MUST be ignored.
---
Note 2.2.1.e.
| If the implementation supports DNSSEC [RFC4033] [RFC4034]
^^^^^^^^ ^^^^^^^^^^^
| [RFC4035], this value MUST be set according to the rules in RFC
^^^^^^^
| 4035, section 3.1.6, "The AD and CD Bits in an Authoritative
^
Response". If the implementation does not support DNSSEC, then
^^^^^^^
| this value MUST be set to 0 and MUST be ignored on receipt.
^ ^^^^^^^^^^^
NOTE: I have expanded 'RFC4033-5' above; please see the final
item (17) below for an alternative proposal.
(7) Section 2.2.5
I suggest adding a comma for clarity:
If the query included an EDNS0 OPT RR this section MAY include an OPT RR
in reply. If the query had an empty Additional Section, this MUST be
empty. A client MAY ignore the contents of this section.
---
If the query included an EDNS0 OPT RR, this section MAY include an
OPT RR in reply. If the query had an empty Additional Section, this
MUST be empty. A client MAY ignore the contents of this section.
(8) Section 3.1
(8a) 1st paragraph
Please consistently use "rational quotation", and either always add
the trailing period to section numbers quoted, or always omit it
(preferred):
In the answer section of AXFR response messages the resource records
within a zone for the given serial number MUST appear. The definition
of what belongs in a zone is described in RFC 1034, Section 4.2, "How
the database is divided into zones", and in particular, section 4.2.1.,
"Technical considerations."
---
| In the answer section of AXFR response messages, the resource records
within a zone for the given serial number MUST appear. The
definition of what belongs in a zone is described in RFC 1034,
Section 4.2, "How the database is divided into zones", and in
| particular, section 4.2.1, "Technical considerations".
^ ^^
(8b) 2nd paragraph
Please correct the word omission:
The first resource record of the first AXFR response message sent by the
AXFR server MUST be the zone's SOA resource record. The last resource
record of the final AXFR response message sent by the AXFR server MUST
be the zone's SOA resource record. The order and grouping of all other
records in the AXFR is arbitrary, but the AXFR server SHOULD group
resource record sets together and transmit in the same AXFR message.
---
The first resource record of the first AXFR response message sent by
the AXFR server MUST be the zone's SOA resource record. The last
resource record of the final AXFR response message sent by the AXFR
server MUST be the zone's SOA resource record. The order and
grouping of all other records in the AXFR is arbitrary, but the AXFR
| server SHOULD group resource record sets together and transmit them
in the same AXFR message.
^^^^^
Nevertheless, it should be noted that the final rule in the last
sentence is incompatible with the subsequent paragraph:
Unless the AXFR server knows that the AXFR client expects just one
| resource record per AXFR response message, an AXFR server SHOULD
| populate an AXFR response message with as many complete resource
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| records as will fit within the limited permissible message size.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^
This seems to be the better choice, for the sake of efficiency.
Therfore, it might be better to simply shorten the 2nd paragraph
to say:
The first resource record of the first AXFR response message sent by
the AXFR server MUST be the zone's SOA resource record. The last
resource record of the final AXFR response message sent by the AXFR
server MUST be the zone's SOA resource record. The order and
grouping of all other records in the AXFR is arbitrary, but the AXFR
| server SHOULD group resource record sets together.
(9) Section 3.2
(9a) 1st paragraph
The draft says:
In RFC 1034, section 4.2.1, this text appears (keep in mind that the use
of the word "should" in the quotation is exempt from the interpretation
in section 1.1) "The RRs that describe cuts ... should be exactly the
same as the corresponding RRs in the top node of the subzone." There has
been some controversy over this statement and the impact on which NS
resource records are included in a zone transfer.
As far as I can recall, DNSSEC makes explicit provisions for deviations
from this rule if either the parent zone or the delegated zone or both
are secured by DNSSEC. This should at least be noted.
I suggest to amend this paragraph to say:
In RFC 1034, section 4.2.1, this text appears (keep in mind that the
use of the word "should" in the quotation is exempt from the
interpretation in section 1.1): "The RRs that describe cuts ...
should be exactly the same as the corresponding RRs in the top node
of the subzone." There has been some controversy over this statement
and the impact on which NS resource records are included in a zone
| transfer. Also, DNSSEC [RFC4033] [RFC4034] [RFC4035] specifies
| particular Resource Records to be inserted at delegation points in
| secure zones, and at the apex of secure zones, respectively, which
| makes the above statement inappropriate.
Furthermore, the note (in parentheses) on "should" is inappropriate
because Section 1.1 only talks about uppercase "SHOULD", and might
therefore better either be changed or omitted entirely:
In RFC 1034, section 4.2.1, this text appears:
"The RRs that describe cuts ... should be exactly the same as the
corresponding RRs in the top node of the subzone."
There has been some controversy over this statement and the impact on
which NS resource records are included in a zone transfer. Also,
DNSSEC [RFC4033] [RFC4034] [RFC4035] specifies particular Resource
Records to be inserted at delegation points in secure zones, and at
the apex of secure zones, respectively, which makes the above
statement inappropriate.
or:
In RFC 1034, section 4.2.1, this text appears (keep in mind that the
word "should" in the quotation is now deemed to be a "SHOULD" subject
to the interpretation in section 1.1):
"The RRs that describe cuts ... should be exactly the same as the
corresponding RRs in the top node of the subzone."
There has been some controversy over this statement and the impact on
which NS resource records are included in a zone transfer. Also,
DNSSEC [RFC4033] [RFC4034] [RFC4035] specifies particular Resource
Records to be inserted at delegation points in secure zones, and at
the apex of secure zones, respectively, which makes the above
statement inappropriate.
(9b) 2nd paragraph -- typo
s/fueld/fuelled/
(9c) 5th paragraph -- word omisison
The AXFR response MUST contain the cut point NS resource record set
registered with the zone whether it agrees with the authoritative set or
not. "Registered with" can interpreted as residing in the zone file of
the zone for the particular serial number (in zone file environments) or
as any data configured to be in the zone, statically or dynamically.
---
The AXFR response MUST contain the cut point NS resource record set
registered with the zone whether it agrees with the authoritative set
| or not. "Registered with" can be interpreted as residing in the zone
^^^
file of the zone for the particular serial number (in zone file
environments) or as any data configured to be in the zone, statically
or dynamically.
(10) Section 3.3 -- enhancement
I suggest inserting the word "quoted" :
As in the previous section, RFC 1034, section 4.2.1, provides guidance
and rationale for the inclusion of glue records as part of an AXFR
transfer. [...]
---
As quoted in the previous section, RFC 1034, section 4.2.1, provides
guidance and rationale for the inclusion of glue records as part of
an AXFR transfer. [...]
(11) Section 4
The draft says:
AXFR sessions are restricted by RFC 1034, section 4.3.5's "because
accuracy is essential, TCP or some other reliable protocol must be used
for AXFR requests." With the addition of EDNS0 and applications which
|require many small zones such in web hosting and some ENUM scenarios,
^
|AXFR sessions on UDP are now possible and desirable. In addition, it is
|conceivable to interleave requests for other data or AXFRs of other
|zones during one session in TCP if the ID values are consistently
|maintained.
(11a)
Firstly "such in web hosting" should be "such as in web hosting".
(11b)
More importantly, I am in serious doubt whether the capability added
by the final sentence is worth the protocol complications it requires.
To my knowledge (admittedly a bit aged), typical AXFR client
implementations anyway perform the AXFR and local database update
in a dedicated process or thread that does not also perform other
DNS queries. Therefore, a dedicated TCP connection will be used
for one or more AXFRs.
Serial reuse of a TCP connection for multiple AXFRs (AXFR chaining
on a connection) or even using a (semi-)persistent TCP connection
for other queries/responses in a serialized manner therefore might
be a reasonable feature that can be supported without protocol
complications and/or serious backwards compatibility issues.
On the other hand, interleaving multi-message AXFR responses with
other DNS query/response traffic seems to be unnecessary and
unnecessarily complicated. Keep in mind that query/response
traffic over UDP can be sustained in parallel without a need
for this extension. Also, paragraph 2 of Section 5 indicates
that regularly, the set of AXFR clients allowed will be restricted
very much, and other queries between sibling authoritative servers
needing TCP are considered less likely.
That said, my subsequent change proposals nevertheless will carry
on support for this protocol extension.
(12) Section 4.1
The last paragraph of Section 4.1 says:
An AXFR server MAY opt to respond to other queries while responding the
|original AXFR query that opened the connection. An AXFR server MAY
^^^^^^^^^^^
ignore or even close the connection if there are two outstanding AXFR
queries for the same zone on a connection, as this could be evidence of
an abusive AXFR client.
AFAICS, there's no requirement at all that the particular AXFR query
opens the connection. As indicated above, the serialized exchange of
various transactions on a more-or-less persistent TCP connection can
be easily supported (and it reduces connection management overhaed).
Therefore, if additionally and even more supporting interleaved
responses, this cannot be a requirement, and hence the text should
be changed to say, e.g.:
An AXFR server MAY opt to respond to other queries while responding
to an AXFR query on the same TCP connection. An AXFR server MAY
ignore or even close the connection if there are two outstanding AXFR
queries for the same zone on a connection, as this could be evidence
of an abusive AXFR client.
(13) Section 4.2
(14a) 1st paragraph
s/in to one DNS message/into one DNS message/
(14b) 2nd paragraph -- textual improvements
I suggest to make the text more precise and use more suggestive
punctuation.
Also, datagram reordering might negatively affect (and counter)
the method of "SOA bracketing" of AXFR responses to ensure zone
date completeness. This should be mentioned as well.
Hence, I suggest to change:
Reasons not to do AXFR over UDP include cases where multiple AXFR
messages are needed for a zone, there is no way to guarantee all AXFR
messages will arrive at the AXFR client and no way to detect a dropped
AXFR message.
---
Reasons not to do AXFR over UDP include cases where multiple AXFR
messages are needed for a zone: There is no way to guarantee all
AXFR response messages will arrive at the AXFR client, and in the
original transmission order (particularly affecting the delineation
of the start/end of an AXFR response by the transmission of the SOA
record), and no way to detect a dropped AXFR response message.
(14c) 3rd paragraph
The draft says:
If an AXFR server cannot place the entire contents of the requested zone
in one AXFR response message, the AXFR server MAY silently drop the
request or MAY send a response with an return code of SERVFAIL.
If an AXFR client does not receive a reply to an AXFR query over UDP or
receives a SERVFAIL response code, the client SHOULD retry the request
via TCP.
Wouldn't it be reasonable and in line with the general DNS protocol to
admit setting the TC bit (and at best leaving the answer section empty)
as a natural means to indicate exceeding of the response message size
limits?
The code to take this as a trigger to immediately retry the request
via TCP will already be implemented in any DNS client code,
and this trigger avoids the performance penalty of having to wait for
a timeout when the request over TCP will most probably succeed.
Also, other parts of the draft seem to indicate that non-response
might be used to indicate lack of authorixation.
This ambiguity in observable DNS server behavior should better
be avoided. Always responding with a precise error code or another
defined trigger should help to avoid unreasonable/unexpected
request retransmissions, and thereby will help offload servers
from useless traffic.
I therefore strongly recommend to not sanction the server behavior
to silently drop a request as a means to signal a specific error
condition.
(15) Section 5
(15a) 1st paragraph
Please do not omit the most stringent and important restriction
to be observed today: LAW !
A zone administrator has the option to restrict AXFR access to a zone.
This was not envisioned in the original design of the DNS but has
emerged as a requirement as the DNS has evolved. Restrictions on AXFR
could be for various reasons including a desire to keep the bulk version
of the zone concealed or to prevent the servers from handling the load
incurred in serving AXFR. All reasons are arguable, but the fact
remains that there is a requirement to provide mechanisms to restrict
AXFR.
---
A zone administrator has the option to restrict AXFR access to a
zone. This was not envisioned in the original design of the DNS but
has emerged as a requirement as the DNS has evolved. Restrictions on
| AXFR could be for various reasons including a desire (or even legal
| requirements) to keep the bulk version of the zone concealed or to
prevent the servers from handling the load incurred in serving AXFR.
All reasons are arguable, but the fact remains that there is a
requirement to provide mechanisms to restrict AXFR.
(15b) last paragraph
I simply do not understand the sense and purpose of the last sentence:
An implementation SHOULD allow access to be open to all requests.
Please supply more specific text, or drop this sentence.
(16) Section 7.1 -- improved wording
(16a) 1st paragraph
An AXFR server has the luxury of being able to react to an AXFR client's
abilities with the exception of knowing if the client can accept
multiple resource records per AXFR response message. The knowledge that
a client is so restricted apparently cannot be discovered, hence it has
|to set by configuration.
^
---
An AXFR server has the luxury of being able to react to an AXFR
client's abilities with the exception of knowing if the client can
accept multiple resource records per AXFR response message. The
knowledge that a client is so restricted apparently cannot be
| discovered, hence it has to be set by configuration.
^^^^
(16b) 2nd paragraph
An implementation of an AXFR server SHOULD permit configuring on a per
AXFR client basis a need to revert to single resource record per
message. The default SHOULD be to use multiple records per message.
---
| An implementation of an AXFR server SHOULD permit configuring, on a
vvvvv ^
| per AXFR client basis, the need to revert to single resource record
per message. The default SHOULD be to use multiple records per
message.
(17) Section 12
- Changes suggested above require adding an entry for RFC 2929.
- IESG and RFC-Ed policy require promoting RFC 2119 to Normative Ref.
- If you like a combined ref. tag for RFCs 4033..4035, I suggest
making use of "[RFC403x]".
- Please use <ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt>
(or any mirrored or derived file) as the base for content, style,
and punctuation in entries of the References section.
Best regards,
Alfred Hönes.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: ah@TR-Sys.de |
+------------------------+--------------------------------------------+
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>