[dns-operations] specifics of UDP response with truncate bit; odd google fail on AAAA responses w/ truncation

[paul vixie]

On 5/25/2012 5:20 AM, David Miller wrote:
> On 5/24/2012 11:08 PM, paul vixie wrote:
>
>> the header counts must match the actual contents but the
>> prospective/desired contents, or else the response is malformed.
>
> There was supposed to be a "not" somewhere in this sentence?

yes. oops. here's the rest of what i meant to say; smartphones are not
good e-mail sending devices.

> the way i treat TC in responders i write is, it means that at least the
> final section is truncated. therefore i am willing to cache rrsets found
> in the second-to-last non-empty section. if that gives me enough to work
> with, i don't have to repeat the query. if it doesn't, then i either
> make a new query (if the thing i need now is just the glue from the
> prior response) or i retry the same query using a transport that allows
> for a larger response (so, a larger advertised response size in
> edns/udp, or just try tcp.)
>
> in the case where the counts are zero and the seconds are empty, i
> clearly have to repeat the query.
>
> that's an initiator-side view of tc. the responder-side view is, if you
> run out of room while you still have things you wish you could add to
> the response, then you might be about to set tc. it depends on what you
> were adding. if it was convenience glue (so, not a subdomain of a
> delegation point, if this is a referral; or if it's additional data due
> to MX or SRV, and this is not a referral) then you can just clear out
> any partial rrsets you may have added, and not bother setting tc. if
> you're running out of room earlier in the response, like in the answer
> or authority section, then you might as well clear all the sections and
> set tc.