This seems like a pretty strong hypothesis based on what I've seen in this thread. For a little historical context: Early in Boulder's history, Boulder would ask Unbound for a copy of DNSSEC-related RRsets, with the thought that we would do DNSSEC validation in Boulder itself. In order to make room for the large responses, Boulder would use TCP and also set the OPT RR (Edns0) bit to indicate a large buffer for the response. However, prior to launch we decided to have Unbound do DNSSEC validation for us. Some time later, we switched from TCP to UDP for internal queries to Unbound (for performance), stopped setting the AD (Authentication Data) bit so we wouldn't get the extra data we don't need, and stopped setting the OPT RR (Edns0) to indicate larger buffer sizes, because we no longer needed them. So far that's been relatively fine. The one case where it might run into trouble is if an authoritative nameserver returns a really large number of records. I haven't looked at this particular domain in detail, but other folks in this thread have said there are a very large number of NS and SOA records, some of which aren't used anymore. @own3mall, I'd recommend cleaning up any unused NS records on your domain, because (a) it's likely to fix this issue, and (b) unused NS records are both a performance problem and potentially a security problem, if someone grabs the domain name of those unused records.
If your goal is to convince us to change Boulder to accept large responses, I'd want to see evidence that such large responses are a very common occurrence in otherwise well-configured domains. So far this is the first bug report we've gotten about this behavior. Thank you for bringing it up, though!