Re: [Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap
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.orig2013-10-23 09:09:47.568113243 +0200
+++ bpk2.com.db.noorigin2013-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
Re: [Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap
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!
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap
Hello! On 22.10.2013 16:26, Brendan Kearney wrote: list, i am trying to setup BIND to use the DynDB LDAP backend, and have found that the $ORIGIN directive is not used or documented for use with the backend. the use case is the for the $ORIGIN directive is to handle unqualified queries. Below is an example of what happens without the $ORIGIN directive set in a zone: [brendan@test ~]$ nslookup server 127.0.0.1 Server: 127.0.0.1 Address: 127.0.0.1#53 ** server can't find server: SERVFAIL [brendan@test ~]$ nslookup server.my-domain.com 127.0.0.1 Server: 127.0.0.1 Address: 127.0.0.1#53 Name: server.my-domain.com Address: 192.168.1.1 Could you please describe your configuration and what you are trying to achieve? I would like to see example zone file for BIND9 and description of desired outcome. Maybe that I'm wrong, but AFAIK $ORIGIN is just shorthand for use *inside* zone files. It has no effect outside zone parser: http://www.zytrax.com/books/dns/ch8/origin.html IMHO it does not affect query processing in any way. the below is the BIND Admin Reference Manual entry for the $ORIGIN directive. The $ORIGIN Directive Syntax: $ORIGIN domain-name [comment] $ORIGIN sets the domain name that will be appended to any unqualified records. When a zone is first read in there is an implicit $ORIGIN zone_name. (followed by trailing dot). The current $ORIGIN is appended to the domain specified in the $ORIGIN argument if it is not absolute. $ORIGIN example.com. WWW CNAME MAIN-SERVER is equivalent to WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM. would a Request For Enhancement be needed or should a bug be filed for this missing functionality? Please let us clarify what you are trying to achieve, then we can open RFE. Have a nice day! -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap
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. 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. 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 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. $ORIGIN . $TTL 3600 ; 1 hour bpk2.comIN SOA server.bpk2.com. root.server.bpk2.com. ( 21684 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 3600 ; minimum (1 hour) ) NS vpn.bpk2.com. NS server.bpk2.com. $ORIGIN bpk2.com. $TTL 600; 10 minutes _kerberos TXT BPK2.COM $TTL 5 ; 5 seconds cache A 192.168.25.1 A 192.168.50.1 ceton A 192.168.200.1 $TTL 3600 ; 1 hour desktop A 192.168.1.60 $TTL 1800 ; 30 minutes TXT 004f797684e9ec50c37966ab6377f6e5c6 $TTL 3600 ; 1 hour dhcp01 CNAME server dhcp02 CNAME vpn edge1037A 192.168.3.1 TXT 31f8a6da151fb3fc048a6e3dbcd4099896 HP001560497B44 CNAME printer inspire A 192.168.2.145 $TTL 1800 ; 30 minutes TXT 3105220f898df9aa1cecba75583223a0e2 $TTL 3600 ; 1 hour iphone A 192.168.2.146 TXT 318d91a7366c7a0cbd8ac4a8cf5f11f2f8 ipsec A 192.168.52.1 $TTL 600; 10 minutes kerberosA 192.168.25.1 A 192.168.50.1 $TTL 3600 ; 1 hour laptop A 192.168.1.139 $TTL 1800 ; 30 minutes TXT 002a031452f258ef236a2463b272372ad6 $TTL 3600 ; 1 hour ldapA 192.168.37.3 ldap-master CNAME server ldap1 CNAME server ldap2 CNAME vpn modem A 192.168.100.1 music CNAME desktop ncsiCNAME server ns01CNAME vpn ns02CNAME server ntp CNAME vpn printer A 192.168.1.3 TXT 316f7731238b38ada102f07b426eb98a95 $TTL 600; 10 minutes proxy A 192.168.37.1 proxy1 CNAME server proxy2 CNAME vpn router CNAME router-vlan254 $TTL 3600 ; 1 hour router-ipmi A 192.168.253.3 $TTL 600; 10 minutes router-vlan1A 192.168.1.254 router-vlan2A 192.168.2.254 router-vlan25 A 192.168.25.254 router-vlan253 A 192.168.253.254 router-vlan254 A 192.168.254.254 router-vlan3A 192.168.3.254 router-vlan37 A 192.168.37.254 router-vlan50 A 192.168.50.254 router-vlan52 A 192.168.52.254 server A 192.168.25.1 server-ipmi A 192.168.253.1 server-old A 192.168.1.1 switch A 192.168.254.253 wpad.tcpTXT service: wpad:!http://www.bpk2.com:80/wpad.dat; SRV 0 0 80 server $TTL 3600 ; 1 hour testA 192.168.1.169 $TTL 1800 ; 30 minutes TXT 00b6f6a38a5caaab7be5bdc35d2d3e7acc $TTL 600; 10 minutes tproxy CNAME server vpn A 192.168.50.1 vpn-ipmiA 192.168.253.2 wifi-g A 192.168.1.253 wifi-guest A 192.168.3.253 wifi-n A
