Re: Help, I can´t make a delega tion :(

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 no.

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 | 10.7.20.2    (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        |10.7.20.2 |

Rob


----- Original Message ----
> From: Reyner Herrpinark Lugo <[email protected]>
> 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        |10.7.20.3 |
> us.example.com |@         |604800 |ns       |NULL        |ns1       |
> us.example.com |ns1       |604800 |a        |NULL        |10.7.20.2 |
> 
> 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 reynerhl.gmail.com. 
> 20090408 3000 900 108864000 432000|
> us.example.com |@    |604800 |ns      |NULL       |ns1        |
> us.example.com |ns1  |604800 |a       |NULL       |10.7.20.2  |
> us.example.com |test |604800 |a       |NULL       |10.7.20.100|
> 
> 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 10.7.20.3 [authoritative for example.com]):
> 
> dig ns us.example.com @127.0.0.1
> 
> ;; QUESTION SECTION:
> ;us.example.com.            IN    NS
> 
> ;; ANSWER SECTION:
> us.example.com.        604800    IN    NS    ns1.us.example.com.
> 
> another from the same server:
> 
> dig a ns1.us.example.com @127.0.0.1:
> 
> ;; QUESTION SECTION:
> ;ns1.us.example.com.    IN    A
> 
> ;; ANSWER SECTION:
> ns1.us.example.com. 604800    IN    A    10.7.20.2
> 
> Now, it is the trouble:
> 
> dig a test.us.example.com @127.0.0.1
> 
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47560
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;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 pretty 
> shure, is just an idea.
> 
> Todd, please. if you have this trouble resolved, share all your configuration 
> 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.
http://p.sf.net/sfu/businessobjects