I'm just installing Bind 9 now, so I haven't used this package yet, but here are some suggestions right off the bat:
1) Make the 'only connected when needed' an option. For heavily used DNS servers this is going to be a killer CPU hog and slow things down hugely. For example, I'm using a DNS server on my network management boxes and they constantly perform lookups for all of the devices they monitor. Every time a port goes down, every time an event gets generated, a lookup is performed.
2) Make the modified reverse lookup changes optional. 111.222.233 is not an IP address, it's label, and it's full name is 233.222.111.in-addr.arpa. 111.222.233.233 may be an IP address, but it should be left in the traditional syntax to prevent confusion. There are other types of data in the reverse lookup domains than just IP addresses. There are NS records, of course, and some people use subnet reverse lookups to find the name of a subnet instead of an IP address. For example, some network management packages will do a reverse lookup on a subnet, say 223.222.111.in-addr.arpa for the subnet 111.222.223/24 to find out the name of the subnet that it places on network maps. While this only works for 8-bit boundary subnets, it is still quite useful. The changes make sense for those who only require IP addresses themselves in the reverse lookup domains, but it makes it unwieldy for those with more diverse needs.
3) Change the names of all of the routines to epgsqldb insted of using the names pgsqldb. pgsqldb is already used by the "official" ISC Bind package and they are likely to modify and expand these routines in future versions. Your package is called epgsqldb, so why create a name scope conflict by taking over the function names of offical SDB? I'd actually like to load both of them in one named binary at the same time in order to perform some performance comparisons.
4) The reverse update triggers are a great idea! I would expand this so that when a reverse entry is edited it finds the forward entry and updates the IP address automatically [This should be an option, of course. There are two main practices for reverse lookups. A practice used by some is to create different PTR records for each interface on a host and have these point to different names. This is most commonly done so that your traceroutes show the interface that the packet was received on. IMO this is an incorrect use of the DNS, and I follow the other practice. The alternative, which follows all of the RFC's that state hosts have DNS names and interfaces do not, is to point all PTR records to the same name. If you follow the first practice you may be safe in looking up the interface name and updating its record -- if there is one (some people insist on having interface IP's resolve to different names, but don't have A records for these IP's!). If you follow the second practice you will update your A record to point to the last interface IP that ws updated. A quick check would be to only update the A record that the PTR record points to if the A record had the old IP address that is being changed in the PTR record!]. Another potentially useful trigger would be to automatically update the SOA record to increase the serial number whenever a change is made to a domain. There are other more esoteric checks that can be made to enforce database entegrity, such as not allowing MX records to be entered unless there is an IP address (A record) for the destination. Lastly, I would attempt to program all of the triggers in an embedded language if at all possible, with PL/SQL being the prime candidate. It should be available on all PostgreSQL installations, so it makes the logical choice. I'm not sure if it has all of the programming constructs that would be necessary, but if it does there is no reason not to use it rather than having a bunch of dynamically loaded object files compiled from C.
All in all, I think the enhanced pgsql SDB is great, and if I have time I'll try to contribute as much as I can. Unfortunately, my time is rather tight at the moment (I wonder how I made the time to type all this up!). Thanks for the effort and good luck to any future enhancements you make!
Fred Reimer
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you so much Fred for your feedback! I realy appreciate your comments.
I'm working on this project to use a configuration file instead of using all those parameters to each zone. And I've already thought of this with persistent pgsql connections but I felt it was appropriate to "improve" the original - that one opened a connection for all zones, even if they used the same database and I'm trying to avoid that. (PostgreSQL is by default limited to 32 connections at the same time ... so if you have 33 zones using this driver, you're in trouble! Of course, it's possible to increase this value)
The next release will have removed all the epgsqldb <--> pgsqldb conflicts too. I just hadn't enough time (and energy) to change that at this stage ... I simply thought: Hey, it's a beta release! Several changes will come!
When it comes to the trigger ... I tried to make everything into PL/PGSQL ... but I had some realy nasty problems retrieving and manipulating all the information that was needed for the reverse update, but it worked in C. It might be some bug in the PL/PGSQL interface or it's simply me which is doing something realy wrong.
And the MX check ... sounds like a simple task ... and the SOA update sounds like a great idea!
I've also thought of being able to configure another database server (rather than the local thru a unix socket at the moment, unless you've added the 'Non-Unix domain sockets support' by cissp) ... also this thru the configuration file I've mentioned. This should actually remove the need for "local" secondary DNS server, since both servers may access the same PostgreSQL database. (But for remotely secondary DNS it has to be done like before)
When it comes to your comments about the modified reverse lookup and make this optional, I will include this in the todo list!
If you are able to do some speed analyzes of this driver, and can compare them against the "original pgsqldb" and the "old fashioned" zone files ... it would be great to see the result!
Take care and keep up the good work! Thank you so far!
David S.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm just installing Bind 9 now, so I haven't used this package yet, but here are some suggestions right off the bat:
1) Make the 'only connected when needed' an option. For heavily used DNS servers this is going to be a killer CPU hog and slow things down hugely. For example, I'm using a DNS server on my network management boxes and they constantly perform lookups for all of the devices they monitor. Every time a port goes down, every time an event gets generated, a lookup is performed.
2) Make the modified reverse lookup changes optional. 111.222.233 is not an IP address, it's label, and it's full name is 233.222.111.in-addr.arpa. 111.222.233.233 may be an IP address, but it should be left in the traditional syntax to prevent confusion. There are other types of data in the reverse lookup domains than just IP addresses. There are NS records, of course, and some people use subnet reverse lookups to find the name of a subnet instead of an IP address. For example, some network management packages will do a reverse lookup on a subnet, say 223.222.111.in-addr.arpa for the subnet 111.222.223/24 to find out the name of the subnet that it places on network maps. While this only works for 8-bit boundary subnets, it is still quite useful. The changes make sense for those who only require IP addresses themselves in the reverse lookup domains, but it makes it unwieldy for those with more diverse needs.
3) Change the names of all of the routines to epgsqldb insted of using the names pgsqldb. pgsqldb is already used by the "official" ISC Bind package and they are likely to modify and expand these routines in future versions. Your package is called epgsqldb, so why create a name scope conflict by taking over the function names of offical SDB? I'd actually like to load both of them in one named binary at the same time in order to perform some performance comparisons.
4) The reverse update triggers are a great idea! I would expand this so that when a reverse entry is edited it finds the forward entry and updates the IP address automatically [This should be an option, of course. There are two main practices for reverse lookups. A practice used by some is to create different PTR records for each interface on a host and have these point to different names. This is most commonly done so that your traceroutes show the interface that the packet was received on. IMO this is an incorrect use of the DNS, and I follow the other practice. The alternative, which follows all of the RFC's that state hosts have DNS names and interfaces do not, is to point all PTR records to the same name. If you follow the first practice you may be safe in looking up the interface name and updating its record -- if there is one (some people insist on having interface IP's resolve to different names, but don't have A records for these IP's!). If you follow the second practice you will update your A record to point to the last interface IP that ws updated. A quick check would be to only update the A record that the PTR record points to if the A record had the old IP address that is being changed in the PTR record!]. Another potentially useful trigger would be to automatically update the SOA record to increase the serial number whenever a change is made to a domain. There are other more esoteric checks that can be made to enforce database entegrity, such as not allowing MX records to be entered unless there is an IP address (A record) for the destination. Lastly, I would attempt to program all of the triggers in an embedded language if at all possible, with PL/SQL being the prime candidate. It should be available on all PostgreSQL installations, so it makes the logical choice. I'm not sure if it has all of the programming constructs that would be necessary, but if it does there is no reason not to use it rather than having a bunch of dynamically loaded object files compiled from C.
All in all, I think the enhanced pgsql SDB is great, and if I have time I'll try to contribute as much as I can. Unfortunately, my time is rather tight at the moment (I wonder how I made the time to type all this up!). Thanks for the effort and good luck to any future enhancements you make!
Fred Reimer
Thank you so much Fred for your feedback! I realy appreciate your comments.
I'm working on this project to use a configuration file instead of using all those parameters to each zone. And I've already thought of this with persistent pgsql connections but I felt it was appropriate to "improve" the original - that one opened a connection for all zones, even if they used the same database and I'm trying to avoid that. (PostgreSQL is by default limited to 32 connections at the same time ... so if you have 33 zones using this driver, you're in trouble! Of course, it's possible to increase this value)
The next release will have removed all the epgsqldb <--> pgsqldb conflicts too. I just hadn't enough time (and energy) to change that at this stage ... I simply thought: Hey, it's a beta release! Several changes will come!
When it comes to the trigger ... I tried to make everything into PL/PGSQL ... but I had some realy nasty problems retrieving and manipulating all the information that was needed for the reverse update, but it worked in C. It might be some bug in the PL/PGSQL interface or it's simply me which is doing something realy wrong.
And the MX check ... sounds like a simple task ... and the SOA update sounds like a great idea!
I've also thought of being able to configure another database server (rather than the local thru a unix socket at the moment, unless you've added the 'Non-Unix domain sockets support' by cissp) ... also this thru the configuration file I've mentioned. This should actually remove the need for "local" secondary DNS server, since both servers may access the same PostgreSQL database. (But for remotely secondary DNS it has to be done like before)
When it comes to your comments about the modified reverse lookup and make this optional, I will include this in the todo list!
If you are able to do some speed analyzes of this driver, and can compare them against the "original pgsqldb" and the "old fashioned" zone files ... it would be great to see the result!
Take care and keep up the good work! Thank you so far!
David S.