Re: LDAP support
On Feb 15, 2011, at 2:01 PM, Munroe Sollog wrote: I am investigating using the dlz-ldap driver to store my zone file in ldap. Before doing so, it seems that the official driver page had less than stellar things to say about the ldap driver. Is anyone using LDAP as a backend? Are you happy with the performance? Is there a future for LDAP and Bind? I played around with DLZ using OpenLDAP. (At the same time I worked with the MySQL DLZ drivers too.) I work with Macintoshes mainly and LDAP is the standard way that the Mac manages information. This seems to be a natural fit. I would tell you, BIND using LDAP over DLZ simply sucks. It is so horribly slow that it makes it unusable. Running "queryperf" against this server made you wonder if there was something really wrong with the system. I would state that BIND using an LDAP backend is a nice "proof of concept" but it does not make sense for any production system. Bill Larson___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: process of updating slave servers
On Feb 14, 2011, at 8:31 PM, Terry. wrote: > check your configure especially for: > > * notify/ also-notify/ allow-notify Thanks you all who replied, I needed the allow notify. -j > * allow-transfer > * does slave named have the permittion to write to data dir? > > Regards. > > 2011/2/15 donovan jeffrey j : >> Greetings >> >> I have a new slave server. I edited my master, incremented the serial number >> and reloaded named. The master is fine, and contains the new entry but the >> slaves are still running the previous entries. >> >> what is the basic operation of updating a slave ? >> >> I reloaded the zone with rndc and the slave pulled the zone. The serial >> number was incremented on the slave, but the old entry's were still there. >> I checked the forward and reverse records, and nothing had changed except >> the serial number. So I deleted the slave files, and pulled the zone again, >> and kick started named, everything works fine. >> I highly doubt my procedure was the correct way to do it. >> >> can someone explain to me the proper work flow for updating records on >> slaves ? >> >> TIA >> >> -j >> >> ___ >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users >> > > > > -- > Free SmartDNS Hosting: > http://DNSbed.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: migration bind8/bind9: config problems.
Firstly please get your mail client fixed. Turning comma's to "=2C" isn't needed and defeats the purpose of printed quotable which is to do the minimum changes to make the message transmitable via 7bit smtp so that the message is readable by old clients. Anything above that minimum is a bug. In message , hugo hugoo writes: > > Dear all, > > I am testing an upgrade from bind8 to bind9. > For this, I have installed bind9 in a server with the same configuration > files as present in the server running bind8. > When I start bind9, I have the following errors and the server do not sta > rt. > > Can you anyone answer the questions presnet in the log here aboive to help > me with my migration? > > Thanks in advance, > > Hugo, > > eb 15 13:13:10 dnsextcache001 named[17541]: starting BIND 9.6-ESV-R3 -c /et > c/bind/named.conf > Feb 15 13:13:10 dnsextcache001 named[17541]: built with '--prefix=/usr/lo > cal/bind-9.6-ESV-R3' > Feb 15 13:13:10 dnsextcache001 named[17541]: using up to 4096 sockets > Feb 15 13:13:10 dnsextcache001 named[17541]: loading configuration from '/e > tc/bind/named.conf' > Feb 15 13:13:10 dnsextcache001 named[17541]: /etc/bind/named.conf:17: optio > n 'fetch-glue' is obsolete > > ==> can I remove this from the configuration without any impact? Yes. It can be safely removed. > Feb 15 13:13:13 dnsextcache001 named[17541]: loading configuration: failure > Feb 15 13:13:13 dnsextcache001 named[17541]: exiting (due to fatal error) > Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc > :488832: zone 'thermote-vanhalst.com': already exists previous definition: > /etc/bind/conf/named.zones.inc:93105 > Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc > :489192: zone 'villedewavre.be': already exists previous definition: /etc/b > ind/conf/named.zones.inc:104087 > Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc > :489912: zone 'saval.be': already exists previous definition: /etc/bind/con > f/named.zones.inc:186169 > Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc > :490816: zone 'dataminercube.com': already exists previous definition: /etc > /bind/conf/named.zones.inc:384171 > Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc > :491735: zone 'cdmeerhout.be': already exists previous definition: /etc/bin > d/conf/named.zones.inc:179099 > Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc > :491745: zone 'agroservices.be': already exists previous definition: /etc/b > ind/conf/named.zones.inc:291937 > Feb 15 13:13:13 dnsextcache001 named[17541]: loading configuration: failure > Feb 15 13:13:13 dnsextcache001 named[17541]: exiting (due to fatal error) > > ==> I can remove the duplicates to allow bind9 to start (bind8 starts > even if duplicates present). > >BUT!! > > I would like to have for this point the same behaviour as bind8 as it is po > ssible that the provisioning in hte future introduces duplicates as it is t > he case in my present setup. > > Is this possible? No. Run the configuration through named-checkconf if you are worried. It will catch the duplicates before you run named. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
LDAP support
I am investigating using the dlz-ldap driver to store my zone file in ldap. Before doing so, it seems that the official driver page had less than stellar things to say about the ldap driver. Is anyone using LDAP as a backend? Are you happy with the performance? Is there a future for LDAP and Bind? -- Munroe Sollog Systems Engineer Digirati Consulting, Inc sol...@digiraticonsulting.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Typo in 9.7.3 Announcement
bsfinkel> In the posting and on the ISC release notes page on the web, bsfinkel> under "Feature Changes" - the first heading "9.7.2" should bsfinkel> read "9.7.3". No, it's correct. Those were new features in 9.7.2. 9.7.3 has a number of bug fixes but no "new" features over 9.7.2. But it's good to know someone is reading the release notes. ;) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
"external" update policy (was: BIND 9.8.0rc1 is now available.)
On 15/02/11 01:15, Mark Andrews wrote: * There is a new update-policy match type "external". This allows named to decide whether to allow a dynamic update by checking with an external daemon. Contributed by Andrew Tridgell of the Samba Project. [RT #22758] This is a useful feature (which I've just tested). However it has some rather serious flaws for certain use-cases[1]. Specifically, the data supplied to the external helper loses much of the context from the original update request. Imagine you have a zone: foo.domain.com TXT "some data" foo.domain.comA 192.168.1.10 ...and someone sends: update delete nx.domain.com update delete foo.domain.com update add www.domain.com 300 A 192.168.1.1 update add www2.domain.com 300 2001:db8::1 ...the helper will receive 4 separate external lookups: name=foo.domain.com rrtype=TXT name=foo.domain.com rrtype=A name=www.domain.com rrtype=A name=www2.domain.com rrtype= The problems I see are: * You see nothing for "nx.domain.com" * Each lookup is on a separate unix stream socket, so you don't know they're related. * There's no info about whether it's a delete or addition * Because of this, if you deny the last one, you can't know that the previous 3 didn't apply either I understand why these happen and that it might be difficult to fix, but thought I'd mention it here. [1] One of the use-cases we have in mind is logging dynamic updates by windows clients and using the external policy check to order our existing static "SQL->DNS" process to "skip" those; if a client sends an update with multiple add/deletes and we only deny one, we will erroneously mark the others to be skipped, because we lack transactional info (as well as whether it's a delete/add) Also: 1. It's normally obvious from the keyname or identity, but since it might be possible for those to conflict, the key algorithm would be useful as an explicit field. 2. The documentation says "Requests to the external daemon are sent over the UNIX-domain socket as datagrams"; this is a bit confusing at and could be reworded. The unix socket is a SOCK_STREAM socket (not a datagram socket) receiving version/len/payload frames - this took a few minutes to figure out. Maybe: "Request to the external daemon are sent over a UNIX stream socket. Request messages are formatted as follows..." ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7.3 is now available.
> > BTW, does bind-9.7's threads work well on Linux X86 platform? Yes they do, but note that threads are not enabled by default on Linux; you have to configure BIND9 with the --enable-threads option. (This requirement has probably outlived its usefulness and we should enable them by default now. We do on most other platforms.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
migration bind8/bind9: config problems.
Dear all, I am testing an upgrade from bind8 to bind9. For this, I have installed bind9 in a server with the same configuration files as present in the server running bind8. When I start bind9, I have the following errors and the server do not start. Can you anyone answer the questions presnet in the log here aboive to help me with my migration? Thanks in advance, Hugo, eb 15 13:13:10 dnsextcache001 named[17541]: starting BIND 9.6-ESV-R3 -c /etc/bind/named.conf Feb 15 13:13:10 dnsextcache001 named[17541]: built with '--prefix=/usr/local/bind-9.6-ESV-R3' Feb 15 13:13:10 dnsextcache001 named[17541]: using up to 4096 sockets Feb 15 13:13:10 dnsextcache001 named[17541]: loading configuration from '/etc/bind/named.conf' Feb 15 13:13:10 dnsextcache001 named[17541]: /etc/bind/named.conf:17: option 'fetch-glue' is obsolete ==> can I remove this from the configuration without any impact? Feb 15 13:13:11 dnsextcache001 named[17541]: /etc/bind/named.conf:30: undefined category: 'parser' Feb 15 13:13:11 dnsextcache001 named[17541]: /etc/bind/named.conf:33: undefined category: 'statistics' Feb 15 13:13:11 dnsextcache001 named[17541]: /etc/bind/named.conf:34: undefined category: 'panic' Feb 15 13:13:11 dnsextcache001 named[17541]: /etc/bind/named.conf:36: undefined category: 'ncache' Feb 15 13:13:11 dnsextcache001 named[17541]: /etc/bind/named.conf:39: undefined category: 'db' Feb 15 13:13:11 dnsextcache001 named[17541]: /etc/bind/named.conf:40: undefined category: 'eventlib' Feb 15 13:13:11 dnsextcache001 named[17541]: /etc/bind/named.conf:41: undefined category: 'packet' Feb 15 13:13:11 dnsextcache001 named[17541]: /etc/bind/named.conf:43: undefined category: 'cname' Feb 15 13:13:11 dnsextcache001 named[17541]: /etc/bind/named.conf:45: undefined category: 'os' Feb 15 13:13:11 dnsextcache001 named[17541]: /etc/bind/named.conf:46: undefined category: 'insist' Feb 15 13:13:11 dnsextcache001 named[17541]: /etc/bind/named.conf:47: undefined category: 'maintenance' Feb 15 13:13:11 dnsextcache001 named[17541]: /etc/bind/named.conf:48: undefined category: 'load' Feb 15 13:13:11 dnsextcache001 named[17541]: /etc/bind/named.conf:49: undefined category: 'response-checks' ==> I have just removed these categories from the configuration file. Feb 15 13:13:13 dnsextcache001 named[17541]: loading configuration: failure Feb 15 13:13:13 dnsextcache001 named[17541]: exiting (due to fatal error) Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc:488832: zone 'thermote-vanhalst.com': already exists previous definition: /etc/bind/conf/named.zones.inc:93105 Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc:489192: zone 'villedewavre.be': already exists previous definition: /etc/bind/conf/named.zones.inc:104087 Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc:489912: zone 'saval.be': already exists previous definition: /etc/bind/conf/named.zones.inc:186169 Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc:490816: zone 'dataminercube.com': already exists previous definition: /etc/bind/conf/named.zones.inc:384171 Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc:491735: zone 'cdmeerhout.be': already exists previous definition: /etc/bind/conf/named.zones.inc:179099 Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc:491745: zone 'agroservices.be': already exists previous definition: /etc/bind/conf/named.zones.inc:291937 Feb 15 13:13:13 dnsextcache001 named[17541]: loading configuration: failure Feb 15 13:13:13 dnsextcache001 named[17541]: exiting (due to fatal error) ==> I can remove the duplicates to allow bind9 to start (bind8 starts even if duplicates present). BUT!! I would like to have for this point the same behaviour as bind8 as it is possible that the provisioning in hte future introduces duplicates as it is the case in my present setup. Is this possible? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Typo in 9.7.3 Announcement
In the posting and on the ISC release notes page on the web, under "Feature Changes" - the first heading "9.7.2" should read "9.7.3". -- -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7.3 is now available.
* Dennis Clarke: > I would think a posix speec compliant implementation would work anywhere. BIND uses its own locking mechanisms, using machine code insertions. For fringe some platforms, they do not seem to be correct. i386 or amd64 should be fine, though. (Switching to GCC's synchronization primitives would probably be quite easy, at least if you can figure out which ordering semantics are expected. The machine code insertions already depend on GCC, after all.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: process of updating slave servers
On 2/14/2011 10:30 PM, Terry. wrote: >> slave options; >> allow-transfer { 10.1.1.2; }; > > In practical the slave doesn't have the allow-transfer option. Sure it does. Any authoritative server (master or slave) can act as the source for a zone transfer. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users