[OpenIndiana-discuss] OI IPv4 Stack setting DF flag on fragmented UDP packets

[James Carlson]

On 12/04/17 13:01, Markus Wernig wrote:
> I switched our DNS from Sol 11.3 to OI illumos-cd964fce75. After that, I
> noticed that some reply packets sent by the new server would no longer
> get through the firewalls. The reason appears to be that they are
> fragmented, but still have the DF (dont-fragment) flag set. This happens
> whenever a reply packet is larger than the interface's MTU (1500), which
> is easily reached with any DNSSEC enabled query.

This is normal behavior for IPv4 in Solaris; it's part of Path MTU
Discovery.  For IPv6, it's even more strict: intermediate nodes are not
supposed to fragment at all -- only the original sender -- so Path MTU
Discovery is simply required.

The way it's supposed to work is that the DF flag causes any
intermediate router that needs to fragment to return a "Fragmentation
Needed" ICMP error instead.  This error message will have the restricted
MTU in it, and the OS caches this information for the next try.  (It's
stored in the IRE, which, in this case, is effectively a
per-IP-destination cache.)

You can turn off Path MTU Discovery (google "disable pmtud"), but it's
probably a good idea to find out what's really broken here.  Is
something filtering ICMP error messages improperly?

I don't know of any way for an application (BIND/named in this case) to
do anything with the DF bit on Solaris.  Linux has a sockopt for this
(IP_MTU_DISCOVER) as does AIX (IP_FINDPMTU), but I don't think that
Solaris does.

I think a better idea is to set up your DNS server to use TCP when it
needs to send ridiculously big replies.  Using UDP for large messages is
just fraught with peril.

> Solaris in the same situation also fragments the reply packet, but does
> not set the DF flag.

That's not the default behavior.  The default is to have DF on, at least
on the Solaris versions I'm familiar with.  (I guess Oracle could have
changed this, though I think it would be wrong to do so.  Path MTU
Discovery is a good thing, not a bad thing.)

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>