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

[Brendan Kearney]

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

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

> > 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
$ORIGIN directive is written into RFC, why is it electively being
dropped, resulting in a broken implementation because of the lack of
compliance?

> $ 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!
>