Dan,
it seems to me that you're advocating splitting the document into two:
- Section 1-2, discussing the present mechanism
- Section 3, discussing requirements for a "permanent solution"
In the "section 3" document, you would also like to discuss the option of
tagging all outgoing DNS responses with the server ID.
Is that what you are proposing?
(BTW, I don't, off the bat, support such a split. It's "just too many
documents" - I'd prefer to get this one out the door.)
Harald
--On torsdag, desember 15, 2005 19:47:12 -0500 Daniel Senie <[EMAIL PROTECTED]>
wrote:
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
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
