djhdo
By:
djhdo

Why do I get this warning related to DNS packet sizes on Digital Ocean with IPv6?

January 15, 2017 746 views
DNS DigitalOcean IPv6 Networking Debian

At the moment, I have a DNS master being served from my Gandi VPS and slaves operated by friends at Linode. I just set up a new VPS to test as a slave at Digital Ocean, but when I run this DNSSEC test,

http://dnsviz.net/d/ad5ey.net/dnssec/

I get this warning for any queries directed to the IPv6 address of the Digital Ocean VPS:

No response was received until the UDP payload size was decreased,
indicating that the server might be attempting to send a payload that
exceeds the path maximum transmission unit (PMTU) size.
(2604:a880:2:d0::826:6001, UDP_0_EDNS0_32768_4096)

(This address "2604:a880:2:d0::826:6001" is for the IPv6 side of my D.O. VPS. This warning does not appear for any of the Linode or Gandi systems, which are using both IPv4 and IPv6.)

I do run a firewall (ufw), but I get the same warnings regardless of disabling or enabling the firewall.

Thank you,
David

3 comments
  • Update: I wrote my own UDP sender/receiver scripts in python to test the largest side datagram that may be sent between two systems. One system is my VPS at Digital Ocean's SFO2 datacenter, the other system is at Gandi's Paris datacenter.

    When measuring IPv4, I could send up to 65507 payload bytes per message both to and from the Digital Ocean VPS at SFO2:
    Gv4 -> DOv4 = 65507 bytes max
    DOv4 -> Gv4 = 65507 bytes max

    But when measuring IPv6 payload sizes:
    Gv6 -> DOv6 = 65527 bytes max
    DOv6 -> Gv6 = 1452 bytes max

    the Digital Ocean VPS could receive up to 65527 byte payloads, but it could send no more than 1452 bytes.

    These test results agree with the findings when running DNSSEC tests at
    http://dnsviz.net/d/ad5ey.net/dnssec/

    In short, the VPS with Gandi has no problem sending receiving large UDP payload sizes. (And from the DNSSEC test, neither did my peers' systems at Linode who also run slave DNS for me.)

    However, the VPS at Digital Ocean's SFO2 exhibits peculiar behavior:
    It can send large sizes over IPv4, but is crippled in IPv6 to 1452 bytes.

    My request: Does anyone know how to fix this limitation with IPv6 UDP payloads on Digital Ocean's VPS? For now, I'll put in a max-udp-size directive into my name server, but this is suboptimal, since it will force more replies over TCP, including IPv4 which was not having this problem.

    Thank you,
    David

  • Thanks jtittle. Yep, I did submit a ticket in parallel to my inquiry here, and it looks like they are escalating the issue to their Software Networking team for further investigation. (I was also pleasantly surprised I got a response on a holiday weekend!)

    I inquired with the forums here in parallel in case there's some boneheaded thing like a sysctl that I can tweak or whatever, and thus fix the issue before the next business day, Tuesday. :)

    [I did briefly investigate sysctl values by diff'ing the output of "sysctl -a" from both systems. There were a few differences, but much of it was attributed to the differing kernels as well. I also tried diff'ing the sysctl's of the SFO2 VPS comparing the ipv4 and the ipv6 sections, and nothing yet jumped out at me there either. My hack sysctl-quest is inconclusive so far, since I've only been visually searching and spot-checking a few different parameter changes to see if that helps.]

    I'm curious if this issue affects just the one VPS I'm testing on, or if it impacts more customers.

    If the Support folks figure it out before the community here, I'll mark your answer as accepted. :)

  • No progress from support yet on this glitch with IPv6 UDP traffic.

1 Answer

@djhdo

Have you submitted a support ticket? When it comes to networking issues, your best bet would be to submit a ticket and let the support team address the issue on their end. Since this is a community, the best possible scenario is that one of the support team drops by or someone here knows how to fix a specific issue, but when it comes to actual issues that are limiting, I'd get in touch directly.

When it comes to software questions, or general how-to's, the community is perfect, but for something that may require physical access to something those within the community are unable to access, that would be my recommendation.

Have another answer? Share your knowledge.