On 10/28/09 4:41 PM, Mark Andrews wrote:
In message<4AE8A694.5010801@gmail.com>, Doug Otis writes:Imposing _any_ TCP mandate represents an expedient that takes DNS in the wrong direction. As such, this draft should also include a strong warning that resources needed to sustain TCP services might be provisioned for other transports during aberrant demand, and that it is not recommended to be dependent upon TCP availability.TCP has always been expected to be implemented unless you had GOOD reasons to not implement it and had REALLY thought about the consequences. Read RFC 1034 and 1123. TCP was not MAY. It was SHOULD.
The concern is about establishing a dependence upon TCP. While TCP has often been a fall-back for truncated DNS answers, it has never been mandated. A SHOULD is not a MUST. TCP being functional for DNS was never assured. Even ensuring that TCP is enable does not ensure availability of a lower priority service. In addition, TCP is not enabled by one the roots, and most CPE equipment. While people can configure their CPE equipment to bypass DNS proxy services lacking proper TCP support, most do not.
Does anyone here really think that any proxy vendor, that doesn't support TCP, could successfully argue that they did that analysis and have the result pass a laugh test?
What analysis? Vendors likely considered the resources needed to support the features they offered, and decided against expenditures related to TCP for DNS. The CPE market decided TCP was not an overriding requirement for DNS, in favor of cost. This same cost issue with TCP killed RDMA. Mandating that DNS servers MUST provide TCP when the service can be carried over UDP extended to conservative MTUs of 1280, or IMHO 1476, makes no sense. This strategy should also help curtail growth of DNS TCP traffic. After all, TCP is not well suited to efficiently handle DNS, and should be avoided where possible.
-Doug