Issues with bind

My syslog spams these messages when bind restarts (fails).

Oct 18 04:09:12 bigfoot named[26716]: starting BIND 9.2.4 -u bind -t /var/lib/named
Oct 18 04:09:12 bigfoot named[26716]: using 1 CPU
Oct 18 04:09:12 bigfoot named[26716]: loading configuration from '/etc/bind/named.conf'
Oct 18 04:09:12 bigfoot named[26716]: /etc/bind/named.conf:32: zone '0.0.127.in-addr.arpa': already exists
Oct 18 04:09:12 bigfoot named[26716]: loading configuration: failure
Oct 18 04:09:12 bigfoot named[26716]: exiting (due to fatal error)

My named config looks as following:
zone "." {
type hint;
file "db.root";
};

zone "0.0.127.in-addr.arpa" {
type master;
file "db.local";
};

zone "40.115.217.in-addr.arpa" {
type master;
file "pri.40.115.217.in-addr.arpa";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "pri.0.0.127.in-addr.arpa";
};


If I comment or remove :
zone "0.0.127.in-addr.arpa" {
type master;
file "db.local";
};

bind starts fine, but trouble returns everytime ispconfig re-generates named.conf .
Does anyone have an idea on how I can fix this?

 

I found the issue 2 seconds after.
This could count as a critical bug.

If the user sets a domain IP address as 127.0.0.1 , ispconfig will attempt to create the zone for 127.0.0.1 when the file pri.0.0.127.in-addr.arpa is created and bind will fail to start.

Behaviour is repeatable with latest version of ispconfig (2.2.7).

 

Thing is, I havent entered 127.0.0.1 as an ip in server-settings.
I'm using a stripped-down reseller account without any space and traffic to hand out as DNS-manager for customers who need to be able to host/change their own zones.

If a reseller could inadvertly break the config, I dont call that very secure.

 

What sense does it make to use 127.0.0.1? If you host web sites on that IP address, they cannot be accessed from outside...

But the reseller cannot access the server settings section, and if you put in the right IP addresses, then there's no problem.