Referring to http://ietf.org/internet-drafts/draft-ietf-dnsop-respsize-07.txt:
1) I don't get this point.
2.2.4. The best case is no truncation at all. This is because many
requesters will retry using TCP immediately, or will automatically re-
query for RRsets that are possibly truncated, without considering
whether the omitted data was actually necessary.
Do you mean that situations requiring large answers ought to use
EDNS0 (as ENUM does/is considering) or recommend avoiding UDP
altogether?
2) This confused me a bit, perhaps though I figured it out.
4.4. Multi-homing of name servers within a protocol family is
inadvisable since the necessary glue RRsets (A or AAAA) are atomically
indivisible, and will be larger than a single resource record. Larger
RRsets are more likely to lead to or encounter truncation.
Is the point that you want to limit the number of address records for
a name server name per address family to 1? When I see multi-homing
I think of routing architecture (with some claiming that anycast is
a special case of multi-homing) and not DNS.
If I've interpreted this right, I'd suggest substituting something
else for "multi-homing". Like "Minimizing the number of address
records per name per address family is advisable since the necessary
glue..." perhaps?
3) Ever since RFC 1876[0] I've made a habit of trying any source code
in a draft. The section 5 stuff passed my cursory check.
[0] The code in the RFC had a buffer overflow problem. I forget the
exact error but still have a deep enough emotional scare to recall it
was RFC 1876.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Think glocally. Act confused.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
