Hello J Doe/general, Some comments inline...
On Sat, Mar 26, 2022 at 09:58:01PM -0400, J Doe wrote: > Hi, > > I had a question regarding configuring: /etc/resolvd.conf for use with a > local caching resolver (using BIND), on the loopback address on OpenBSD 7.0. > > This server is a mail server and I make use of DNSBL's such as SpamHaus, > which is why I require a local caching resolver. > > I see in: /etc/resolvd.conf that there are two options for the: options > directive: Do you mean /etc/resolv.conf? I don't see a resolvd.conf but there is a resolvd manpage. > > edns0 > tcp > > Because I have: /etc/resolvd.conf configured to use BIND on localhost, can I > add either: edns0 or: tcp since I know the resolver on localhost supports > this and it's the only resolver I ever contact ? I am thinking that this is > perhaps more efficient than using just UDP without edns0 or tcp. Some fun facts about DNS. A DNS packet can be 0xffff hex (or 65535 bytes dec) maximally. This is true for TCP DNS packets which serve an unsigned short indicator of length before the packet segment. With UDP it's a bit different a UDP packet can be maximally 65535 bytes long but often the MTU of the interface doesn't allow this much room so it fragments at the IP layer if the MTU is below that value. There is a constraint in UDP DNS keeping it to 512 bytes without EDNS set, it can be increased with an EDNS header. Usually the value for this is 4096 but over time it has been reduced to 1232 which was invented at a dns flag day which was a community event with the dns community. Usually what happens is that if the server would truncate on UDP, it would send back a TC indicator in the DNS packet that pretty well requires the query to be redone with TCP in order to get the packet, so it's a hybrid solution in order to make use of maximally 0xffff dns lengths. If you use TCP transport right from the start, the drawback is the 3 way handshake overhead, and the computer will generate more packets due to the TCP ACK. I don't know what the behaviour is in the resolver whether it will connect for each query or stay connected for the next answer. I also don't know if BIND supports it, but I do know in DNS some servers allow this (wether right or wrong), there may also be a timeout for the session to close. Since DNS uses compression in most answers you can cram in a lot of data in even 512 bytes and if not then in 1232 bytes when using UDP. The compression mechanism is unique to DNS and isn't zlib or any of those types of compressions. Having UDP mode on and allowing it to occasionally use TCP for large answers seems rather correct to me. > The other thing I'm wondering is whether this is superfluous ... does BIND > "know" when being queried over localhost to use better network settings that > UDP ? > > Thanks, > > - J I don't know BIND all too well, so I can't help you with this. To sum up what you're asking I would use edns0 option but leave tcp option be. Best Regards, -peter
