Peter and Matt, hello again!
Thanks for reviving the Resolver Priming draft, and amending and
restructuring some of the text to enhance the readability and
completenes of the reasoning, in
draft-ietf-dnsop-resolver-priming-02.
(You politely have chosen to not mention these improvements in the
document history. :-) )
However, it looks like my previous comments on the -02 version
(once ack'ed) have been missed in the recent edits.
Below are (A) a few more general comments, followed by (B) notes
on the editorial nits (still) present in the memo.
(A) General comments
(A.1) DISCUSS item in 2.3
| [[Is it OK to send multiple priming queries to multiple targets in
| parallel?]]
The more conservative, yet perhaps less user friendly approach
would be to not allow multiple parallel queries.
However, I am not aware of similar restrictions in any DNS related
RFCs for any kind of queries. Since we apparently do not have
such rules for other queries to root servers, there would need to
be strong reasons for interdicting multiple parallel queries.
Priming queries can reasonably be expected to be much less frequent
than other queries that make it to the root servers, so this in fact
might not be an issue at all.
(A.2) Section 4, 3rd para -- OBE !
vvvvvvvvvvv
| [[At the time of writing, all but one root name server were
authoritative for ROOT-SERVERS.NET., even though only a subset
received an official delegation.]]
At IETF 72, the root server operators had promised to rectify this
irregularity; as can be seen now, the first inconsistency indeed
has been done in the meantime. So please change the 1st line:
vvv
| [[At the time of writing, all root name server were authoritative for
ROOT-SERVERS.NET., even though only a subset received an official
delegation.]]
Note: The subset mentioned is {A,F,J,K}.ROOT-SERVERS.NET.
Since the whole para is under the premise "At the time of writing",
I suggest to give this information as well, as a service to readers
of the memo.
(A.3) Section 3.1 -- additional discussion
To mitigate the effects of SBELT information becoming outdated
over time, as described in Section 4, it might be contemplated
to 'update' the SBELT information with information obtained in
authoritative responses. It remains unclear from Section 3.1
whether such use of priming (or other) responses should be admitted
and under which conditions. The strongmost condition would be to
require having received and validated signed data -- as soon as
DNSSEC signatures for the root zone are available --, but one could
consider declaring receipt of the same information from multiple
(<n> ... tbd!) root servers as sufficient to allow an auto-update
of the SBELT.
(B) Editorials
(B.1) Section 1, below the quotes fron RFC 1034
Typo: s/seperates/separates/
^ ^
(B.2) Section 2.3, 1st para -- punctuation
For enhanced readability, I suggest inserting a comma as follows:
[...]. For resending the priming query to a
| different server the random selection SHOULD also be used.
---
[...]. For resending the priming query to a
| different server, the random selection SHOULD also be used.
^
(B.3) Sections 3.1, 3.3, 4
I suggest to use titlecase fo the special terms related to DNS packets,
as these consist of plain english words, and thus titlecase should
serve to help avoid possible ambiguities:
answer section --> Answer Section (2x)
authority section --> Authority Section
additional section --> Additional Section (6x)
(B.4) Section 3.3, 1st para -- punctuation
As above:
[...]. To ensure equal
| availability the A and AAAA RRSets should have identical TTL values
at the authoritative source. [...]
--- v
[...]. To ensure equal
| availability, the A and AAAA RRSets should have identical TTL values
at the authoritative source. [...]
(B.5) Section 4, 2nd para -- missing verb
All DNS root name servers need to be able to provide for all
| addresses of all root name servers. This can easily achieved by
making all root name servers authoritative for the zone containing
the servers' names.
---
All DNS root name servers need to be able to provide for all
| addresses of all root name servers. This can easily be achieved by
^^^^
making all root name servers authoritative for the zone containing
the servers' names.
MfG/Kind 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: a...@tr-sys.de |
+------------------------+--------------------------------------------+
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
