resolve: remove server 'large' level

[ddstreet]

This removes the DNS_SERVER_FEATURE_LEVEL_LARGE, and sets the EDNS0
advertised max packet size as if always in 'large' mode.

Without this, we always send out EDNS0 opts that limit response sizes
to 512 bytes, thus the remote server will never send anything larger
and will always truncate responses larger than 512 bytes, forcing us
to drop from EDNS0 down to TCP, even though one of the primary benefits
of EDNS0 is larger packet sizes.

[ddstreet]

rebased on main, just to keep this up to date.

@yuwata could you take a look at this if you have time?

[yuwata]

rebased on main, just to keep this up to date.

@yuwata could you take a look at this if you have time?

I'd like to forward this to @poettering or @keszybz. I am not familiar with DNS protocol...

[ddstreet]

just rebased on main to keep this up to date.

[technicianted]

Can we expedite this? the issue causes hostname failures if tcp dns is not available.

[ddstreet]

rebased, and also opened #20993 for this

[fredflev]

the issue causes hostname failures if tcp dns is not available.

I can confirm ^^ '

Using feature level UDP+EDNS0 for transaction 49776.
Using DNS server 168.63.129.16 for transaction 49776.
Sending query packet with id 49776.
Processing query...
Processing incoming packet on transaction 49776. (rcode=SUCCESS)
Reply truncated, retrying via TCP.
Using feature level UDP+EDNS0 for transaction 49776.
Timeout reached on transaction 49776.
Retrying transaction 49776.

[keszybz]

Sorry for the delay. The changes to the code look correct.

@poettering, review?

[poettering]

Did anyone actually do a review of this? I totally don#t follow here. @keszybz you merged this, what's going on here?

The original idea was that we'd start out with "large" mode, and if that fails, will fall back to simple edns0 (and thus still get better error codes and stuff, but no large packets) mode. Now you basically removed the latter? Why though?

The thing is that whether edns0 works or not is primarily a question of the server implementation. While the packet size is a lot more a question of the gateways in between... Hence it makes sense to discern edns0 mode from large mode, and still to edns0 if the large stuff doesn't work.

Anyway, I don't understand what the rationale for removing this altogether is. There's no rationale for that given.. Only this:

"Without this, we always send out EDNS0 opts that limit response sizes
to 512 bytes, thus the remote server will never send anything larger
and will always truncate responses larger than 512 bytes, forcing us
to drop from EDNS0 down to TCP, even though one of the primary benefits
of EDNS0 is larger packet sizes."

But that sounds like an issue that the large level is not sued on the offending system at all?

I mean, I am not questioning that there's a bug, but it seems a bit drastic to remove the middle level altogether.

So, what's the rationale here?

[poettering]

I filed #22368 as a revert for this. Not necessarily something to merge, but just so that we can track this, because this doesn't look right to me, and this requires further discussion.

(Sorry for catching up so late, I have been on parental leave the past months)