Best way to handle multiple retries from BIND?
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 -- 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 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
