John Crain alluded to the point I want to reinforce here. There are many different operational postures. It's tempting to see a situation as it applies to just one. The three snips below illustrate common environments I've run across - TLD (/registration zones), remote debugging (/third-party management), and enterprise.
When I think of "generally" I assume the latter environment. By
comparison, there are very few operations that handle TLD (and root) zone.
The remote debugging is an interesting environment. On the one hand it is
benign, "coaching" and basically freely helping others. But the technical
footprint of it is not far removed from outside surveillance ("the NSA" or
corporate spying), with the real difference locked into "intent." And
sometimes even benign outside help is considered an intrusion.
As far as "generally unwise" - I am not the kind who likes loose ends. By
analogy, I see opening up AXFR on serves like walking with my shoes
untied. It's convenient (to not have to bend over and tie them) but if I
step on one end I trip over. Usually, my stance is wide enough that I
don't trip. The other concern is getting the laces wet in puddles, so I
pull them in. (Yes, it is disturbing I've actually thought about this.)
And worse yet, when I do this, my wife will frown at me. I.e., once I
mitigate the risks of tripping, stepping in puddles, and the scorn of my
wife, it's fine. If I don't consider these risk, I've been unwise.
On 4/14/15, 18:58, "Patrik Fältström" <p...@frobbit.se> wrote:
>
>I see personally quite a number of registries that are nervous about
>XFR (or release of the zone in one way or another)
On 4/14/15, 19:29, "Mark Andrews" <ma...@isc.org> wrote:
>
>I, and I know others, have been able to debug DNS problems reported
>on bind-users because we could see the full zone contents which
>would have been harder or perhaps impossible to solve otherwise.
On 4/14/15, 16:31, "Michael Sinatra" <mich...@brokendns.net> wrote:
>
>The real reason I see for restricting AXFR is to preserve resources on
>the server. This is less of an issue now than it was in the BIND 4 days
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
