Re: Error: dns_rdata_fromtext: buffer-0x413fe440:1: near 'www': bad dotted quad

> Additionally, 
there 
were 
a 
few 
things 
that 
were 
not 
clear 
until 
more
> googling 
and 
more 
staring 
at 
the 
DLZ 
docs.  
I 
found 
the 
answers 
I
> needed 
mostly 
in 
the 
Postfix 
examples 
section, 
oddly 
enough.

I think you mean the PostgreSQL section, not Postfix - that's a mail server.

> 1. 
The 
first 
lookup 
is 
for 
the 
record 
you're 
attempting 
to 
find, 
for
> example 
'www', 
and 
the 
second 
lookup 
is 
for 
'@', 
of 
which 
that 
must
> return 
the 
SOA 
record 
at 
the 
very 
minimum.  
Returning 
all 
the 
SOA
> information 
with 
each 
and 
every 
lookup 
does 
absolutely 
nothing, 
so 
my
> original 
assumption 
was 
false.

Right, you should only return what is asked for by DLZ, not try to out-think it and return more than you need.

> 2. 
The 
SOA 
field 
(4th 
field 
of 
the 
SOA 
record 
returned) 
must 
be 
single 
a
> concatenated 
string 
of 
all 
the 
parts, 
not 
the 
parts 
returned
> individually.  
That's 
not 
clear 
from 
the 
documentation, 
but 
it 
is
> implied 
by 
the 
query 
configuration 
in 
the 
PostgreSQL 
and 
MySQL 
examples.

Actually, that is incorrect.  You can return all the parts individually and DLZ will concatenate them for you.  But it's probably more efficient to concatenate at the DB because fewer columns are returned.  Returning a result set that is wider, but has lots of empty columns for all non-SOA records isn't as efficient.

> 3. 
The 
mx_priority 
must 
be 
NULL 
for 
all 
records 
except 
MX 
records.

Duh! DLZ is standard DNS, nothing magical.  So if your record normally wouldn't have that field, it should be null in the DB.

> Item 
#3 
was 
kind 
of 
heartbreaking 
for 
me 
because 
up 
until 
that 
point, 
I
> had 
managed 
to 
keep 
my 
tables 
unchanged, 
but 
in 
the 
end 
I 
had 
to 
create
> an 
mx_priority 
column 
in 
my 
domain_record 
table.  
My 
original 
table 
only
> had 
name 
and 
value, 
but 
MX 
records 
must 
have: 
>   
name 
'@'
>   
value 
'mail_server_name' 
>   
mx_priority 
(positive 
integer)  
> I 
just 
couldn't 
cram 
the 
information 
into 
a 
name/value 
pair 
without 
a
> (more) 
complex 
(than 
it 
needs 
to 
be) 
query.

Well you can put all the records data (rdata) in one column if you choose, because internally DLZ just concatenates it.  But it usually is easier to have a separate column for each field.

> Again, 
thanks 
for 
pointing 
me 
in 
the 
right 
direction.  
Without 
that
> first 
crucial 
bit 
of 
information, 
none 
of 
this 
would 
have 
started 
making
> sense.

No problem.  There's always something that trips new users up.  If it's not one thing it's another.  Many people come to DLZ because they think it's easier than 'standard' zone files.  Actually it's more complex because you have to understand DNS and figure out how to put that in a DB.

Rob



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/