Slowing down bind answers

[Sten Carlsen]

On 07/01/14 14.16, Bob McDonald wrote:
> > Unless the goal is to move all DNS services off that subnet.  Our
> network
> > staff would love to reclaim the /24 our DNS servers are tying up
> with very
> > little else on it wasting 250 addresses.
>
> I'm not sure I'm describing a properly configured anycast environment
> well.  Since in anycast the client never see the "physical" address of
> a DNS server, it matters not where they (the DNS server(s))
> "physically" are (only if they are in the anycast cloud or not).  You
> can move them around (insert/delete servers to/from the cloud) to your
> heart's content and the client doesn't know.  The requirement here (to
> avoid having clients left on legacy devices) is that all the affected
> servers be in the anycast cloud and all of your client devices point
> to the "logical" anycast address for DNS resolution NOT the "physical"
> address(es) of the DNS server(s).  You add the new server(s) to the
> cloud and delete the legacy server(s) from the cloud.  Easy peasey. 
> Obviously, this takes some up front planning and having a group of
> servers on the same subnet is probably not a good idea (although it
> could be interesting from a load sharing perspective...).  YMMV, it's
> just a thought.
If I understood the problem correctly, the address the anycast would
take is the address the clients actually use and the new servers can be
set anywhere. In this case they want to free that address for other
purposes.
Again if I understand this correctly anycast might be fine for future
but a bit too late in this case.
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140107/dc110c74/attachment.html>