#define DNS_EDNS0_SIZE 1280U

[den...@gmail.com]

Hello Brandon!

Could you please explain the meaning of the subj? This one hardcoded in gdnsd, however I can't understand clearly its influence on behaviour... It seems that it only sets the value of the OPT pseudosection.
If I have some records which imply responses bigger than 1280 bytes what should gdnsd do? Send trunctated even of requested UDPBuf > expected_size_of_response? Or just answer with EDNS response with UDPBuf=1280 set?

I've suspected no convergence in between clients and server if clients haven't got full series of fragments (dropped silently by intermediate gateways).

Playing with that parameter in source code gives me literally nothing. I've tried to increase it to 4096 since I wasn't able to resolve some of my huge pools, at some point it started to work, but seems was just a coincedence with global rerouting when the lostage of UDP fragments disappeared.

Thanks in advance!

[Brandon Black]

On Wed, Aug 13, 2014 at 4:06 PM, <gdnsd+noreply-APn2wQfGKkkaYfpced...@googlegroups.com> wrote:

Hello Brandon!

Could you please explain the meaning of the subj?

The DNS_EDNS0_SIZE define you're referring to in the subject sets the size gdnsd advertises in its responses, and is intentionally a fixed value.  Basically, we want to advertise that the server supports edns0 in general, and in doing that one includes a buffer size.  When gdnsd sets 1280 as an edns0 size in the OPT RR of a response,  it's advertising to the client that we're willing to accept future client query packets up to that size.  This has no bearing on our server->client response packets; those obey the edns0 size sent to us by the client in their request, as well as other constraints.  That fixed 1280 value we advertise could probably be lowered to 512 without any ill effect, but 1280 seems like a pretty reasonable value: it's the IPv6 minimum MTU, and generally considered unlikely to fragment anywhere that fragmentation is avoidable in general on the real internet (e.g. even with some layers of common encapsulation eating up the nominal ~1500 bytes you start with, etc).

Regardless of the value of the DNS_EDNS0_SIZE define, if you want to send e.g. 4K-sized single-packet responses, and the client advertises that it's willing to accept them, it should work.

If you're doing something very non-standard and screwy with giant response packets, the configuration parameter you probably want to take a look at is "max_response".  It defaults to 16K, and can be upped as high as 62464.  Most normal data sets will never even come close to approaching 16K of data in a single response.  However, if you suspect you might be breaking that barrier, you really need to raise that parameter.  There's no warning or nice clean error if you go over it; things will just break horribly (probably crashing the server and/or sending invalid data).  I feel bad having to admit my software has ill-defined behavior in such a case, but the truth is that solving this problem in a cleaner way ends up being a pretty large burden (a complexity one in the codebase, and a startup-time one) on all the sane users, and I'd rather see the ones with insane data bear that burden in the form of needing to discover and use this parameter.

-- Brandon

[den...@gmail.com]

On Thursday, August 14, 2014 12:30:37 AM UTC+3, blblack wrote:

 and I'd rather see the ones with insane data bear that burden in the form of needing to discover and use this parameter.

Just recalled our controversy about huge responses about 1 year ago :D

RE max_response: yes, I saw it in the man page, however default seems good to me since now I've just changed DNS_EDNS0_SIZE to 4096. What do you think about forced payload size? for e.g. if response is bigger than 1280 and client requests UDPBuf=4096 then we send truncated response with limit of 1280 bytes requesting client to fallback in TCP?
However, if you have a big list of different endpoints and a variety of integrations and implementation that also should be configured per RR or configured pool :((

Anyway, thanks for your mention!

[Brandon Black]

Maybe I wasn't clear before: the DNS_EDNS0_SIZE parameter shouldn't need to be changed for *any* reason, which is why it's a define rather than a configuration parameter.  If changing that is fixing something, there's a bug somewhere in gdnsd or the client.

We could easily (and perhaps, should) add a configuration parameter to set an upper bound on the edns0 buffer the client is claiming (e.g. with a setting of 2K, if the client sends us a buffer size >2K, we act as if their setting was merely 2K and truncate with the TC bit and tell them to go use TCP if the data is larger).  However, this would mostly be a workaround for broken clients.  Clients shouldn't be setting large buffer sizes if they can't receive those packets reliably.

[den...@gmail.com]

On Thursday, August 14, 2014 1:00:46 AM UTC+3, blblack wrote:

Clients shouldn't be setting large buffer sizes if they can't receive those packets reliably.

Well, there is a problem with "reliably" definition... Client can ensure that the capabilities are present, however he couldn't be aware of problems of any intermidiate gateways/routers and PMTUD still works poorly nowadays so you cannot fully rely on it. Agree?

[Brandon Black]

Oh I agree those are problems (well, PMTUD should work, but relying on it for regular traffic isn't ideal), but the solution is that if the client is making the requests over the public internet, it shouldn't be configured to set the size that high (especially by default)...  the problem still ultimately lies in mis-configuration or mis-default of the client.  As with our define, 1280 would be a much nicer choice than 4K on today's internet.  Then again those that are drinking full doses of the DNSSEC Kool-Aid may have other concerns about what a sane default response size is anymore...