[Pdns-users] Re: pdns ldapbackend - axfr bug and "patch"

[Norbert Sendetzky]

Hi Peter

Thank you for your very detailed description of your problem :-)

> I'm trying to set up powerdns with ldap backend and after few days of
> configuring ldap and pdns
> for full work (ipv4/ipv6, direct/revers, subdomain delegation, AXFR to
> other slaves without ldap backend) it looks, that there's
> bug for AXFR transfers when domain and subdomain are configured and
> delegated separately to different NS for example (in my case tested on
> revers, but probably also problematic is direct delegation).
>
> I'll try to show you one example:
> ->zone 168.192.in-addr.arpa
> ->subzone 1.168.192.in-addr.arpa
> ->host in subzone 1.1.168.192.in-addr.arpa
>
> zone 168.192.in-addr.arpa:
> - definned SOA  for 168.192.in-addr.arpa
> - subzone delegation i.e. 1.168.192.in-addr.arpa. IN NS any.dns.server.tld.
>
> zone 1.168.192.in-addr.arpa:
> -definned SOA  for 1.168.192.in-addr.arpa
> -PTR host definition i.e. 1.1.168.192.in-addr.arpa. IN PTR
> host.any.domain.tld.
>
> When structure in LDAP is like (everything in one subtree):
> ##########################
> dc=any,dc=domain,dc=tld
>              dc=168.192.in-addr.arpa,dc=any,dc=domain,dc=tld  (->NS,SOA
> definition)
>                                                      dc=
> 1.168.192.in-addr.arpa,dc=168.192.in-addr.arpa,dc=any,dc=domain,dc=tld
> (->NS delegation)
>
>                       dc= 1.168.192.in-addr.arpa,dc=1.168.192.in-addr.arpa,
> dc=168.192.in-addr.arpa,dc=any,dc=domain,dc=tld (SOA, NS definition)
>
>                                                                    
> dc=1.1.168.192.in-addr.arpa,dc=1.168.192.in-addr.arpa,dc=1.168.192.in-addr.
>arpa,dc=any,dc=domain,dc=tld (->PTR record)
> ##########################
> Here's problem, that AXFR of 168.192.in-addr.arpa
> has included also PTR's from subzone 1.168.192.in-addr.arpa. (so in AXFR
> list is also included 1.1.168.192.in-addr.arpa PTR record what is bad)
>
> -------
> So problem could be in 2 things IMHO:
> 1. search of AXFR-ed zone should be not "sub" but "one"   (?)
> or (hmm)
> 2. zone and subzone should be structured in ldap like (2 subtrees ->
> different for zone and subzone)->

I think I do understand your problem but I'm not sure if I already know the 
right solution. Therefore I need some help regarding how DNS delegation for 
reverse zones should work.

To my understanding, delegation of normal zones (sub.test.dom) is simple as 
you only need a SOA and a NS record for your subdomain where the NS record 
points to the name server providing records of the subdomain. Simple 
class-based partitial delegation of reverse zones should be the same, e.g. if 
you have 168.192.in-addr.arpa and want to delegate 1.168.192.in-addr.arpa, 
the 1.168.192.in-addr.arpa entry needs a SOA and a NS record pointing to the 
foreign name server.

> ###########################
> dc=any,dc=domain,dc=tld
>              dc=168.192.in-addr.arpa,dc=any,dc=domain,dc=tld  (->NS,SOA
> definition)
>                                                      dc=
> 1.168.192.in-addr.arpa,dc=168.192.in-addr.arpa,dc=any,dc=domain,dc=tld
> (->NS delegation)
>
>             dc=1.168.192.in-addr.arpa,dc=any,dc=domain,dc=tld (->NS,SOA
> definition)
>                                                      
> dc=1.1.168.192.in-addr.arpa,dc=1.168.192.in-addr.arpa,dc=any,dc=domain,dc=t
>ld (->PTR record)

OK, now the interesting part:
Looking at the SQL backends, you can't delegate the complete zone 
1.168.192.in-addr.arpa but keep records for single IPs at your side in the 
same zone. This must this be handled as separate zone, so my suggestion would 
be the second solution above.

This would work perfectly in simple mode but not in tree mode where you can't 
separate 1.1.168.192.in-addr.arpa from 1.168.192.in-addr.arpa. I don't know 
how this can be done for the tree mode at the moment.

> ###########################
> and in pdns-2.9.xx/modules/ldapbackend/ldapbackend.cc
> in LdapBackend::list_simple
> should be first filter like:
> filter = strbind( ":target:", "(&(associatedDomain=" + qesc +
> ")(SOARecord=*))", getArg( "filter-axfr" ) );
> and not
> filter = strbind( ":target:", "(associatedDomain=" + qesc + ")", getArg(
> "filter-axfr" ) );
> -> to do subsearch in base which is not subzone NS delegation but subzone
> with NS and SOA record.
>
> What do you think ? Or do you have working AXFR of zones and subzones which
> are separatly delegated ? On website is only example like
> dc=1.1,dc=168.192.in-addr.arpa,dc=...,dc=....
> what isn't universal sollution "dc=1.1" when I need separated subzones
> delegation:)

The values of the attribute "domain component" (dc) are only important in tree 
mode and in all other cases you can name them as you like. That's the reason 
I preferred not repeating the whole domain every time and that's in line with 
the intention of this attribute.


Norbert
-- 
OpenPGP public key
http://www.linuxnetworks.de/norbert.pubkey.asc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20080301/1c845e39/attachment.sig>