Re: DLZ fields in database

After spending some time with this, I wanted to come back and update  
this thread.

On Mar 22, 2009, at 7:33 AM, Rob Butler wrote:
> ----- Original Message ----
>> From: Scott Haneda <[email protected]>
>> To: [email protected]
>> Sent: Thursday, March 19, 2009 8:20:16 PM
>> Subject: [Bind-dlz-testers] DLZ fields in database
>>
>> Hello, I now have DLZ up and running on RHEL, it seems to be working
>> well. I have a few questions, simple probably.
>>
>> Is there any reason I can not mix file based zones as usual in named?
>> I have a small handful of zones that will never change, and rather
>> than run the risk of someone nuking out the entire database, I would
>> like to keep those on disk.  Is this any issue?  I assume I just set
>> up my keys and move on as usual?
>
> No, there is no reason you can't mix DLZ and 'file' zones.  In fact  
> file based zones are required for zones that support rfc 2136  
> dynamic updates as DLZ doesn't support that.

Thanks, this worked out nice, I have it all set up, and working.  It  
was more or less a breeze, just set up a normal instance of named to  
your liking, sprinkle DLZ in later, it just keeps working.

>> Does named log as usual even though all the queries are coming out of
>> a database?  So I can set up a query log, transfer log, and whatever
>> other log breakdowns I want and those will work as normal?
>
> It should log as normal.

And indeed it does, I have separate logs for axfr, query, security,  
etc, they are all logged to by named using files, as well as named  
using a data source.

>> Do I need to update the serial whenever a record changes? Any issue
>> with just making it an in with an on update increment restraint on  
>> it?
>
> That depends on your secondaries.  The serial number for a zone is  
> really to support replication via AXFR & IXFR (full and partial zone  
> transfer).  If you aren't using those mechanisms then there really  
> isn't a requirement that you increment the serial.  It's probably a  
> good idea to do so though just to stay compliant with other's  
> expectations.

I took the simple route here, and set the database to insert a date as  
YYYYMMDD00.  If I make updates on the same day, the 00 is incremented,  
if I make updates on a different day, a new date is added.

>> Does case matter in any way as to what is stored in the database, so
>> 'a' or 'A' ?
>
> I don't believe it does.  All DLZ does is move the storage mechanism  
> from a file to a DB.  You can think of each row in the DB as being a  
> line in a tradditional zone file.  So whatever the required file  
> syntax is DLZ is the same.

This is correct.  In my tests, DLZ did not care about cname over CNAME  
and example.com over EXAMPLE.com.  You can foul it up by setting  
fields in the database to be case sensitive.  Since it takes effort to  
set that, and I do not see anyone doing so, I will not elaborate.

>> Can I use non second values in the database such as 1D, 4H etc etc.
>
> Yes, that should work.  See above.

If you are using the stock sample configs and data from the DLZ  
website, this is not the case.

( http://bind-dlz.sourceforge.net/mysql_example.html)
mysql> describe dns_records;
+-------------+------------+------+-----+---------+-------+
| Field       | Type       | Null | Key | Default | Extra |
+-------------+------------+------+-----+---------+-------+
| zone        | text       | YES  |     | NULL    |       |
| host        | text       | YES  |     | NULL    |       |
| type        | text       | YES  |     | NULL    |       |
| data        | text       |      |     |         |       |
| ttl         | int(11)    | YES  |     | NULL    |       |
| mx_priority | text       | YES  |     | NULL    |       |
| refresh     | int(11)    | YES  |     | NULL    |       |
| retry       | int(11)    | YES  |     | NULL    |       |
| expire      | int(11)    | YES  |     | NULL    |       |
| minimum     | int(11)    | YES  |     | NULL    |       |
| serial      | bigint(20) | YES  |     | NULL    |       |
| resp_person | text       | YES  |     | NULL    |       |
| primary_ns  | text       | YES  |     | NULL    |       |
+-------------+------------+------+-----+---------+-------+
13 rows in set (0.00 sec)

All of the int() types, will not accept a value of 1D for example.  I  
am not sure what all the databases do, some may coerce, some my fail.   
I suggest changing the type if you need to, though the best is to  
leave it as int for performance reasons.

The above schema is already de-normalized to a degree, and from my  
reading, for reasons to support performance.  To move to varchar()  
would probably take a hit in query speed.

>> So far, this is looking like a perfect solution to my needs, thanks
>> for making it available.
>
> Your welcome!

Great project, hope this helps someone else coming here for the first  
time.  Very glad I found this project; with the number of domains I am  
working with, I do not see any other solution as elegant as this for  
the cost, both time and money wise.
--
Scott
* If you contact me off list replace talklists@ with scott@ *


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com