upgrade 2.2.16 -> 2.2.22 PTR problem (Bugs?)

Hi there,
I have upgraded from version 2.2.16 to 2.2.22. Now I have a problem with DNS.

I have defined several records for one domain/zone which I use as IP "shortcuts", i.e. which resolve to IPs not under my control, for example backup.mydomain.com which resolves to the backup server of my ISP.

The first problem now is, for each of those IPs a reverse zone is created, which makes no sense. As a consequence (or as an additional bug) the entries in those files are not correct either: while the forward declaration is "bla.mydomain.com" the PTR entry is generated as "bla.one-of-my-other-domains.com".

Maybe one should simply not generate reverse zones for IPs that ISPConfig is not responsible for.

The second thing is, I have one hostname which resolves to 127.0.0.1, for that it creates a second reference to 0.0.127.in-addr.arpa in named.conf, which effectively breaks the BIND configuration, as the named.conf.master already contains a static entry for the loopback interface at the top. Bind does not start with two entries for the same zone.

Best regards,
jmroth

 

Well everything is wrong, but if you say so...

I figured that out by myself already
Although I don't think it's a real solution.

 

same problem here.

I have for example 2 domains, say domain1.com and domain2.com

on domain1.com , I have configured home1.domain1.com in the DNS which have my fixed IP at home.

but ispconfig create an arpa file in Bind, with a PTR of my home IP with the wrong reverse home1.domain2.com (instead of home1.domain1.com)

appart creating a PTR of an IP which is not really usefull and may cause problem in some other applications (like SSH which now does not really like the wrong reverse of my home IP and says in the log "possible break-in attempt") , it should at least put the "right PTR" home1.domain1.com and not home1.domain2.com

for now, since I'm not using PTR actually, I have deactivated the "reverse" bloc in the named.conf customised template to avoid these problems.

 

I've added this to the bugtracker.

 

Hmmm ok, I can register for the bugtracker but not post any comments :-\
Here we go then:


Concerning the "Bugfix for PTR records: only one PTR record per IP address; PTR zones are now created correctly" (ISPC 2.2.22). Where was this initial bugfix discussed, I would like to look that up?

I can elaborate more on this BTW.

I have a zone/domain called "blubbi.com" in ISPConfig (both as a web and in DNS).
(The domain does not actually exist/is not mine, it is just for internal testing.)

Now it generates the following PTR records:

/etc/bind# grep blubbi * | grep PTR
pri.0.0.127.in-addr.arpa:1 PTR mysql.blubbi.com.
pri.239.239.213.in-addr.arpa:xx PTR sm.blubbi.com.
pri.245.135.213.in-addr.arpa:xx PTR mde.blubbi.com.
pri.42.198.88.in-addr.arpa:xx PTR hb.blubbi.com.
pri.43.46.78.in-addr.arpa:xx PTR mark5.blubbi.com.
pri.44.198.88.in-addr.arpa:xx PTR a.ns.blubbi.com.
pri.54.11.217.in-addr.arpa:xx PTR m1.blubbi.com.
pri.54.11.217.in-addr.arpa:xx PTR m2.blubbi.com.
pri.54.11.217.in-addr.arpa:xx PTR m3.blubbi.com.
pri.54.11.217.in-addr.arpa:xx PTR m4.blubbi.com.
pri.64.186.195.in-addr.arpa:xx PTR old.blubbi.com.
pri.88.177.195.in-addr.arpa:xx PTR blubbi.com.
pri.90.177.195.in-addr.arpa:xx PTR cs.blubbi.com.

1) My DNS is not authoritative for those networks: only generate (correct) records when the IP of the corresponding A record is also listed in Management->Server->Settings.

If you do that maybe you don't even need the second point (which also does not matter if the initial bugfix had only fixed the bug of "only one PTR record per IP address"):

2) Those are all hosts that I have configured A records for, but NOT in the domain blubbi.com! (except for the root of the domain "blubbi.com." itself of course) I do not know why it chooses blubbi.com!

 

I've completely rewritten the PTR part. Instead of having ISPConfig create the PTR records automatically, there's now a web form (similar to the slave records) where you can define PTR records one by one. This should fix all the problems.