Murray writes: > > * tcp retry of a DNS query does not happen; > Requires _FFR_DNS_UPGRADE.
Thanks! I hope it gets enabled by default in the next version. > > with a TC bit set, even though the requested RR is present in the > > reply (but the gratuitous authoritative section is truncated). > > Isn't that impossible without something like EDNS0? > > How, for example, could I tell that the reply is actually complete when > TC is set, without making any assumptions about EDNS0? > > * the complete requested RR _is_ included in a response, > > so according do DNS rfc the client is permitted to use it > > if it choses to do so, despide TC flag being set; > > I don't remember seeing in RFC1034/1035 how I can tell that the reply is > complete even though TC is set. I believe this is a safe bet: if the 'Answers' section is followed by some other section (like 'Authoritative nameservers', or optional data section, it is a relatively safe to assume the 'Answers' section was not truncated. It seems the answer is somewhat moot, and people have different opinions. Here is what I could find: RFC 2181: If the Answer section of the response is truncated and if the requester supports TCP, it SHOULD try the query again using TCP. Note it is _not_ the 'Answer section' that is truncated in my example. Where TC is set, the partial RRSet that would not completely fit may be left in the response. When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies. Note the use of 'should', not 'MUST'. Whether it is possible to use a truncated answer depends on the application. Indeed. Here is one expired draft: http://tools.ietf.org/id/draft-fujiwara-dnsop-bad-dns-auth-03.txt Authoritative DNS servers with large RRSets whose response size may exceeds 512 octets must answer TCP DNS query and should support EDNS0. Or the RRset cannt be resolved. An interesting thread is at: http://www.ops.ietf.org/lists/namedroppers/namedroppers.199x/threads.html with a subject: 'BIND 4.9 and the "truncate" bit' Here is a tiny clip: If the truncation occurs in the additional data section, it probably isn't worth doing a TCP query. A posting in that thread: http://www.ops.ietf.org/lists/namedroppers/namedroppers.199x/msg00755.html also applies to what Bind 9.3.? is doing. The RFC 4472 offers some interesting reading on the matter. Time to start flagging queries by EDNS0 [RFC2671] I guess. What is the situation in this area? Mark ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ dkim-milter-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
