[Pdns-users] DNS answer don't fit UDP packet

[Antoine Levavasseur]

> For now I reduced my mx list to fit UDP.
> 
> But is there any configuration that makes PDNS shrink ADDITIONAL SECTION
> in order to fit UDP and answer UDP query with UDP.

Some insightfull comments can be found in RFC1123 

*************
6.1.3.2  Transport Protocols

            DNS resolvers and recursive servers MUST support UDP, and
            SHOULD support TCP, for sending (non-zone-transfer) queries.
            Specifically, a DNS resolver or server that is sending a
            non-zone-transfer query MUST send a UDP query first.  If the
            Answer section of the response is truncated and if the
            requester supports TCP, it SHOULD try the query again using
            TCP.

            DNS servers MUST be able to service UDP queries and SHOULD
            be able to service TCP queries.  A name server MAY limit the
            resources it devotes to TCP queries, but it SHOULD NOT
            refuse to service a TCP query just because it would have
            succeeded with UDP.

            Truncated responses MUST NOT be saved (cached) and later
            used in such a way that the fact that they are truncated is
            lost.

            DISCUSSION:
                 UDP is preferred over TCP for queries because UDP
                 queries have much lower overhead, both in packet count
                 and in connection state.  The use of UDP is essential
                 for heavily-loaded servers, especially the root
                 servers.  UDP also offers additional robustness, since
                 a resolver can attempt several UDP queries to different
                 servers for the cost of a single TCP query.

                 It is possible for a DNS response to be truncated,
                 although this is a very rare occurrence in the present
                 Internet DNS.  Practically speaking, truncation cannot
                 be predicted, since it is data-dependent.  The
                 dependencies include the number of RRs in the answer,
                 the size of each RR, and the savings in space realized
                 by the name compression algorithm.  As a rule of thumb,
                 truncation in NS and MX lists should not occur for
                 answers containing 15 or fewer RRs.

RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989

                 Whether it is possible to use a truncated answer
                 depends on the application.  A mailer must not use a
                 truncated MX response, since this could lead to mail
                 loops.                 Responsible practices can make
		 UDP suffice in the vast
                 majority of cases.  Name servers must use compression
                 in responses.  Resolvers must differentiate truncation
                 of the Additional section of a response (which only
                 loses extra information) from truncation of the Answer
                 section (which for MX records renders the response
                 unusable by mailers).  Database administrators should
                 list only a reasonable number of primary names in lists
                 of name servers, MX alternatives, etc.

                 However, it is also clear that some new DNS record
                 types defined in the future will contain information
                 exceeding the 512 byte limit that applies to UDP, and
                 hence will require TCP.  Thus, resolvers and name
                 servers should implement TCP services as a backup to
                 UDP today, with the knowledge that they will require
                 the TCP service in the future.

*************


By the way it seems that truncating additional section is the
recommended strategy, but in this case this affect the caching
possibility.

I have not already look at the code to see if it's possible to truncate
the answer just before sending the UDP answer or if this affect powerdns
caching strategy.


-- 
Antoine.