On the closest server question it will prefer the closest but a certain
percentage will go to servers further away. Additionally depending on the
version of BIND and the distance it could lead to the servers further away
taking more traffic in high QPS situations.

If you are getting high QPS you could fire off a large amount of queries to
the "slower" server before it responds and resets its SRTT. I believe newer
BIND versions have moved away from a static decrement value and has fixed
the issue but even fixes some queries will go out of region.


On Sun, May 8, 2022, 12:47 PM Bob McDonald <bmcdonal...@gmail.com> wrote:

> Thanks for the answers. A couple more questions and then I'll stand down.
>
> First, it's Ben Croswell. Just pointing that out.
>
> Second, my reading of the definition of a static-stub zone in the Bvarm
> indicates that its use is to allow a local copy of the NS list which may
> differ from the primary zone. I'm not sure that's what I'm looking for. I
> think I'm ok with the NS list from the primary zone. Lei me take another
> swing and try to be a bit more pedantic to see if that helps.
>
> I wish to define a global internal DNS environment.
>
> At the level closest to the client would be a global network of recursive
> DNS servers which would handle all internal and external DNS requests. The
> internal DNS zones would be housed on a global network of authoritative
> only DNS servers. The NS list for the internal DNS zones on these
> authoritative only servers would be known to the recursive servers via stub
> zones. My question is, if a client in Mumbai submits a DNS request to his
> local recursive server for an internal authoritative only zone defined by a
> stub zone statement, which authoritative only server does the recursive
> server pick from the NS list and will that eventually be the "closest"
> server. I'm assuming a global distribution of the authoritative servers.
> E.g. Hong Kong, London, US East, US West, South Amer, etc. The use of the
> stub zones in this case is to eliminate the need for an internal root. I
> want to avoid lookups for example from clients in Asia being sent to
> authoritative only servers in South Amer.
>
> Bob
> --
> 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
>
-- 
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

Reply via email to