Projects / PostgreSQL BIND-9 SDB interface

PostgreSQL BIND-9 SDB interface

PostgreSQL BIND-9 SDB interface is an enhanced version of the original pgsqldb interface which is included with the BIND-9.1.3. This patch allows you to store all your zone data in a PostgreSQL database rather than in text files. This even makes changes visible immediately without restart/reload of the named server. It also includes PL/SQL functions and triggers to simplify reverse updates.

Tags
Licenses
Operating Systems
Implementation

Recent releases

  •  06 Aug 2001 15:52

    No changes have been submitted for this release.

    Recent comments

    22 Oct 2008 08:55 dazo

    Development ceased
    This project is no longer maintained, as you most probably have understood.

    If anyone are interested into continue this project, please get in touch and we'll make sure this can happen.

    Kind regards,

    David Sommerseth

    15 Aug 2001 17:14 freimer

    Re: Suggestions
    Oops! I thought I was on Sourceforge for some stupid
    reason. These comments were meant for the package
    author and not the general Freshmeat crowd. Oh well,
    now you know what I think of it. The source looks
    great (I haven't tested it in production yet), but it could
    do with some changes and enhancements. Keep in
    mind this is a 0.0.1 version release...

    Fred Reimer

    15 Aug 2001 17:09 freimer

    Suggestions
    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


    Screenshot

    Project Spotlight

    OpenStack4j

    A Fluent OpenStack client API for Java.

    Screenshot

    Project Spotlight

    TurnKey TWiki Appliance

    A TWiki appliance that is easy to use and lightweight.