I read Brad's comments on this draft with interest. I've had some
concerns about the mechanism recommended by this draft for some time,
and would urge a bit of expansion in one area. I would like to see at
least an optional, but standardized way to include an identifier in
all response packets sent by the server, provided there's room in the
packets. This could be accomplished by placing the information in the
additionals section after ensuring the addition would not cause an overflow.
The thinking is simple: if the DNS server is able to tag all outbound
packets with some uniqueness information, then there is no ambiguity
concerning tracking down which server responded. Any mechanism that
relies on a subsequent query will provide a less than perfect
indication of the server involved, as load balancing or similar could
in fact shift focus to a new server. When I've raised this issue
previously, the response has been that the result of the subsequent
query will be "good enough."
The introduction section of the document indicates folks are already
using the mechanism offered by BIND (which requires an additional
query) and that a rationale for this document is to codify practice.
The introduction also goes on to talk about there being shortcomings.
A requirements document must look forward and lay out the goals for a
sufficient solution. It is understood that the existing practice has
drawbacks, and so at this time I can't support having a requirements
document that settles for solutions that are not sufficient to solve
the problem. That this document does not explore more possible
solutions says to me this is NOT a requirements document as written.
If this document is reworked, it could indeed be a useful document. A
separate document could and should explore the present practice as
one possible solution to a set of requirements, just as other
possible solutions could and should be documented. The merits of the
approaches could then be compared to the requirements, and weighed.
It may well be that more than one mechanism could or should be
considered together to provide the best possible solution given
constraints that exist.
Dan
--
-----------------------------------------------------------------
Daniel Senie [EMAIL PROTECTED]
Amaranth Networks Inc. http://www.amaranth.com
"George Orwell was only off by 20 years. Had he titled his book
2004 instead of 1984, he'd have been hailed as prescient.
War is Peace. Freedom is Slavery. Ignorance is Strength." -dts
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
