Hello Peter and Matt,
eventually, I found the time to take a closer look at the
latest version of your Resolver Priming I-D,
draft-ietf-dnsop-resolver-priming-01,
and again would like to submit a few comments, most of which
are editorial in nature.
Items (4) and (7) ff. should be of interest for the WG discussion.
(The message is copied to the list therefore.)
(1) Section 1, 2nd text paragraph -- typo
| Today's practice generally seperates serving and resolving ...
--- ^
| Today's practice generally separates serving and resolving ...
^
(2) Section 2.1 -- nit
For clarity, I suggest to add a comma in the last sentence:
v
| [...] For resending the priming query to a different server, the
random selection SHOULD also be used.
(3) General (in particular Sections 3, 3.2, and 4) -- terminology/case
I suggest to spell the established terms for the parts of DNS
messages in headline case:
Answer Section / Authority Section / Additional Section
^ ^ ^ ^ ^ ^
(4) Section 3.1 "Use of the Priming Response"
The draft simply says:
A resolver MAY use the priming response as it would use any other
data fed to its cache. However, it SHOULD NOT use the SBELT
information directly in any responses it hands out.
After some consideration, this perhaps also means that the priming
response SHOULD NOT be fed back into the SBELT -- which otherwise
would be a possible option for use of the priming response.
For clarity, I suggest to make that explicit in the text.
Further, it might be useful to recommend [rate limited] logging of
(or sending notifications to the resolver operator) the occurrence
of changes in the priming response vs. the SBELT information, to give
the resolver operator a trigger/opportunity to verify the changes
and, if approved, update the SBELT configuration information (or the
code of the resolver if it is compiled in) accordingly, for improved
resilience in the future.
(5) Section 3.2, 1st paragraph -- nit
Again, for clarity, I suggest to add a comma in the 3rd sentence:
[...]. To ensure equal
| availability, the A and AAAA RRSets should have identical TTL values
^
at the authoritative source. [...]
(6) Section 4, 2nd paragraph -- nit
I recommend to insert "be" in the second sentence:
vvvv
| [...]. This can easily be achieved by
making all root name servers authoritative for the zone containing
the servers' names.
(7) Section 4, 3rd paragraph -- ATTENTION to ROOT SERVER OPERATORS !
The draft says:
[[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.]]
For clarity:
a) L.ROOT-SERVERS.NET is the single "one" root server not pretending
to be authoritative for ROOT-SERVERS.NET.
b) The subset that has received an official delegation consists of
{A,F.J.K}.ROOT-SERVERS.NET.
At the DNSOP session in Dublin (IETF 72), root server operators have
indicated that in fact *all* root servers should be authoritative,
via official delegation, for ROOT-SERVERS.NET., and they have
indicated their intend to perform the necessary updates as soon
as feasible; but these changes have not happened yet.
I suggest to update the draft text accordingly and keep track of the
changes to happen.
(8) Section 4, 5th paragraph
The draft says:
[[Do the TTLs for the root NS RRSet and address RRSets in the root
and the ROOT-SERVERS.NET. zones need to be aligned? In real life
responses, the address RRSet's TTL values vary by implementation.]]
Again, at IETF72 root server operators have indicated that indeed
these TTL values SHOULD be aligned, and promised to take the necessary
operational measures to ensure that in the future.
I suggest to update the draft text accordingly.
(9) Section 6
I recommend that the consensus of the root server operators indicated
at IETF72 on the discussion items (7) and (8) above be submitted to
the IANA for incorporation in their root server policy and guidelines.
Kind regards,
Alfred.
--
+------------------------+--------------------------------------------+
| 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: [EMAIL PROTECTED] |
+------------------------+--------------------------------------------+
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
