Eric A. Hall wrote:
> | Consider the case where the query is so long or the number of the
> | additional ("glue") records is so high that the response must either
there's a difference between "glue" and "additional data". "glue" ist where the
data originates from and "additional data" is where it's carried in.
> | be truncated (leading to a retry with TCP) or some of the additional
> | data removed from the reply. Further, resource record sets are never
Section 9 of RFC 2181 stronly recommends against setting the TC bit just if
the response couldn't be optimally populated. If there's legitimate glue, than
it's needed in the response. Everything else is just courtesy information.
> The "best" scenario is for additional-data associated with DNS-specific
> RRs (such as NS RRs) to give preference to the current network type, and
> for additional-data associated with application RRs (such as MX RRs) to
> interleave a randomized subset of network type addresses.
What about not sending any of A or AAAA unless both RRSets fit or "glue"
is really necessary? That will add another round-trip, but the end system
can choose (of course prep'ing its closest cache for the TTL to come).
-Peter
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
