They don't actually explain how to disable AXFR...saying just: "The easiest way to fix this issue is to re-check your dns server’s configuration file. Make sure that the nameservers only allow AXFR to subsidiary nameservers and that these aren’t allowed to answer AXFR requests."
In BIND, this is configured by the allow-transfer option. You can explicitly allow your slaves with an option like:
allow-transfer { 192.168.1.1; };
Or, disable all transfers by specifying "none;". This can be done on a per-zone basis, as well, though the global section will apply in the absence of zone-specific configuration, which I suspect is how so many servers are misconfigured (i.e. there is no rule in place to block it in the global section, so it is allowing all for zones that don't have an allow-transfer section). I just noticed that some of my zones on slave servers fall prey to this, as well, even though I know better. The default seems to be to allow all, if allow-query allows all.
That said, I'm not overly alarmed. Very little (roughly zero) sensitive data exists in my world-facing zones.
We thought about putting some "example fixes/configurations" into the blogpost, but then abandoned the idea, because there are a lot of different DNS servers out there.
Only covering a few didn't seem useful to us.
So thank you for giving an example configuration for BIND :)
Haha...you know enough to know that BIND has tremendous market share. It may not be the best name server, but it's definitely the most popular. Why not help 65%+ of name server administrators with specific advice?
The article author seems to ignore the existence of views. If you have confidential data query-able from the outside, it's a much bigger issue than wide open AXFR... Restricting AXFR is more cute than efficient, the information still leave your network unencrypted.
6 comments
[ 1.9 ms ] story [ 20.0 ms ] threadIn BIND, this is configured by the allow-transfer option. You can explicitly allow your slaves with an option like:
Or, disable all transfers by specifying "none;". This can be done on a per-zone basis, as well, though the global section will apply in the absence of zone-specific configuration, which I suspect is how so many servers are misconfigured (i.e. there is no rule in place to block it in the global section, so it is allowing all for zones that don't have an allow-transfer section). I just noticed that some of my zones on slave servers fall prey to this, as well, even though I know better. The default seems to be to allow all, if allow-query allows all.That said, I'm not overly alarmed. Very little (roughly zero) sensitive data exists in my world-facing zones.
We thought about putting some "example fixes/configurations" into the blogpost, but then abandoned the idea, because there are a lot of different DNS servers out there.
Only covering a few didn't seem useful to us.
So thank you for giving an example configuration for BIND :)
Thanks!
http://www.cyberciti.biz/faq/linux-unix-bind9-named-configur...
that's another good point!
Thanks for bringing it up.