Architecture Questions

[Mark Andrews]

In message <D6C04EC67151214DAD5E55E7EBF5207E425E3836 at WRXXENTEXMB01.na.follett.l
an>, "Baird, Josh" writes:
> Hi,
> 
> I have historically hosted authoritative slave zones on my internal caching/r
> ecursive servers to override recursion for internal zones.  These servers are
>  not directly reachable from the internet.  Generally speaking, I realize tha
> t it is considered a bad practice for any authoritative servers to perform re
> cursion.  Is it a common practice in this particular scenario though?
>
> The other option would be to have 'X' number of authoritative servers with re
> cursion disabled, and then spin up another dedicated caching/recursive tier w
> hich used stub zones to communicate with the authoritative servers.   Clients
>  would point directly to the caching tier for name resolution.   This scenari
> o sounds like it would be more cumbersome to maintain.  It would also require
>  additional servers.  I'm not sure the additional hardware and complexity is 
> worth trouble in this scenario, but I am looking for opinions.
> 
> Furthermore, I was recently told by one of the larger managed IPAM/DNS vendor
> s that it was on ISC's roadmap to no longer allow authoritative servers to pe
> rform recursion (ie, the 'recusion yes' option would be disabled if the serve
> r contained authoritative zones).  Is this actually true?

No.  There are good reasons to allow a server to perform both roles.

What isn't advisable is for a listed server offering authoritative
service to the world to also be recursive.  This risks leaking
cached data to the world.  It can also result in answers being
returned when referrals are expected.  Sharing rolls is very bad
if you serve not leaf zones to the world.  If there are only leaf
zones being served it is not such a issue.

A internal server or a recursive server having copies of zones isn't
generally issue though you do need to be careful about the type of
response you generate depending upon RD state.

This is a much more complex issue that is generally acknowledged.

> Thanks,
> 
> Josh 
> _______________________________________________
> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org