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. _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
