Todd Lyons | 1 Jun 22:08 2009

Re: Help, I can´t make a delegation :(

2009/5/29 Reyner Herrpinark Lugo <rherrpinark <at> estudiantes.uci.cu>:
>
> I have already done that Todd, and I can only get answers if I make a query from the example.com's machine.
>
> With: "dig ns1.us.example.com  <at> 127.0.0.1" on the tip-server machine (10.7.20.3) I get the correct answer:

Here is how I see your system.  Please correct me if I'm wrong:

tip-server.example.com:  authoritative for example.com
ns1.us.example.com:  authoritative for us.example.com

> But Todd, this does not solve what I hope. I expected that queries to reach the delegated name server, for
example, if within the zone us.example.com (in 10.7.20.2 server) I have:
>
> us.example.com |test |604800 |a |null |10.7.20.253 |
>
> When I type "dig test.us.example.com  <at> 127.0.0.1" on the tip-server machine (10.7.20.3) I expected
something like this:
>
> ;; ANSWER SECTION:
> test.us.example.com.   604800   IN   A   10.7.20.253
>
> ;; AUTHORITY SECTION:
> us.example.com.   604800   IN   NS   ns1.us.example.com.

The data I gave you was only for the ns1.us.example.com server.  You
also have to configure the tip-server with the corresponding
information that it needs to send us.example.com queries to
ns1.us.example.com.  So here is what you have to do:

(Continue reading)

Reyner Herrpinark Lugo | 3 Jun 04:49 2009
Picon

Re: 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    | <at>          |604800 |soa      |NULL        |tip-server reynerhl.gmail.com. 20090408 3000 900 108864000 432000|
example.com    | <at>          |604800 |ns       |NULL        |tip-server|
example.com    |tip-server|604800 |a        |NULL        |10.7.20.3 |
us.example.com | <at>          |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 | <at>     |604800 |so      |NULL       |ns1 reynerhl.gmail.com. 20090408 3000 900 108864000 432000|
us.example.com | <at>     |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%';

(Continue reading)

Todd Lyons | 4 Jun 05:24 2009

Re: Help, I can´t make a delegation :(

2009/6/2 Reyner Herrpinark Lugo <rherrpinark <at> estudiantes.uci.cu>:
>
> tip-server.example.com:  authoritative for example.com
> With the following data:
>
> dns_zone       |host      |ttl    |dns_type |mx_priority |data      |
> us.example.com | <at>          |604800 |ns       |NULL        |ns1       |
> us.example.com |ns1       |604800 |a        |NULL        |10.7.20.2 |

I think the above data might be incorrect.  Change it to:
example.com |us         |604800 |ns       |NULL        |ns1.us       |
example.com |ns1.us       |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 | <at>     |604800 |so      |NULL       |ns1 reynerhl.gmail.com. 20090408 3000 900
108864000 432000|

I assume the above line has a typo, and "so" should be "soa".

> My querys are:
> SELECT ttl, dns_type, mx_priority, data
> FROM dns_records WHERE dns_zone='%zone%' AND host='%record%';

I have not examined your queries for correctness.  You should look at
the previous threads from this mailing list from just a few months ago
where others were working on subdelegating dns.

(Continue reading)

Reyner Herrpinark Lugo | 6 Jun 20:24 2009
Picon

Re: Help, I can´t make a delegation :(

Thanks Todd, for giving me encouragement.

Yess Todd, all queries are over tip-server, and sorry, was "soa" and no "so" the type.

Making the changes that you suggested, I can't get an answer for "dig ns us.example.com  <at> 127.0.0.1"

I was reading the named's outputs (named -f -g) and when I ask for "dig ns us.example.com  <at> 127.0.0.1", it's
look correct and return what I expected, take a look:

06-Jun-2009 13:14:44.734 279 query is 'select dns_zone from dns_records where dns_zone=
'us.example.com' limit 1'
06-Jun-2009 13:14:44.734 279 executing query for 0 time
06-Jun-2009 13:14:44.736 279 rs ok
06-Jun-2009 13:14:44.736 279 cleaning up
06-Jun-2009 13:14:44.736 279 unlocking mutex
06-Jun-2009 13:14:44.736 279 returning
06-Jun-2009 13:14:44.737 139 Getting DBI
06-Jun-2009 13:14:44.737 139 Got DBI - checking query
06-Jun-2009 13:14:44.737 139 checked query
06-Jun-2009 13:14:44.737 139 did zone
06-Jun-2009 13:14:44.737 139 did record
06-Jun-2009 13:14:44.737 139 did client
06-Jun-2009 13:14:44.737 139 built query
06-Jun-2009 13:14:44.737 139 query is '
SELECT ttl, dns_type, mx_priority, data
FROM dns_records WHERE dns_zone='us.example.com' AND host=' <at> ';
'
06-Jun-2009 13:14:44.737 139 executing query for 0 time
06-Jun-2009 13:14:44.737 139 rs ok
06-Jun-2009 13:14:44.737 139 cleaning up
(Continue reading)

Rob Butler | 9 Jun 17:23 2009
Picon

Re: Help, I can´t make a delegation :(


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

(Continue reading)


Gmane