On Feb 23, 2011, at 12:19 PM, Kevin Darcy wrote:
Unless one intimately knows the failure behavior of
*every*single*app*and*subsystem* in one's environment (which in a
large/complex environment is a constantly moving target, since new
apps
and subsystems are being implemented all the time), one should err on
the side of safety and ensure that DNS resolution still works even if
the resources that the address (A/AAAA) records point to is
unavailable.
Ah yes, but for any given application, how do we know which is safer?
Failure to resolve the name? Or resolving the name and then failing
to connect? If an app doesn't handle some error conditions
well, why is it safer to assume a priori that one specific error
(failure to connect) is handled well and another (failure to resolve
the name) handled poorly? By resolving the DNS to something,
we could be making things worse.
If we establish that a critical app can handle a failure where name
resolution works but connecting to the service does not, but cannot
handle
a failure where name resolution doesn't work, and the app cannot be
fixed, then yes, we have an incentive to provide some type of name
service that always resolves to something or other. We also have
an incentive to get rid of that app, tell others about its weaknesses,
etc.
John
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
