Features Download
From: Rob Butler <crodster2k <at> yahoo.com>
Subject: Re: =?iso-8859-1?q?Help=2C_I_can=B4t_make_a_delega?= =?iso-8859-1?q?tion_=3A=28?=
Newsgroups: gmane.network.dns.bind9.dlz
Date: Tuesday 9th June 2009 15:23:46 UTC (over 8 years ago)
The problem (pulling this from memory way back) is the 'glue record' isn't
included in the first query.  Unfortunately due to a failing of DLZ (well
really BIND) DLZ can't support glue records.

A glue record is a record returned in the additional section of a DNS query
to provide additional information necessary for fully resolving a host. 
Technically, returning glue records (additional record processing) is
optional, but sometimes it's necessary for things to work and overcome the
chicken & egg problem.

In this case, you are stating the server ns1.us.example.com is
authoritative for the zone us.example.com.  Since the authoritative name
server is IN the us.example.com zone, you need to provide the resolver with
a hint (or glue) to where ns1.us.example.com is, because it has no idea how
to find that server otherwise (classic chicken & egg problem).  

In 'normal' BIND zones this works just fine and your first query would've
had the A record for ns1.us.example.com in the additional section of the
query.  DLZ doesn't perform this additional processing and thus the A
record isn't included in the first response.  Is this DLZ's fault, yes and

DLZ is an implementation of the BIND DB interfaces that allows the use of
an external data source like a SQL/LDAP server, BDB, file system, etc. 
It's responsibility is to perform that translation between BIND's
interfaces and the external data stores.  Unfortunately, the logic for
performing additional record processing is part of BIND's default in-memory
DB 'driver'.  The logic for additional record processing should be at the
layer above the DB interface since all DB's should perform the same exact
logic.  Could DLZ replicate that functionality, yes.  Should it, no.  Do I
have the time right now to add it, no.  Do I have time to 'fix' BIND, no. 
Even if I did fix BIND they probably wouldn't accept such a large patch and
change to how BIND works.

In the short term to resolve your problem use a host name outside the
delegated zone and all should be well.  For example

us.example.com | @ | 604800| ns | NULL | ns1-us.example.com.  (notice the
trailing '.' which makes this name absolute and not relative!!)

example.com | ns1-us | 604800 | a | NULL |    (notice the name is
ns1-us not ns1.us, this makes 'ns1-us' a single label.  I've given the name
server a name in the example.com zone instead of the delegated
us.example.com zone).

You can get rid of the last record in your example: 
us.example.com |ns1       |604800 |a        |NULL        | |


----- Original Message ----
> From: Reyner Herrpinark Lugo 
> To: [email protected]
> Sent: Tuesday, June 2, 2009 10:49:36 PM
> Subject: Re: [Bind-dlz-testers] Help, I canĀ“t make a delegation :(
> Firstly, thank you very much Todd for not stopping to help.
> You're correct Todd:
> tip-server.example.com:  authoritative for example.com
> With the following data:
> dns_zone       |host      |ttl    |dns_type |mx_priority |data      |
> example.com    |@         |604800 |soa      |NULL        |tip-server 
> reynerhl.gmail.com. 20090408 3000 900 108864000 432000|
> example.com    |@         |604800 |ns       |NULL        |tip-server|
> example.com    |tip-server|604800 |a        |NULL        | |
> us.example.com |@         |604800 |ns       |NULL        |ns1       |
> us.example.com |ns1       |604800 |a        |NULL        | |
> and ns1.us.example.com:  authoritative for us.example.com
> With the following data:  
> dns_zone       |host |ttl    |dns_type|mx_priority|data       |
> us.example.com |@    |604800 |so      |NULL       |ns1
> 20090408 3000 900 108864000 432000|
> us.example.com |@    |604800 |ns      |NULL       |ns1        |
> us.example.com |ns1  |604800 |a       |NULL       |  |
> us.example.com |test |604800 |a       |NULL       ||
> My querys are:
> SELECT ttl, dns_type, mx_priority, data
> FROM dns_records WHERE dns_zone='%zone%' AND host='%record%';
> now, take a look at some output from dig command:
> (from the [authoritative for example.com]):
> dig ns us.example.com @
> ;us.example.com.            IN    NS
> us.example.com.        604800    IN    NS    ns1.us.example.com.
> another from the same server:
> dig a ns1.us.example.com @
> ;ns1.us.example.com.    IN    A
> ns1.us.example.com. 604800    IN    A
> Now, it is the trouble:
> dig a test.us.example.com @
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47560
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ;test.us.example.com.        IN    A
> It is as if not allowed to transfer the querys through example.com to 
> us.example.com. I mean, the querys never reach the delegated server, I
think if 
> example.com's server find a substring that match with his domain name 
> (test.us.EXAMPLE.COM), he assume hi is authoritaive for that, I 'm not
> shure, is just an idea.
> Todd, please. if you have this trouble resolved, share all your
> files, posting, by mail, where you prefer.
> Thanks a lot.


Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
CD: 4ms