Hello,
On 22.10.2013 22:24, Brendan Kearney wrote:
my config uses bind and bind-dyndb-ldap to host zone data in ldap. i am
trying to achieve the equivalent directives and configuration of bind
+bind-dyndb-ldap that i have in straight bind.
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.
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?
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.)
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.
$ 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
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
