[Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap

[Petr Spacek]

On 23.10.2013 23:08, Brendan Kearney wrote:
>> Do you plan to use FreeIPA command line interface or not?
>>
>> With FreeIPA, you can create equivalent records with this set of commands:
>> $ ipa dnszone-add bpk2.com
>> $ ipa dnsrecord-add bpk2.com _kerberos --txt-rec=...
>> etc.
>>
>> Those commands allow you to create almost equivalent data in LDAP. This
>> doesn't work for you?
>>
>> Please note that dnsrecord-add command contains zone name (as the first
>> argument), so the FQDN can be constructed from the first and second argument.
>
> i am using bind-dyndb-ldap without FreeIPA, or 389.  It is on Fedora,
> with  OpenLDAP and a bunch of steps to get it working.  i am using
> phpLdapAdmin to administrate the ldap instance and have created the
> needed configs in ldap, using the existing sample ldif as a guide.
>
>>
>> DNS zone is represented by LDAP object which contains all other named in the zone:
>> idnsname=bkp2.com,cn=dns,dc=ipa,dc=test
>>
>> Each name inside particular zone is represented by own LDAP object:
>> idnsname=_kerberos, idnsname=bkp2.com,cn=dns,dc=ipa,dc=test
>>
>> As a result, FQDN can be constructed for each relative name in the zone simply
>> by concatenating second and first idnsname components.
>>
>> Is it now clearer why bind-dyndb-ldap don't have equivalent of $ORIGIN?
>
> no.  you say that the FQDN can be constructed by stinging together 2 of
> the values in the DN, but neither bind, nor the bind-dyndb-ldap
> "plug-in" are doing that.

In that case it is a bug.

Please be so kind and provide us with all the information as described at 
https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting#a3.Whatweneedtoknow

>>> attached is my forward zone (frozen before copying data, so that the jnl
>>> entries were written out).
>>>
>>> the desired outcome is to have zones configured so that unqualified
>>> queries are looked up locally and return properly, if appropriate,
>>> before being forwarded to any forwarders or via the hints to the roots
>>> or whatever is configured to be done with a record that does not have a
>>> locally authoritative entry.
>>
>> AFAIK 'unqualified' names are purely client-side thing. I belive that all
>> names have to be expanded to FQDN *before* the query is sent to any DNS
>> server. (See search directive in /etc/resolv.conf.)
>>
>
> and there are no conceivable scenarios where an unqualified query could
> ever get to the bind server?  regardless of opinions on how
> frequent/infrequent it could happen, the fact is that this is an
> entirely legitimate scenario that improperly fails with an error.

DNS server blindly follows algorithm described in
http://tools.ietf.org/html/rfc6672#section-3.2
to construct the answer.

If you want to resolve unqualified name (e.g. QNAME = 'server.') then the name 
in question has to be present in 'nearest ancestor to QNAME' (see 2nd point of 
the server's algorithm in RFC 6672).

There is only one possible 'nearest ancestor' for unqualified names - the root.

>>> while zytrax does have good articles, the reference i provided is
>>> directly out of the bind admin guide, and likely a more authoritative
>>> voice on the subject.
>>
>> I agree. Please note that both sources say the same information, just in other
>> words.
>>
>>> i have validated that when no $ORIGIN directive is set, a query using
>>> the short name will fail when looked up locally, and will either be
>>> forwarded or recursively searched for.  the examples i provided go
>>> against bind+bind-dyndb-ldap, and the short name query fails.  doing the
>>> same lookups against my straight bind instance, using the attached zone
>>> file, gives authoritative responses for both short and FQDN queries.
>>
>> I belive that your zone file will be perfectly functional if you remove origin
>> completely. You will have to replace name for SOA record.
>
> it does not matter what will or will not work with my zones.  what i am
> trying to account for is lookups failing against bind when using the
> bind-dyndb-ldap backend and a short name is specified.  since the

We will help you debug the problem, but we need to see exact configuration, 
parameters of the query, logs and possibly tcpdump.

> $ORIGIN directive is written into RFC, why is it electively being
> dropped, resulting in a broken implementation because of the lack of
> compliance?

I wasn't 100% accurate in previous post about this aspect. Technically, 
$ORIGIN is stored in LDAP - it is the second idnsname component of the DN (for 
names under zone apex).

Examples:
- $ORIGIN for zone itself is implicitly '.':
idnsname=zone-name, cn=dns
Resulting DNS name: zone-name.

- $ORIGIN for any name under zone apex is the second idnsname component:
idnsname=name, idnsname=origin, cn=dns
Resulting DNS name: name.origin.

I hope that this explains how the LDAP schema represents DNS data.

>> $ diff -u bpk2.com.db.orig bpk2.com.db.noorigin
>> --- bpk2.com.db.orig	2013-10-23 09:09:47.568113243 +0200
>> +++ bpk2.com.db.noorigin	2013-10-23 09:10:09.347112464 +0200
>> @@ -1,6 +1,5 @@
>> -$ORIGIN .
>>    $TTL 3600	; 1 hour
>> -bpk2.com		IN SOA	server.bpk2.com. root.server.bpk2.com. (
>> +@			IN SOA	server.bpk2.com. root.server.bpk2.com. (
>>    				21684      ; serial
>>    				10800      ; refresh (3 hours)
>>    				3600       ; retry (1 hour)
>> @@ -9,7 +8,6 @@
>>    				)
>>    			NS	vpn.bpk2.com.
>>    			NS	server.bpk2.com.
>> -$ORIGIN bpk2.com.
>>    $TTL 600	; 10 minutes
>>    _kerberos		TXT	"BPK2.COM"
>>    $TTL 5	; 5 seconds
>>
>>
>> I assume that your zone definition in named.conf looks like:
>>           zone "bpk2.com." IN {
>>                   type master;
>>                   file "bpk2.com.db";
>>           };
>>
>> As a result, default origin "bpk2.com." is appended to all names in zone file
>> - and that is it.
>>
>> Do not forget to bump serial and check server logs if the new zone file was
>> loaded correctly ...
>>
>> Have a nice day!

-- 
Petr^2 Spacek