Re: Best way to handle multiple retries from BIND?
> On 26 Jun 2023, at 11:05, Fred Morris wrote: > > I have an authoritative server which performs a resource intensive operation > to determine an answer; sometimes it takes long enough that BIND asks again > (and again!). Firing off multiple attempts to determine the answer just digs > the hole deeper. Well what do you expect when the server doesn’t answer? Silence means nothing. Packet loss is a thing. > What's the best approach, assuming the same client asks repeatedly: > • Discard later queries, answer the first one? > • Discard earlier queries, answer the last one? > • Send same the response (when we get it) in response to all queries (I > don't like this one)? If you have a true duplicate you only need to answer it once otherwise you have different clients and you need to answer all of them. Note there can be multiple clients on the same address. > And does anyone know can the recommended mitigation be presumed to be the > best option regardless of the recursive server (BIND, Unbound, etc.)? Fix whatever is causing the server to take a long time to respond. DNS isn’t designed with servers that take a lot of time to respond in mind. Resolution takes long enough without spurious delays. Clients give up in a couple of seconds and the resolver often needs to make 20+ queries to validate a answer. The time budget per query is small and the planet has about a 200ms RTT. > Thanks in advance... > -- > Fred Morris > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Best way to handle multiple retries from BIND?
> If you have a true duplicate you only need to answer it once otherwise > you have different clients and you need to answer all of them. Note > there can be multiple clients on the same address. i gotta ask. so, for address foux, how do i know if there is one client or more than one? randy -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Best way to handle multiple retries from BIND?
> On 26. 6. 2023, at 6:04, Randy Bush wrote: > > so, for address foux, how do i know if there is one client or more than > one? I think you only know that for an established TCP connection. Everything else could be port reuse. Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Best way to handle multiple retries from BIND?
> On 26 Jun 2023, at 14:25, Ondřej Surý wrote: > > >> On 26. 6. 2023, at 6:04, Randy Bush wrote: >> >> so, for address foux, how do i know if there is one client or more than >> one? > > I think you only know that for an established TCP connection. Everything else > could be port reuse. Which doesn’t matter as there can only be one client at any point in time behind the tuple sans a broken NAT implementation. > Ondřej > -- > Ondřej Surý — ISC (He/Him) > > My working hours and your working hours may be different. Please do not feel > obligated to reply outside your normal working hours. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Best way to handle multiple retries from BIND?
I would suggest doing what forwarders do, joining multiple queries into single upstream request. When the answer arrives, send replies to all requestors of this common transaction. If you cannot fix your server to handle the response right away and have pre-computed answers, as is common for authoritative servers. It is expected authoritative server does not have to do anything serious per client. What is that resource intensive operation we are talking about? Do you sign on the fly? Can you explain a bigger picture? Maybe there is a design of the service, which could be improved instead. Attempt to suppress a retry when the server does not answer quickly enough is not correct way of solving it IMO. Regards, Petr On 6/26/23 03:05, Fred Morris wrote: I have an authoritative server which performs a resource intensive operation to determine an answer; sometimes it takes long enough that BIND asks again (and again!). Firing off multiple attempts to determine the answer just digs the hole deeper. What's the best approach, assuming the same client asks repeatedly: * Discard later queries, answer the first one? * Discard earlier queries, answer the last one? * Send same the response (when we get it) in response to all queries (I don't like this one)? And does anyone know can the recommended mitigation be presumed to be the best option regardless of the recursive server (BIND, Unbound, etc.)? Thanks in advance... -- Fred Morris -- Petr Menšík Software Engineer, RHEL Red Hat,https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Best way to handle multiple retries from BIND?
Well in this case... I'd be more interested in ways to tune BIND's internal resolver behavior. On Sun, 25 Jun 2023, Randy Bush wrote: If you have a true duplicate you only need to answer it once otherwise you have different clients and you need to answer all of them. Note there can be multiple clients on the same address. True, in the general case. Here, not so much. i gotta ask. so, for address foux, how do i know if there is one client or more than one? In this case DNS is a gateway sitting in front of a source of telemetry data on a private network, and I know it only has defined clients because I set it up that way. Anything that needs the data can ask those clients (e.g. BIND) and that's the point: to hand off caching and access control instead of reinventing the wheel. Nothing else running on the machine where BIND is running in this example has any need to access the data in the zone, whether directly or via BIND. -- Fred Morris -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Best way to handle multiple retries from BIND?
On 26. 06. 23 3:05, Fred Morris wrote: I have an authoritative server which performs a resource intensive operation to determine an answer; sometimes it takes long enough that BIND asks again (and again!). Firing off multiple attempts to determine the answer just digs the hole deeper. As others said, deduplicate on the auth side. At least it will not dig the hole deeper. What's the best approach, assuming the same client asks repeatedly: * Discard later queries, answer the first one? * Discard earlier queries, answer the last one? * Send same the response (when we get it) in response to all queries (I don't like this one)? And does anyone know can the recommended mitigation be presumed to be the best option regardless of the recursive server (BIND, Unbound, etc.)? Well, if you insist ... you can respond with TC=1 when your internal timeout fires off (which obviously must be shorter than client's timeout), but this is going to be pretty tough race. Knot Resolver used to retransmit after 200 ms or so. Or do TC=1 all the time and answer only over TCP. That usually has more leeway in terms of timeouts, but I doubt you can reliably prolong it over 1 sec. At that mark it starts to smell like slow lorris attack and the client might close the connection. -- Petr Špaček -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
