On 3/29/2004 5:18 AM, Peter Koch wrote: > 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).
Omitting all additional-data is not helpful. http://www.ietf.org/internet-drafts/draft-hall-qtype-addr-01.txt says: | 4.1. Truncated Additional-Data | | In those cases where all of the A and AAAA resource records will | not fit within a response message, the responder MUST truncate the | message according to the following rules. | | Incomplete resource record sets MUST NOT be provided. If this | means that only one or the other resource record types can be | provided as additional data, then only one of those resource | record sets are to be provided. Both resource record sets MAY be | omitted from the additional-data section if necessary or desired. | | If a responder wishes to include one of the resource record sets | (and assuming that there is room in the response message for that | data), the responder SHOULD give a preference to the network type | which was used to transport the original query. For example, if | the original query was received over an IPv6 network interface, | the responder SHOULD give preference to the AAAA resource records | in the response message. That's still the best strategy, IMO, since it prevents incomplete RRsets from being transmitted and cached, and leans towards improving the DNS navigation pointer data that is necessary to locate all other data. In the case of other-application pointers (like MX addresses), it is far better to omit the additional-data than it is to provide and cache incomplete RRsets. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
