I noticed this in my messages log
May 29 14:32:23 vps named[7199]: client 217.170.79.11#34175: transfer of 'example.com/IN': AXFR started May 29 14:32:23 vps named[7199]: client 217.170.79.11#34175: transfer of 'example.com/IN': AXFR ended
where example.com is one of my Virtual server domains.
217.170.79.11 is not an IP affilated with my network and is in Amsterdam.
Should I be not allowing this type of zone transfer?
Through google search someone mentioned this:
You can ban everyone from doing so using allow-transfer {"none";}; in the options section of named.conf.If I did that would it cause any normal functionality issues? Is there a way to add that using the GUI of the bind module in webmin or should I just edit the config file manually (named.conf)?
that IP seems to be coming from a russian webhoster
per haps that domain is setting up a slave zone?
I control all domains on the server and I do not have a slave DNS server in Russia!
What should I do?
the other day i noticed the same lines in my log and the IP came from the SIDN which is the Dutch version of ICANN
So I don't think this is a security threat.
Don't use "allow-transfer {"none";};" !!!!!!
If you have slave servers. Instead use "allow-transfer { Slave-IP1; Slave-IP2;};" and so on else your slaves will be denied as well.
Don't use "allow-transfer {"none";};" !!!!!!
If you have slave servers. Instead use "allow-transfer { Slave-IP1; Slave-IP2;};" and so on else your slaves will be denied as well.
that seems to be the point. you can do this in the bind dns server module under zone defaults.
for example this is how mine look like:
for the master server
notify yes;
version "[I forgot]";
allow-recursion {
127.0.0.1;
my.master.server.IP;
my.slave.server.IP;
};
recursion yes;
forwarders {
my.slave.server.IP;
};
allow-transfer {
my.slave.server.IP;
};
};
the slave server looks like this:
allow-transfer {
my.master.server.IP;
};
recursion no;
version "[I forgot]";
};
If you don't use a slave DNS in Russia, just disable AXFR transfers using the "allow-transfer {"none";};" option in the options section of /etc/named.conf
Molski
OK.
I don't have slave servers now but will add one in about a month so that's good to know.
Thanks Scott!
Will "allow-transfer { Slave-IP1; Slave-IP2;};" ONLY allow those IPs?
I other words will it stop the people I don't want from transferring?
Ah Ha!
Thanks for that ronald as I thought that the zone defaults section worked only like a template for creating NEW zones. I didn't know that the lower section was an addition to existing zones so that helps me understand how the modle works a bit better :)
I had added allow-transfer {"none";}; manually and I see that none shows up in the GUI in the lower Default zone settings section. When I set up my slave I will add it's IP there.
Maybe it would be a good idea for the default install of the module to set allow-transfer none untill you manually change it to your slave IP?
From Wikipedia:
<div class='quote'>Of course DNS zone transfers are a necessary and critical aspect of how DNS works, and can not be turned off completely. But DNS zone transfers should only be allowed between DNS servers and clients that actually need it. Typically, only inter-dependent DNS servers will need to do zone transfers. An additional layer of protection with zone transfers can be obtained by implementing DNS keys and even encrypted DNS payloads.
As with all Information Technology security, there is no perfect solution. But implementing multiple security configurations increases the protection of a system.
In 2008 a court in North Dakota, USA, ruled that performing a zone transfer as an unauthorised outsider to obtain information that was not publicly accessible constitutes a violation of North Dakota law.
[edit] Denial of Service
If a malicious entity is able to perform a DNS zone transfer they can launch a Denial of Service attack against that zone's DNS servers by bogging them down with many multiple requests. Not only can the name servers be made slow and unresponsive, in some cases this can lock-out the ability to do legitimate DNS updates by keeping the DNS servers database backend in a "write lock" mode.
However, this is largely fixed by limiting access to do DNS zone transfers. Malicious entities can still pepper DNS servers with bogus requests, but that is not a security issue unique to DNS and has to be handled at a lower level of the OSI model.</div>