Re: bind 192.168.1.1 to all interfaces
Eugen Konkov yandex.ru> writes: > ... > So in my vlan I have two DHCP servers. One is mine and > second is on that router. Some users get wrong IPs from that router. > ... > Or s there any other method to prevent such ilegal DHCP servers on LAN? http://www.tcpipguide.com/free/t_DHCPSecurityIssues.htm jb ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: bind 192.168.1.1 to all interfaces
Le Sun, 23 Dec 2012 14:17:47 +0200, Eugen Konkov a écrit : Hello, > Or s there any other method to prevent such ilegal DHCP servers on > LAN? At work we use "dhcp_probe" http://www.net.princeton.edu/software/dhcp_probe/ It works quite fine, when someone plug a dhcp server it is detected and we shutdown the switch port. I don't know if it runs on FreeBSD, it runs on Centos 6. Regards. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND - slaving the root zone and signature expired
On 25 October 2012 18:55, Damien Fleuriot wrote: > On 25 October 2012 18:33, Warren Block wrote: >> On Thu, 25 Oct 2012, Damien Fleuriot wrote: >> >>> Anyone else experienced this problem today ? >>> >>> We slave the root zone and have received "signature expired" errors. >> >> >> Found this: >> >> https://lists.dns-oarc.net/pipermail/dns-operations/2011-March/007116.html >> >> which leads to this: >> >> http://in-addr-transition.icann.org/ > > > > Hi Warren and thanks for your reply, > > > I've dug around some more and identified the problem we've been having. > > > > Apparently, from a given netblock, we can't AXFR the "." and "arpa" > zones anymore with F.ROOT-SERVERS.NET. > We can from some other boxes. > I suspect we might have been firewalled or something, although we > don't query them very often , but that's beyond the point. > > > I've now transitioned all our PF boxes to slave from > "xfr.lax.dns.icann.org" and "xfr.cjr.dns.icann.org" as per the > documentation found in /etc/namedb/named.conf > > What bothers me is that the commented lines from named.conf say to use > the ICANN XFR servers, while the actual commented configuration uses > F.ROOT-SERVERS.NET > > > > > See below a freshly SVNup'd copy on 10.0: > > % svn info named.conf > Path: named.conf > Name: named.conf > Working Copy Root Path: /data/freebsd/src/head > URL: svn://svn.freebsd.org/base/head/etc/namedb/named.conf > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 242082 > Node Kind: file > Schedule: normal > Last Changed Author: uqs > Last Changed Rev: 229783 > Last Changed Date: 2012-01-07 16:10:32 + (Sat, 07 Jan 2012) > Text Last Updated: 2012-09-01 11:43:31 + (Sat, 01 Sep 2012) > Checksum: 598add209c192aac1dc4d973ce31922dff8b93c9 > > > I SVNup'd it just today, and yet: > > === > As documented at http://dns.icann.org/services/axfr/ these zones: > "." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and ROOT-SERVERS.NET > are available for AXFR from these servers on IPv4 and IPv6: > xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org > */ > /* > zone "." { > type slave; > file "/etc/namedb/slave/root.slave"; > masters { > 192.5.5.241;// F.ROOT-SERVERS.NET. > }; > notify no; > }; > === > > > > > I'm going to file a PR with a small diff to use the ICANN's XFR > servers instead of F. > > > > Thanks for your feedback regardless :) If anyone cares to take it, filed as conf/173077 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND - slaving the root zone and signature expired
On 25 October 2012 18:33, Warren Block wrote: > On Thu, 25 Oct 2012, Damien Fleuriot wrote: > >> Anyone else experienced this problem today ? >> >> We slave the root zone and have received "signature expired" errors. > > > Found this: > > https://lists.dns-oarc.net/pipermail/dns-operations/2011-March/007116.html > > which leads to this: > > http://in-addr-transition.icann.org/ Hi Warren and thanks for your reply, I've dug around some more and identified the problem we've been having. Apparently, from a given netblock, we can't AXFR the "." and "arpa" zones anymore with F.ROOT-SERVERS.NET. We can from some other boxes. I suspect we might have been firewalled or something, although we don't query them very often , but that's beyond the point. I've now transitioned all our PF boxes to slave from "xfr.lax.dns.icann.org" and "xfr.cjr.dns.icann.org" as per the documentation found in /etc/namedb/named.conf What bothers me is that the commented lines from named.conf say to use the ICANN XFR servers, while the actual commented configuration uses F.ROOT-SERVERS.NET See below a freshly SVNup'd copy on 10.0: % svn info named.conf Path: named.conf Name: named.conf Working Copy Root Path: /data/freebsd/src/head URL: svn://svn.freebsd.org/base/head/etc/namedb/named.conf Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 242082 Node Kind: file Schedule: normal Last Changed Author: uqs Last Changed Rev: 229783 Last Changed Date: 2012-01-07 16:10:32 + (Sat, 07 Jan 2012) Text Last Updated: 2012-09-01 11:43:31 + (Sat, 01 Sep 2012) Checksum: 598add209c192aac1dc4d973ce31922dff8b93c9 I SVNup'd it just today, and yet: === As documented at http://dns.icann.org/services/axfr/ these zones: "." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and ROOT-SERVERS.NET are available for AXFR from these servers on IPv4 and IPv6: xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org */ /* zone "." { type slave; file "/etc/namedb/slave/root.slave"; masters { 192.5.5.241;// F.ROOT-SERVERS.NET. }; notify no; }; === I'm going to file a PR with a small diff to use the ICANN's XFR servers instead of F. Thanks for your feedback regardless :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND - slaving the root zone and signature expired
On Thu, 25 Oct 2012, Damien Fleuriot wrote: Anyone else experienced this problem today ? We slave the root zone and have received "signature expired" errors. Found this: https://lists.dns-oarc.net/pipermail/dns-operations/2011-March/007116.html which leads to this: http://in-addr-transition.icann.org/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND and LDAP support
Hello, thanks for replying. Regarding building BIND, are you sure the setting should go in make.conf and not src.conf - here is the relevant text from the src.conf man page: "WITHOUT_BIND Setting this variable will prevent any part of BIND from being built. When set, it also enforces the following options: WITHOUT_BIND_DNSSEC WITHOUT_BIND_ETC WITHOUT_BIND_LIBS_LWRES WITHOUT_BIND_MTREE WITHOUT_BIND_NAMED WITHOUT_BIND_UTILS" Thankyou for the web link for the DLZ driver however I had already seen it; my confusion is what is the difference between BIND built with the DLZ LDAP driver and BIND built with the 'sdb' (simplified database interface) option as specified in http://bind9-ldap.bayour.com/ and as built in the dns/bind97-sdb port? If these are two different ways for BIND to use LDAP, which one should I choose? Thanks. On 7 December 2011 20:04, Damien Fleuriot wrote: > On 12/7/11 8:15 PM, Kernel Panic wrote: >> Apologies if this is not the appropriate list but I can't seem to find >> one pertaining to the installation and configuration of BIND. I posted >> the following message on the FreeBSD forums a few weeks back but have >> had no replies, so I thought I'd try here on the lists: >> >> System: FreeBSD 8.2-RELEASE 64-bit >> >> Hello, I'm going to attempt to install the latest BIND port >> (dns/bind98) and have a couple of questions about the available >> install options: >> >> WITH_REPLACE_BASE=true >> >> Does this delete the base BIND version and if so would I need to edit >> src.conf to tell the compiler not to reinstall base BIND when I do a >> buildworld cycle? >> >> WITH_DLZ_LDAP=true >> >> Does this actually enable LDAP backend support or is it something >> else? The reason I ask is because there seems to be a separate port >> for BIND LDAP support but it's for an older version of BIND >> (dns/bind97-sdb) >> >> Thanks for any assistance. > > > Hi, > > > Regarding WITH_REPLACE_BASE, yes, this will make "make install" install > the files in place of the base system's ones, as opposed to in /usr/local/ . > > > If you do this, you will indeed want to add the following to your > /etc/make.conf : > NO_BIND= true > > > Regarding your LDAP question, I'm still at work and it's 9PM so I'm a > bit in a rush, but a quick google search turned up the following: > http://bind-dlz.sourceforge.net/ldap_driver.html > > > Regards, > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND and LDAP support
On 12/7/11 8:15 PM, Kernel Panic wrote: > Apologies if this is not the appropriate list but I can't seem to find > one pertaining to the installation and configuration of BIND. I posted > the following message on the FreeBSD forums a few weeks back but have > had no replies, so I thought I'd try here on the lists: > > System: FreeBSD 8.2-RELEASE 64-bit > > Hello, I'm going to attempt to install the latest BIND port > (dns/bind98) and have a couple of questions about the available > install options: > > WITH_REPLACE_BASE=true > > Does this delete the base BIND version and if so would I need to edit > src.conf to tell the compiler not to reinstall base BIND when I do a > buildworld cycle? > > WITH_DLZ_LDAP=true > > Does this actually enable LDAP backend support or is it something > else? The reason I ask is because there seems to be a separate port > for BIND LDAP support but it's for an older version of BIND > (dns/bind97-sdb) > > Thanks for any assistance. Hi, Regarding WITH_REPLACE_BASE, yes, this will make "make install" install the files in place of the base system's ones, as opposed to in /usr/local/ . If you do this, you will indeed want to add the following to your /etc/make.conf : NO_BIND= true Regarding your LDAP question, I'm still at work and it's 9PM so I'm a bit in a rush, but a quick google search turned up the following: http://bind-dlz.sourceforge.net/ldap_driver.html Regards, ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND 9.8.1-P1 with OpenSSL 1.0.0 issues..
On 23/11/2011 14:01, Jerry wrote: > On Wed, 23 Nov 2011 13:18:45 + > Matthew Seaman articulated: > >> I've been using the attached patch with the dns/bind98 port and >> openssl-1.0.x from ports for months. This disables using the GOST >> cipher plugins -- which is no big deal as far as I'm concerned. GOST >> ciphers are only supplied as plugin modules unlike all other ciphers >> in openssl, which is a new thing with version 1.0.0 in ports. It's >> that libgost.so plugin shlib not playing well with chroot that >> apparently causes named to crash. > > Mathew, has anyone filed a PR either here or upstream regarding this > phenomena? I sent my patch to Doug Barton (bind maintainer in src/ports) but he didn't accept it. Discussions I've seen around this are that the OpenSSL guys say that it's not a bug from their side, and that bind is doing it wrong. I believe the ISC guys are aware but I don't know if they have a fix in the works or not. Possibly some advanced combination of LDFLAGS at compile-time might sort things, but I really have no idea. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: BIND 9.8.1-P1 with OpenSSL 1.0.0 issues..
On Wed, 23 Nov 2011 13:18:45 + Matthew Seaman articulated: > I've been using the attached patch with the dns/bind98 port and > openssl-1.0.x from ports for months. This disables using the GOST > cipher plugins -- which is no big deal as far as I'm concerned. GOST > ciphers are only supplied as plugin modules unlike all other ciphers > in openssl, which is a new thing with version 1.0.0 in ports. It's > that libgost.so plugin shlib not playing well with chroot that > apparently causes named to crash. Mathew, has anyone filed a PR either here or upstream regarding this phenomena? -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND 9.8.1-P1 with OpenSSL 1.0.0 issues..
On Wed, November 23, 2011 08:18, Matthew Seaman wrote: > I've been using the attached patch with the dns/bind98 port and > openssl-1.0.x from ports for months. This disables using the GOST > cipher plugins -- which is no big deal as far as I'm concerned. GOST > ciphers are only supplied as plugin modules unlike all other ciphers in > openssl, which is a new thing with version 1.0.0 in ports. It's that > libgost.so plugin shlib not playing well with chroot that apparently > causes named to crash. > > Cheers, > > Matthew > > -- > Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard > Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate > JID: matt...@infracaninophile.co.uk Kent, CT11 9PW > You, sir, are correct about the chroot. Bind 9.8.1 and OpenSSL 1.0.0 don't play nicely in a chroot environment. This also isn't limited to FreeBSD, as I experienced the problem on Solaris 10. James ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND 9.8.1-P1 with OpenSSL 1.0.0 issues..
On 23/11/2011 12:53, Howard Leadmon wrote: > I just ran through on one of my older FreeBSD servers, and updated from > BIND 9.8.1 to 9.8.1-P1 to get the security patches for BIND online, and > after doing this bind crashes. > > I am seeing: > > > Nov 23 06:35:19 named[24537]: starting BIND 9.8.1-P1 -u bind -t /var/named > -u bind > Nov 23 06:35:19 named[24537]: built with '--localstatedir=/var' > '--disable-linux-caps' '--disable-symtable' '--with-randomdev=/dev/random' > '--with-openssl=/usr/local' '--with-libxml2=/usr/local' > '--with-idn=/usr/local' '--with-libiconv=/usr/local' > 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-ipv6' '--enable-threads' > '--sysconfdir=/etc/namedb' '--prefix=/usr' '--mandir=/usr/share/man' > '--infodir=/usr/share/info/' '--build=i386-portbld-freebsd6.4' > 'build_alias=i386-portbld-freebsd6.4' 'CC=cc' 'CFLAGS=-O2 > -fno-strict-aliasing -pipe' 'LDFLAGS= -rpath=/usr/local/lib' 'CPPFLAGS=' > 'CPP=cpp' 'CXX=c++' 'CXXFLAGS=-O2 -fno-strict-aliasing -pipe' > Nov 23 06:35:19 named[24537]: found 4 CPUs, using 4 worker threads > Nov 23 06:35:19 named[24537]: using up to 4096 sockets > Nov 23 06:35:19 named[24537]: initializing DST: openssl failure > Nov 23 06:35:19 named[24537]: exiting (due to fatal error) > > > Now as I knew my this older machine (on my hitlist to be upgraded) and the > supplied OpenSSL had issues of it's own, I also installed the current > OpenSSL from the ports to use, which BIND is built against.After doing > the update to the -P1 version, I now find that when trying to start it dies > with the above error. I've been using the attached patch with the dns/bind98 port and openssl-1.0.x from ports for months. This disables using the GOST cipher plugins -- which is no big deal as far as I'm concerned. GOST ciphers are only supplied as plugin modules unlike all other ciphers in openssl, which is a new thing with version 1.0.0 in ports. It's that libgost.so plugin shlib not playing well with chroot that apparently causes named to crash. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW --- Makefile.orig 2011-05-05 22:40:37.198878075 +0100 +++ Makefile2011-05-05 22:46:57.116962017 +0100 @@ -209,6 +209,11 @@ ${WRKSRC}/bin/named/Makefile.in.Dist > \ ${WRKSRC}/bin/named/Makefile.in +.if defined(WITH_OPENSSL_PORT) +post-configure: + ${SED} -i~ -e 's:^#define HAVE_OPENSSL_GOST.*:/* #undef HAVE_OPENSSL_GOST */:' ${WRKSRC}/config.h +.endif + PKGMESSAGE=${.CURDIR}/../bind97/pkg-message PKGINSTALL=${.CURDIR}/../bind97/pkg-install post-install: signature.asc Description: OpenPGP digital signature
Re: BIND: could not configure root hints from 'named.root': file not found
Krad, Thank you for the tip. I've changed the "." to the correct value. Matthew On 1 October 2010 21:16, CyberLeo Kitsana wrote: On 10/01/2010 12:52 PM, Matthew wrote: I would be grateful for any pointers on how to resolve this. I suspect the error message may not be exactly descriptive of whats happening. Kinda. Here's a few points to keep in mind when working with bind in FreeBSD: * By default, named runs in a chroot jail rooted at /var/named/. * For security reasons, named cannot write to anything in that tree, except the dynamic, slave, and working directories. * named uses its current working directory to resolve relative pathnames in the configuration file. * With a recent change to ISC Bind 9, named started complaining if it couldn't write to its current working directory. At the time, this was (chroot)/etc/namedb/; this was subsequently changed to (chroot)/etc/namedb/working/ to make named happy without compromising security. When the working directory for named was (chroot)/etc/namedb/, everything was peachy. Since this was changed, relative pathnames no longer work as expected because the reference point is different. The easiest solution is to alter your configuration file to include only absolute pathnames, relative to the root of the jail. The default named config file (in /var/named/etc/namedb/named.conf) is an excellent source of examples for this. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net Furry Peace! - http://.fur.com/peace/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to " freebsd-questions-unsubscr...@freebsd.org" Hmm, options { directory"."; that doesnt look ideal. Not sure if you are meaning to do that but put an explicit direcorty in eg /etc/namedb. Otherwise it will be looking in whatever current directory you are in at that time. The main named.conf will be found as its supplied via a cli switch by the rc script. However all subsequent files will come from the current dir ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND: could not configure root hints from 'named.root': file not found
CyberLeo Kitsana, Thank you so much for the history and evolution on Bind expected directory structures. It enabled me to jump through that tough spot. Thanks again, Matthew On 10/01/2010 12:52 PM, Matthew wrote: I would be grateful for any pointers on how to resolve this. I suspect the error message may not be exactly descriptive of whats happening. Kinda. Here's a few points to keep in mind when working with bind in FreeBSD: * By default, named runs in a chroot jail rooted at /var/named/. * For security reasons, named cannot write to anything in that tree, except the dynamic, slave, and working directories. * named uses its current working directory to resolve relative pathnames in the configuration file. * With a recent change to ISC Bind 9, named started complaining if it couldn't write to its current working directory. At the time, this was (chroot)/etc/namedb/; this was subsequently changed to (chroot)/etc/namedb/working/ to make named happy without compromising security. When the working directory for named was (chroot)/etc/namedb/, everything was peachy. Since this was changed, relative pathnames no longer work as expected because the reference point is different. The easiest solution is to alter your configuration file to include only absolute pathnames, relative to the root of the jail. The default named config file (in /var/named/etc/namedb/named.conf) is an excellent source of examples for this. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND: could not configure root hints from 'named.root': file not found
On 1 October 2010 21:16, CyberLeo Kitsana wrote: > On 10/01/2010 12:52 PM, Matthew wrote: > > I would be grateful for any pointers on how to resolve this. I suspect > > the error message may not be exactly descriptive of whats happening. > > Kinda. > > Here's a few points to keep in mind when working with bind in FreeBSD: > > * By default, named runs in a chroot jail rooted at /var/named/. > > * For security reasons, named cannot write to anything in that tree, > except the dynamic, slave, and working directories. > > * named uses its current working directory to resolve relative pathnames > in the configuration file. > > * With a recent change to ISC Bind 9, named started complaining if it > couldn't write to its current working directory. At the time, this was > (chroot)/etc/namedb/; this was subsequently changed to > (chroot)/etc/namedb/working/ to make named happy without compromising > security. > > When the working directory for named was (chroot)/etc/namedb/, > everything was peachy. Since this was changed, relative pathnames no > longer work as expected because the reference point is different. The > easiest solution is to alter your configuration file to include only > absolute pathnames, relative to the root of the jail. > > The default named config file (in /var/named/etc/namedb/named.conf) is > an excellent source of examples for this. > > -- > Fuzzy love, > -CyberLeo > Technical Administrator > CyberLeo.Net Webhosting > http://www.CyberLeo.Net > > > Furry Peace! - http://.fur.com/peace/ > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscr...@freebsd.org" > Hmm, options { directory"."; that doesnt look ideal. Not sure if you are meaning to do that but put an explicit direcorty in eg /etc/namedb. Otherwise it will be looking in whatever current directory you are in at that time. The main named.conf will be found as its supplied via a cli switch by the rc script. However all subsequent files will come from the current dir ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND: could not configure root hints from 'named.root': file not found
On 10/01/2010 12:52 PM, Matthew wrote: > I would be grateful for any pointers on how to resolve this. I suspect > the error message may not be exactly descriptive of whats happening. Kinda. Here's a few points to keep in mind when working with bind in FreeBSD: * By default, named runs in a chroot jail rooted at /var/named/. * For security reasons, named cannot write to anything in that tree, except the dynamic, slave, and working directories. * named uses its current working directory to resolve relative pathnames in the configuration file. * With a recent change to ISC Bind 9, named started complaining if it couldn't write to its current working directory. At the time, this was (chroot)/etc/namedb/; this was subsequently changed to (chroot)/etc/namedb/working/ to make named happy without compromising security. When the working directory for named was (chroot)/etc/namedb/, everything was peachy. Since this was changed, relative pathnames no longer work as expected because the reference point is different. The easiest solution is to alter your configuration file to include only absolute pathnames, relative to the root of the jail. The default named config file (in /var/named/etc/namedb/named.conf) is an excellent source of examples for this. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net Furry Peace! - http://.fur.com/peace/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND Refusing to Resolve for External Hosts
In freebsd-questions Digest, Vol 317, Issue 13, Message: 14 On Sat, 3 Jul 2010 14:20:01 -0700 Chris Maness wrote: > Ok, it is working for the local net now, but it is no longer working > as an authoritative server for my zones. > > Here is the current config: > > // $FreeBSD: src/etc/namedb/named.conf,v 1.26.2.2.2.1 2008/11/25 > 02:59:29 kensmith Exp $ > // > // Refer to the named.conf(5) and named(8) man pages, and the documentation > // in /usr/share/doc/bind9 for more details. Indeed, the ARM be deep and wide, but pretty well essential reading .. [..] > // Set up an ACL called our-nets. Replace this with the real IP numbers. > > acl our-nets { 192.168.1.0/24; 76.238.148.145/24; 127.0.0.1; }; > > options { > // Relative to the chroot directory, if any > directory "/etc/namedb"; > pid-file"/var/run/named/pid"; > dump-file "/var/dump/named_dump.db"; > statistics-file "/var/stats/named.stats"; > allow-transfer { > 76.238.148.146; }; > allow-query { our-nets; }; > allow-recursion { our-nets; }; > }; What Matthew said, of course .. just to add that: Anything set in options is global, so here 'allow-query { our-nets; };' is why you later found the need, in Message: 15 :) [..] > Ahhh, I see I need to add: > > allow-query { any; }; > > to my authoritative zones. > > Thanks it all works now. > > Chris Maness > > > p.s. So was this a change in the default behavior of BIND over the > years? Because I don't think my named.conf has been changed, and this > used to work for any hosts. I gather you didn't have that acl limiting queries to our-net before .. and yes bind is always on the move, keeping ahead of the moving badguys. cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND Refusing to Resolve for External Hosts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/07/2010 22:29:46, Chris Maness wrote: > Ahhh, I see I need to add: > > allow-query { any; }; > > to my authoritative zones. > > Thanks it all works now. Great. > p.s. So was this a change in the default behavior of BIND over the > years? Because I don't think my named.conf has been changed, and this > used to work for any hosts. The built-in access control rules have evolved over time, certainly. However, this hasn't changed since BIND 9.6 was released, and possibly longer than that. RELENG_8 and above have contained BIND 9.6.x from the point where the branch was created, but RELENG_7 contains BIND 9.4.x -- so if you've done an upgrade from 7.x to 8.x recently it might explain your experiences. The pre-canned configuration that comes with FreeBSD is suitable for use as a localhost-only recursive resolver: if you want to serve a whole network of machines or add authoritative data then you will need to modify it or craft your own named.conf, an important part of which is setting up ACLs to control what you will serve to who. This is a very useful reference: http://www.cymru.com/Documents/secure-bind-template.html Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwwG9kACgkQ8Mjk52CukIyPdwCeKKNIRAl3xfGRlyRovx4tMu/f flcAn1aoYlhHv1VO4hCrLFKCyBGG8N/R =3N80 -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND Refusing to Resolve for External Hosts
Ahhh, I see I need to add: allow-query { any; }; to my authoritative zones. Thanks it all works now. Chris Maness p.s. So was this a change in the default behavior of BIND over the years? Because I don't think my named.conf has been changed, and this used to work for any hosts. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND Refusing to Resolve for External Hosts
Ok, it is working for the local net now, but it is no longer working as an authoritative server for my zones. Here is the current config: // $FreeBSD: src/etc/namedb/named.conf,v 1.26.2.2.2.1 2008/11/25 02:59:29 kensmith Exp $ // // Refer to the named.conf(5) and named(8) man pages, and the documentation // in /usr/share/doc/bind9 for more details. // // If you are going to set up an authoritative server, make sure you // understand the hairy details of how DNS works. Even with // simple mistakes, you can break connectivity for affected parties, // or cause huge amounts of useless Internet traffic. // Set up an ACL called our-nets. Replace this with the real IP numbers. acl our-nets { 192.168.1.0/24; 76.238.148.145/24; 127.0.0.1; }; options { // Relative to the chroot directory, if any directory "/etc/namedb"; pid-file"/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; allow-transfer { 76.238.148.146; }; allow-query { our-nets; }; allow-recursion { our-nets; }; }; // If named is being used only as a local resolver, this is a safe default. // For named to be accessible to the network, comment this option, specify // the proper IP address, or delete this option. // listen-on { 127.0.0.1; }; // If you have IPv6 enabled on this system, uncomment this option for // use as a local resolver. To give access to the network, specify // an IPv6 address, or the keyword "any". // listen-on-v6{ ::1; }; // These zones are already covered by the empty zones listed below. // If you remove the related empty zones below, comment these lines out. /* disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; */ // In addition to the "forwarders" clause, you can force your name // server to never initiate queries of its own, but always ask its // forwarders only, by enabling the following line: // // forward only; // If you've got a DNS server around at your upstream provider, enter // its IP address here, and enable the line below. This will make you // benefit from its cache, thus reduce overall DNS traffic in the Internet. /* forwarders { 127.0.0.1; }; */ /* Modern versions of BIND use a random UDP port for each outgoing query by default in order to dramatically reduce the possibility of cache poisoning. All users are strongly encouraged to utilize this feature, and to configure their firewalls to accommodate it. AS A LAST RESORT in order to get around a restrictive firewall policy you can try enabling the option below. Use of this option will significantly reduce your ability to withstand cache poisoning attacks, and should be avoided if at all possible. Replace N in the example with a number between 49160 and 65530. */ // query-source address * port N; // If you enable a local name server, don't forget to enter 127.0.0.1 // first in your /etc/resolv.conf so this server will be queried. // Also, make sure to enable it in /etc/rc.conf. // The traditional root hints mechanism. Use this, OR the slave zones below. zone "." { type hint; file "named.root"; }; /* Slaving the following zones from the root name servers has some significant advantages: 1. Faster local resolution for your users 2. No spurious traffic will be sent from your network to the roots 3. Greater resilience to any potential root server failure/DDoS On the other hand, this method requires more monitoring than the hints file to be sure that an unexpected failure mode has not incapacitated your server. Name servers that are serving a lot of clients will benefit more from this approach than individual hosts. Use with caution. To use this mechanism, uncomment the entries below, and comment the hint zone above. */ /* zone "." { type slave; file "slave/root.slave"; masters { 192.5.5.241;// F.ROOT-SERVERS.NET. }; notify no; }; zone "0.0.127.IN-ADDR.ARPA" { type master; file "master/localhost.rev"; }; zone "in-addr.arpa" { type slave; file "slave/in-addr.arpa.slave"; masters { 192.5.5.241;// F.ROOT-SERVERS.NET. }; notify no; }; */ /* Serving the following zones locally will prevent any queries for these zones leaving your network and going to the root name servers. This has two significant advantages: 1. Faster local resolution for your users
Re: BIND Refusing to Resolve for External Hosts
On Sat, Jul 3, 2010 at 12:52 PM, Matthew Seaman wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03/07/2010 20:28:27, Chris Maness wrote: >> Including the line: >> >> acl public-nets { 127.0.0.1; ::1; } > ^ > You need a semi-colon here __| I am on gmail with variable width font. I am not sure exactly where I need the semi colon. > > Just defining the acl won't do a great deal on its own -- you need to > add it to an allow-recursion {}; or similar block. > Sorry, Matt. I haven't had to mess with the configuration file in 10 years. Everything just worked until recently (probably the upgrade). I am running a small Web/DNS/Mail server in my house. I like using a local recursive server as it has been faster than the alternatives in the past. Currently, my local net is using the DSL router as its upstream DNS. So without rambling too much. I am a bit simple at this stuff, and a little confused. I could switch to another DNS server, but for academic purposes, I want to learn this stuff. I am looking at some example files from the ISC link you sent me: http://www.isc.org/files/arm96.html#sample_configuration I was thinking of just rebuilding the file from scratch as my current file is greek to me. However, the examples posted are for recursive only and authoritative only. Since my server is a hybrid, I am wondering which directives might interfere with the other. Moreover I had a look at the security section from that link: http://www.isc.org/files/arm96.html#Bv9ARM.ch07 Here is what I added to my named.conf. I guess over time they have increased the default security of BIND so that old files don't allow recursion from outside hosts by default. // Set up an ACL called our-nets. Replace this with the real IP numbers. acl our-nets { 192.168.1.0/24; }; options { // Relative to the chroot directory, if any directory "/etc/namedb"; pid-file"/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; allow-transfer { 76.238.148.146; allow-query { our-nets; }; allow-recursion { our-nets; }; }; Thanks, Chris Maness ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND Refusing to Resolve for External Hosts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/07/2010 20:28:27, Chris Maness wrote: > Including the line: > > acl public-nets { 127.0.0.1; ::1; } ^ You need a semi-colon here __| > for testing resulted in a failure to launch with the following error code: > > /etc/namedb/named.conf:23: unknown option 'acl' > /etc/rc.d/named: ERROR: named-checkconf for $named_conf failed Just defining the acl won't do a great deal on its own -- you need to add it to an allow-recursion {}; or similar block. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwvlQMACgkQ8Mjk52CukIy3igCfXVI0Hvq4VYLMFOWa5mR0E6JK zuEAn2Lt3SZbmm0z/chH1FimEtWQxaSI =DV8h -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND Refusing to Resolve for External Hosts
On Thu, Jul 1, 2010 at 7:33 AM, Matthew Seaman wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/07/2010 15:05:37, Chris Maness wrote: >> Can a sub block of IP address space be used, and if so, what is the >> wild card? > > Yes. You can use lists of IPs or address-and-mask in BIND ACLs. See: > > http://www.isc.org/files/arm96.html#address_match_lists > > and > > http://www.isc.org/files/arm96.html#id2553419 > > So, for example, I use this in my own BIND configuration: > > acl public-nets { > 127.0.0.1; > ::1; > 81.187.76.160/29; > 81.187.220.164; > 2001:8b0:151:1::/64; > }; > > Cheers, > > Matthew > > > - -- Including the line: acl public-nets { 127.0.0.1; ::1; } for testing resulted in a failure to launch with the following error code: /etc/namedb/named.conf:23: unknown option 'acl' /etc/rc.d/named: ERROR: named-checkconf for $named_conf failed It seems as though BIND did not recognize this option. Is there something that I need to enable in order to use this option? Thanks, Chris Maness ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND Refusing to Resolve for External Hosts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/07/2010 15:05:37, Chris Maness wrote: > Can a sub block of IP address space be used, and if so, what is the > wild card? Yes. You can use lists of IPs or address-and-mask in BIND ACLs. See: http://www.isc.org/files/arm96.html#address_match_lists and http://www.isc.org/files/arm96.html#id2553419 So, for example, I use this in my own BIND configuration: acl public-nets { 127.0.0.1; ::1; 81.187.76.160/29; 81.187.220.164; 2001:8b0:151:1::/64; }; Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwspz4ACgkQ8Mjk52CukIwe+ACfUD9llW6qoIhgNRGYr63gYU87 geAAmwcYudxH5G6YHiYLTmZGlveTOB+6 =ltc+ -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND Refusing to Resolve for External Hosts
Can a sub block of IP address space be used, and if so, what is the wild card? Chris On Wed, Jun 30, 2010 at 7:34 AM, Chris Maness wrote: > On Wed, Jun 30, 2010 at 1:49 AM, krad wrote: >> >> >> On 29 June 2010 07:20, Chris Maness wrote: >>> >>> My named server used to resolve for external hosts. Recently I have >>> noticed that it no longer resolves names for resolvers not on the >>> local host. It works just fine for dig on the dns server itself. It >>> also works for domains that it has authority over. I also have it set >>> up to be a caching server on my network. Has the spec for the config >>> file changed or something? >>> >>> Here is the beginning of the the config file: >>> >>> cat named.conf >>> // $FreeBSD: src/etc/namedb/named.conf,v 1.26.2.2.2.1 2008/11/25 >>> 02:59:29 kensmith Exp $ >>> // >>> // Refer to the named.conf(5) and named(8) man pages, and the >>> documentation >>> // in /usr/share/doc/bind9 for more details. >>> // >>> // If you are going to set up an authoritative server, make sure you >>> // understand the hairy details of how DNS works. Even with >>> // simple mistakes, you can break connectivity for affected parties, >>> // or cause huge amounts of useless Internet traffic. >>> >>> options { >>> // Relative to the chroot directory, if any >>> directory "/etc/namedb"; >>> pid-file "/var/run/named/pid"; >>> dump-file "/var/dump/named_dump.db"; >>> statistics-file "/var/stats/named.stats"; >>> allow-transfer { >>> 76.238.148.146; >>> }; >>> >>> // If named is being used only as a local resolver, this is a safe >>> default. >>> // For named to be accessible to the network, comment this option, specify >>> // the proper IP address, or delete this option. >>> // listen-on { 127.0.0.1; }; >>> >>> // If you have IPv6 enabled on this system, uncomment this option for >>> // use as a local resolver. To give access to the network, specify >>> // an IPv6 address, or the keyword "any". >>> // listen-on-v6 { ::1; }; >>> >>> // These zones are already covered by the empty zones listed below. >>> // If you remove the related empty zones below, comment these lines out. >>> disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; >>> disable-empty-zone >>> >>> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; >>> disable-empty-zone >>> >>> "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; >>> >>> // In addition to the "forwarders" clause, you can force your name >>> // server to never initiate queries of its own, but always ask its >>> // forwarders only, by enabling the following line: >>> // >>> // forward only; >>> >>> // If you've got a DNS server around at your upstream provider, enter >>> // its IP address here, and enable the line below. This will make you >>> // benefit from its cache, thus reduce overall DNS traffic in the >>> Internet. >>> /* >>> forwarders { >>> 127.0.0.1; >>> }; >>> */ >>> /* >>> Modern versions of BIND use a random UDP port for each outgoing >>> query by default in order to dramatically reduce the possibility >>> of cache poisoning. All users are strongly encouraged to >>> utilize >>> this feature, and to configure their firewalls to accommodate >>> it. >>> >>> AS A LAST RESORT in order to get around a restrictive firewall >>> policy you can try enabling the option below. Use of this >>> option >>> will significantly reduce your ability to withstand cache >>> poisoning >>> attacks, and should be avoided if at all possible. >>> >>> Replace N in the example with a number between 49160 and >>> 65530. >>> */ >>> // query-source address * port N; >>> }; >>> >>> // If you enable a local name server, don't forget to enter 127.0.0.1 >>> // first in your /etc/resolv.conf so this server will be queried. >>> // Also, make sure to enable it in /etc/rc.conf. >>> >>> // The traditional root hints mechanism. Use this, OR the slave zones >>> below. >>> zone "." { type hint; file "named.root"; }; >>> >>> /* Slaving the following zones from the root name servers has some >>> significant advantages: >>> 1. Faster local resolution for your users >>> 2. No spurious traffic will be sent from your network to the roots >>> 3. Greater resilience to any potential root server failure/DDoS >>> >>> On the other hand, this method requires more monitoring than the >>> hints file to be sure that an unexpected failure mode has not >>> incapacitated your server. Name servers that are serving a lot >>> of clients will benefit more from this approach than individual >>> hosts. Use with caution. >>> >>> To use this mechanism, uncomment the entries below, and comment >>> the hint zo
Re: BIND Refusing to Resolve for External Hosts
On 30 June 2010 15:34, Chris Maness wrote: > On Wed, Jun 30, 2010 at 1:49 AM, krad wrote: > > > > > > On 29 June 2010 07:20, Chris Maness wrote: > >> > >> My named server used to resolve for external hosts. Recently I have > >> noticed that it no longer resolves names for resolvers not on the > >> local host. It works just fine for dig on the dns server itself. It > >> also works for domains that it has authority over. I also have it set > >> up to be a caching server on my network. Has the spec for the config > >> file changed or something? > >> > >> Here is the beginning of the the config file: > >> > >> cat named.conf > >> // $FreeBSD: src/etc/namedb/named.conf,v 1.26.2.2.2.1 2008/11/25 > >> 02:59:29 kensmith Exp $ > >> // > >> // Refer to the named.conf(5) and named(8) man pages, and the > >> documentation > >> // in /usr/share/doc/bind9 for more details. > >> // > >> // If you are going to set up an authoritative server, make sure you > >> // understand the hairy details of how DNS works. Even with > >> // simple mistakes, you can break connectivity for affected parties, > >> // or cause huge amounts of useless Internet traffic. > >> > >> options { > >>// Relative to the chroot directory, if any > >>directory "/etc/namedb"; > >>pid-file"/var/run/named/pid"; > >>dump-file "/var/dump/named_dump.db"; > >>statistics-file "/var/stats/named.stats"; > >>allow-transfer { > >>76.238.148.146; > >>}; > >> > >> // If named is being used only as a local resolver, this is a safe > >> default. > >> // For named to be accessible to the network, comment this option, > specify > >> // the proper IP address, or delete this option. > >> // listen-on { 127.0.0.1; }; > >> > >> // If you have IPv6 enabled on this system, uncomment this option for > >> // use as a local resolver. To give access to the network, specify > >> // an IPv6 address, or the keyword "any". > >> // listen-on-v6{ ::1; }; > >> > >> // These zones are already covered by the empty zones listed below. > >> // If you remove the related empty zones below, comment these lines out. > >>disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; > >>disable-empty-zone > >> > >> > "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; > >>disable-empty-zone > >> > >> > "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; > >> > >> // In addition to the "forwarders" clause, you can force your name > >> // server to never initiate queries of its own, but always ask its > >> // forwarders only, by enabling the following line: > >> // > >> // forward only; > >> > >> // If you've got a DNS server around at your upstream provider, enter > >> // its IP address here, and enable the line below. This will make you > >> // benefit from its cache, thus reduce overall DNS traffic in the > >> Internet. > >> /* > >>forwarders { > >>127.0.0.1; > >>}; > >> */ > >>/* > >> Modern versions of BIND use a random UDP port for each > outgoing > >> query by default in order to dramatically reduce the > possibility > >> of cache poisoning. All users are strongly encouraged to > >> utilize > >> this feature, and to configure their firewalls to accommodate > >> it. > >> > >> AS A LAST RESORT in order to get around a restrictive firewall > >> policy you can try enabling the option below. Use of this > >> option > >> will significantly reduce your ability to withstand cache > >> poisoning > >> attacks, and should be avoided if at all possible. > >> > >> Replace N in the example with a number between 49160 and > >> 65530. > >>*/ > >>// query-source address * port N; > >> }; > >> > >> // If you enable a local name server, don't forget to enter 127.0.0.1 > >> // first in your /etc/resolv.conf so this server will be queried. > >> // Also, make sure to enable it in /etc/rc.conf. > >> > >> // The traditional root hints mechanism. Use this, OR the slave zones > >> below. > >> zone "." { type hint; file "named.root"; }; > >> > >> /* Slaving the following zones from the root name servers has some > >>significant advantages: > >>1. Faster local resolution for your users > >>2. No spurious traffic will be sent from your network to the > roots > >>3. Greater resilience to any potential root server failure/DDoS > >> > >>On the other hand, this method requires more monitoring than the > >>hints file to be sure that an unexpected failure mode has not > >>incapacitated your server. Name servers that are serving a lot > >>of clients will benefit more from this approach than individual > >>hosts. Use with caution. > >> > >>To use this mechanism, uncomment the entries below, and
Re: BIND Refusing to Resolve for External Hosts
On Wed, Jun 30, 2010 at 1:49 AM, krad wrote: > > > On 29 June 2010 07:20, Chris Maness wrote: >> >> My named server used to resolve for external hosts. Recently I have >> noticed that it no longer resolves names for resolvers not on the >> local host. It works just fine for dig on the dns server itself. It >> also works for domains that it has authority over. I also have it set >> up to be a caching server on my network. Has the spec for the config >> file changed or something? >> >> Here is the beginning of the the config file: >> >> cat named.conf >> // $FreeBSD: src/etc/namedb/named.conf,v 1.26.2.2.2.1 2008/11/25 >> 02:59:29 kensmith Exp $ >> // >> // Refer to the named.conf(5) and named(8) man pages, and the >> documentation >> // in /usr/share/doc/bind9 for more details. >> // >> // If you are going to set up an authoritative server, make sure you >> // understand the hairy details of how DNS works. Even with >> // simple mistakes, you can break connectivity for affected parties, >> // or cause huge amounts of useless Internet traffic. >> >> options { >> // Relative to the chroot directory, if any >> directory "/etc/namedb"; >> pid-file "/var/run/named/pid"; >> dump-file "/var/dump/named_dump.db"; >> statistics-file "/var/stats/named.stats"; >> allow-transfer { >> 76.238.148.146; >> }; >> >> // If named is being used only as a local resolver, this is a safe >> default. >> // For named to be accessible to the network, comment this option, specify >> // the proper IP address, or delete this option. >> // listen-on { 127.0.0.1; }; >> >> // If you have IPv6 enabled on this system, uncomment this option for >> // use as a local resolver. To give access to the network, specify >> // an IPv6 address, or the keyword "any". >> // listen-on-v6 { ::1; }; >> >> // These zones are already covered by the empty zones listed below. >> // If you remove the related empty zones below, comment these lines out. >> disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; >> disable-empty-zone >> >> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; >> disable-empty-zone >> >> "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; >> >> // In addition to the "forwarders" clause, you can force your name >> // server to never initiate queries of its own, but always ask its >> // forwarders only, by enabling the following line: >> // >> // forward only; >> >> // If you've got a DNS server around at your upstream provider, enter >> // its IP address here, and enable the line below. This will make you >> // benefit from its cache, thus reduce overall DNS traffic in the >> Internet. >> /* >> forwarders { >> 127.0.0.1; >> }; >> */ >> /* >> Modern versions of BIND use a random UDP port for each outgoing >> query by default in order to dramatically reduce the possibility >> of cache poisoning. All users are strongly encouraged to >> utilize >> this feature, and to configure their firewalls to accommodate >> it. >> >> AS A LAST RESORT in order to get around a restrictive firewall >> policy you can try enabling the option below. Use of this >> option >> will significantly reduce your ability to withstand cache >> poisoning >> attacks, and should be avoided if at all possible. >> >> Replace N in the example with a number between 49160 and >> 65530. >> */ >> // query-source address * port N; >> }; >> >> // If you enable a local name server, don't forget to enter 127.0.0.1 >> // first in your /etc/resolv.conf so this server will be queried. >> // Also, make sure to enable it in /etc/rc.conf. >> >> // The traditional root hints mechanism. Use this, OR the slave zones >> below. >> zone "." { type hint; file "named.root"; }; >> >> /* Slaving the following zones from the root name servers has some >> significant advantages: >> 1. Faster local resolution for your users >> 2. No spurious traffic will be sent from your network to the roots >> 3. Greater resilience to any potential root server failure/DDoS >> >> On the other hand, this method requires more monitoring than the >> hints file to be sure that an unexpected failure mode has not >> incapacitated your server. Name servers that are serving a lot >> of clients will benefit more from this approach than individual >> hosts. Use with caution. >> >> To use this mechanism, uncomment the entries below, and comment >> the hint zone above. >> */ >> /* >> zone "." { >> type slave; >> file "slave/root.slave"; >> masters { >> 192.5.5.241; // F.ROOT-SERVERS.NET. >> }; >> notify no; >> }; >> >> zone "0.0.127.IN-ADDR.ARPA" { >> ty
Re: BIND Refusing to Resolve for External Hosts
On 29 June 2010 07:20, Chris Maness wrote: > My named server used to resolve for external hosts. Recently I have > noticed that it no longer resolves names for resolvers not on the > local host. It works just fine for dig on the dns server itself. It > also works for domains that it has authority over. I also have it set > up to be a caching server on my network. Has the spec for the config > file changed or something? > > Here is the beginning of the the config file: > > cat named.conf > // $FreeBSD: src/etc/namedb/named.conf,v 1.26.2.2.2.1 2008/11/25 > 02:59:29 kensmith Exp $ > // > // Refer to the named.conf(5) and named(8) man pages, and the documentation > // in /usr/share/doc/bind9 for more details. > // > // If you are going to set up an authoritative server, make sure you > // understand the hairy details of how DNS works. Even with > // simple mistakes, you can break connectivity for affected parties, > // or cause huge amounts of useless Internet traffic. > > options { >// Relative to the chroot directory, if any >directory "/etc/namedb"; >pid-file"/var/run/named/pid"; >dump-file "/var/dump/named_dump.db"; >statistics-file "/var/stats/named.stats"; >allow-transfer { >76.238.148.146; >}; > > // If named is being used only as a local resolver, this is a safe default. > // For named to be accessible to the network, comment this option, specify > // the proper IP address, or delete this option. > // listen-on { 127.0.0.1; }; > > // If you have IPv6 enabled on this system, uncomment this option for > // use as a local resolver. To give access to the network, specify > // an IPv6 address, or the keyword "any". > // listen-on-v6{ ::1; }; > > // These zones are already covered by the empty zones listed below. > // If you remove the related empty zones below, comment these lines out. >disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; >disable-empty-zone > "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; >disable-empty-zone > "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; > > // In addition to the "forwarders" clause, you can force your name > // server to never initiate queries of its own, but always ask its > // forwarders only, by enabling the following line: > // > // forward only; > > // If you've got a DNS server around at your upstream provider, enter > // its IP address here, and enable the line below. This will make you > // benefit from its cache, thus reduce overall DNS traffic in the Internet. > /* >forwarders { >127.0.0.1; >}; > */ >/* > Modern versions of BIND use a random UDP port for each outgoing > query by default in order to dramatically reduce the possibility > of cache poisoning. All users are strongly encouraged to utilize > this feature, and to configure their firewalls to accommodate it. > > AS A LAST RESORT in order to get around a restrictive firewall > policy you can try enabling the option below. Use of this option > will significantly reduce your ability to withstand cache > poisoning > attacks, and should be avoided if at all possible. > > Replace N in the example with a number between 49160 and > 65530. >*/ >// query-source address * port N; > }; > > // If you enable a local name server, don't forget to enter 127.0.0.1 > // first in your /etc/resolv.conf so this server will be queried. > // Also, make sure to enable it in /etc/rc.conf. > > // The traditional root hints mechanism. Use this, OR the slave zones > below. > zone "." { type hint; file "named.root"; }; > > /* Slaving the following zones from the root name servers has some >significant advantages: >1. Faster local resolution for your users >2. No spurious traffic will be sent from your network to the roots >3. Greater resilience to any potential root server failure/DDoS > >On the other hand, this method requires more monitoring than the >hints file to be sure that an unexpected failure mode has not >incapacitated your server. Name servers that are serving a lot >of clients will benefit more from this approach than individual >hosts. Use with caution. > >To use this mechanism, uncomment the entries below, and comment >the hint zone above. > */ > /* > zone "." { >type slave; >file "slave/root.slave"; >masters { >192.5.5.241;// F.ROOT-SERVERS.NET. >}; >notify no; > }; > > zone "0.0.127.IN-ADDR.ARPA" { >type master; >file "master/localhost.rev"; > }; > zone "in-addr.arpa" { >type slave; >file "slave/in-addr.arpa.slave"; >masters { >192.5.5.241;/
Re: BIND Refusing to Resolve for External Hosts
uhm here's my named.conf (it's a bit lightwight) but it works... // $FreeBSD: src/etc/namedb/named.conf,v 1.26.2.2.4.1 2009/04/15 03:14:26 > kensmith Exp $ > options { > directory"/etc/namedb/namedwritable"; //made dir writable to bind > user > pid-file"/var/run/named/pid"; > dump-file"/var/dump/named_dump.db"; > statistics-file"/var/stats/named.stats"; > //listen-on{ 127.0.0.1; }; > disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; > disable-empty-zone > "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; > disable-empty-zone > "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; > forwarders {8.8.8.8; 8.8.4.4; 62.231.76.49; 81.18.85.7; 4.2.2.4; > 208.67.222.222; 208.67.220.220; 213.154.124.1; 193.231.252.1; 4.2.2.1; > 4.2.2.2; 4.2.2.3; 4.2.2.5; 4.2.2.6; 151.197.0.38; 151.197.0.39; > 151.202.0.84; 151.202.0.85; 151.202.0.85; 151.203.0.84; 151.203.0.85; > 199.45.32.37; 199.45.32.38; 199.45.32.40; 199.45.32.43; 192.76.85.133; > 206.124.64.1; 67.138.54.100; 220.233.167.31; 199.166.31.3; 66.93.87.2; > 216.231.41.2; 216.254.95.2; 64.81.45.2; 64.81.111.2; 64.81.127.2; > 64.81.79.2; 64.81.159.2; 66.92.64.2; 66.92.224.2; 66.92.159.2; 64.81.79.2; > 64.81.159.2; 64.81.127.2; 64.81.45.2; 216.27.175.2; 66.92.159.2; 66.93.87.2; > 199.2.252.10; 204.97.212.10; 204.117.214.10; 64.102.255.44; 128.107.241.185; > 156.154.70.1; 156.154.71.1;}; > }; > > zone "." { type hint; file "../named.root"; }; > > zone "pgn.ro" { > type master; > file "../master/pgn.ro.zone"; //master dir writable to bind user > allow-transfer { localhost; }; > allow-update { key rndc-key; }; > }; > > zone "pvp.ro" { > type master; > file "../master/pvp.ro.zone"; > allow-transfer { localhost; }; > allow-update { key rndc-key; }; > > }; > > zone "pnl-mioveni.ro" { > type master; > file "../master/pnl-mioveni.ro.zone"; > allow-transfer { localhost; }; > allow-update { key rndc-key; }; > }; > > zone "chiritamarian.ro" { > type master; > file "../master/chiritamarian.ro.zone"; > allow-transfer { localhost; }; > allow-update { key rndc-key; }; > }; > > key "rndc-key" { > algorithm hmac-md5; > secret "XX"; > }; > > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Bind Sendmail to an IP address
On Wed, 28 Oct 2009 15:49:15 -0700 (PDT), Aflatoon Aflatooni wrote: > Hi, > I have a Freebsd 7.2 installation and using Sendmail for the SMTP > service. This server has two public interfaces and different IP > addresses. > > I need to have sendmail configured so that the outbound emails are > sent using a certain IP address (SPF rules). I have tried the > following without any success: > > DAEMON_OPTIONS(`Addr=x.y.z.i')dnl > > Any help or suggestions would be greatly appriciated. When Sendmail relays messages to another server it acts as the `client' for that server. So you have to use CLIENT_OPTIONS() instead of the DAEMON_OPTIONS() you are using now: CLIENT_OPTIONS(`Addr=a.b.c.d')dnl ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: bind configuration issues
On Mon, Oct 26, 2009 at 6:42 PM, Steve Bertrand wrote: > Ray Still wrote: >> Ok, >> tell me just how nuts this idea is. > > imho, your thought-process is not nuts. I can see what you are trying to > do, so kudos given for trying to work it out with what you have. > >> To recap, two pipes, one destination. > >> I set up second DNS server. >> ns1.example.com at 70.65. (provider 1) >> ns2.example.com at 206.75(provider 2) >> A records for example.org on ns1 will give 70.65. >> on ns2 206.75 >> if provider one goes down, ns1 is gone, ns2 is still available, and so >> is the route to the sites. > > Note: I haven't followed the entire thread... > > Remember that no matter where your name servers are located, they both > will hold the same information (if they don't, then shame on you, as you > just broke scalability). > > This means that other caching servers all over the 'net may have either > entry. Some ISP's name servers will cache records even longer than what > your TTL is set to without trying to re-check (shame on them). Hence, > you can never count on using DNS naming as a tactic for redundancy. > >> It's not the best solution, but it's better than what I have. > > If I understand your conundrum properly (one server with an internal IP, > with NAT in front of it, port-forwarded back aliased from two separate > ISP public IPs), then, at minimum, here's how you can essentially > 'halve' the damage: > > - set up your DNS servers in a proper master/slave configuration > - configure your 'A' records in a round-robin setup. I'll assume your > zone is ibctech.ca, and that your $TTL is 360: > > www IN A 208.70.104.210 > www IN A 208.70.104.211 > > (yes, I know 360 puts pressure on everyone else, but this is for example > purposes). > > If I know I will need to make DNS changes in advance for a domain, I'll > set the TTL to 360 (secs) long before the changes need to be made. Then, > I can make the changes, and if caching resolvers are Doing The Right > Thing, they will pick up these changes after five minutes. > > If you have a domain that is high-traffic, don't do this. I'd like to > emphasize that a low ttl puts pressure on every DNS caching server on > the Internet that must look up information on your domain. > > With that said, with a 5 min ttl, in the event of an outage, you can hop > onto your authoritative DNS server, switch BOTH A records to point to > the working IP, and the rest of the 'net 'should' be able to see those > changes within five minutes (again, if they obey your ttl). > > Steve > OK, after reading and re-reading and experimenting I think I get it. Thanks for your comments and patience. I will probably end up using something based on Gary's round robin suggestion. It may not provide 100% reliable failover, but it will help, and worst case, it will provide some bandwidth sharing. Thanks, Ray ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: bind configuration issues
Ray Still wrote: > Ok, > tell me just how nuts this idea is. In addition to my other post: I like your mentality of trying to do whatever you can to create redundancy. I've often tried to think of ways to use DNS to make things redundant and resilient. Keep up trying new ways to stretch things in ways people may not have expected. You never know what you may stumble across one day. Cheers, Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: bind configuration issues
Ray Still wrote: > Ok, > tell me just how nuts this idea is. imho, your thought-process is not nuts. I can see what you are trying to do, so kudos given for trying to work it out with what you have. > To recap, two pipes, one destination. > I set up second DNS server. > ns1.example.com at 70.65. (provider 1) > ns2.example.com at 206.75(provider 2) > A records for example.org on ns1 will give 70.65. > on ns2 206.75 > if provider one goes down, ns1 is gone, ns2 is still available, and so > is the route to the sites. Note: I haven't followed the entire thread... Remember that no matter where your name servers are located, they both will hold the same information (if they don't, then shame on you, as you just broke scalability). This means that other caching servers all over the 'net may have either entry. Some ISP's name servers will cache records even longer than what your TTL is set to without trying to re-check (shame on them). Hence, you can never count on using DNS naming as a tactic for redundancy. > It's not the best solution, but it's better than what I have. If I understand your conundrum properly (one server with an internal IP, with NAT in front of it, port-forwarded back aliased from two separate ISP public IPs), then, at minimum, here's how you can essentially 'halve' the damage: - set up your DNS servers in a proper master/slave configuration - configure your 'A' records in a round-robin setup. I'll assume your zone is ibctech.ca, and that your $TTL is 360: www IN A 208.70.104.210 www IN A 208.70.104.211 (yes, I know 360 puts pressure on everyone else, but this is for example purposes). If I know I will need to make DNS changes in advance for a domain, I'll set the TTL to 360 (secs) long before the changes need to be made. Then, I can make the changes, and if caching resolvers are Doing The Right Thing, they will pick up these changes after five minutes. If you have a domain that is high-traffic, don't do this. I'd like to emphasize that a low ttl puts pressure on every DNS caching server on the Internet that must look up information on your domain. With that said, with a 5 min ttl, in the event of an outage, you can hop onto your authoritative DNS server, switch BOTH A records to point to the working IP, and the rest of the 'net 'should' be able to see those changes within five minutes (again, if they obey your ttl). Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: bind configuration issues
How will the client side resolvers know what dns server to use to resolve example.com? - Original Message - From: Gary Gatten To: 'rstil...@gmail.com' ; 'freebsd-questions@freebsd.org' Sent: Mon Oct 26 18:24:38 2009 Subject: Re: bind configuration issues Yes, your missing something. I don't think your solution will work very well. - Original Message - From: owner-freebsd-questi...@freebsd.org To: freebsd-questions@freebsd.org Sent: Mon Oct 26 18:13:47 2009 Subject: Re: bind configuration issues Ok, tell me just how nuts this idea is. To recap, two pipes, one destination. I set up second DNS server. ns1.example.com at 70.65. (provider 1) ns2.example.com at 206.75(provider 2) A records for example.org on ns1 will give 70.65. on ns2 206.75 if provider one goes down, ns1 is gone, ns2 is still available, and so is the route to the sites. It's not the best solution, but it's better than what I have. Am I missing something that's going to come back and bite me in the butt? Thanks, Ray On Mon, Oct 26, 2009 at 2:14 PM, Gary Gatten wrote: > I googled "dns round robin failover" and there are many hits. One > interesting one is: > http://forums.devshed.com/dns-36/ha-using-round-robinworking-368800.html > > It suggests well written apps / resolvers will try to use all ip's returned > by the query starting with the preferred one, not JUST the preferred one. > Which means, just by enabling round robin with multiple A records, you MAY > get some level of HA/Failover by default. Cool, BUT, I wouldn't bet my life > on it. I'd still have something that could tweak your DNS records based on > packet loss, latency, etc. What if your circuit is "up", but is degraded by > loss, latency (load induced or otherwise), etc. > > As you mentioned, something is better than nothing - so start simple and go > from there! > > HTH! > > G > > > -Original Message- > From: owner-freebsd-questi...@freebsd.org > [mailto:owner-freebsd-questi...@freebsd.org] On Behalf Of Gary Gatten > Sent: Monday, October 26, 2009 2:07 PM > To: Ray Still; freebsd-questions@freebsd.org > Subject: RE: bind configuration issues > > I'm not intimate with bind, or anything/one actually - but that's another > story... > > Anyway, the gist is you need to "ping" some public hosts from your dns server > (or another system I guess, but easier if on the dns server). One > destination host would be reachable through one connection, and the other of > course would only be reachable through the alternate connection. Maybe use > the primary DNS servers each upstream ISP provides to you? Anyway, if both > pings are OK, then your DNS server does round-robin for the host(s) in > question. If one ping fails, then you stop handing out that IP. You can for > the route taken within ping itself, or use static host(/32) routes, etc. > > Sounds simple huh? It kinda is, and LONG ago I had a shell script to do just > this, but it's gone - and maybe bind 9+ has some sort of this functionality > available to you embedded in the bind code? Don't know. Even if you have to > write your own script to update your dns records based on your monitoring > process it's not that hard even for a scripting novice such as myself! > > G > > > -Original Message- > From: owner-freebsd-questi...@freebsd.org > [mailto:owner-freebsd-questi...@freebsd.org] On Behalf Of Ray Still > Sent: Monday, October 26, 2009 1:56 PM > To: freebsd-questions@freebsd.org > Subject: Re: bind configuration issues > > On Mon, Oct 26, 2009 at 11:55 AM, Gary Gatten wrote: >> >> You certainly don't "need" BGP for this, the DNS thing will work, but will >> be a bit kludgy and certainly not as ... "responsive" to failures - a la >> query caching, TTL's and what not. >> >> - Original Message - >> From: owner-freebsd-questi...@freebsd.org >> >> To: Ray Still >> Cc: freebsd-questions@freebsd.org >> Sent: Mon Oct 26 12:50:56 2009 >> Subject: Re: bind configuration issues >> >> On Oct 26, 2009, at 10:03 AM, Ray Still wrote: >> > Hello, >> > I am adding a redundant Internet connection to my current hosting >> > setup and >> > I need to figure out how to set up the DNS to make this work. >> >> The two issues normally aren't related. >> >> If both connections are from the same provider, talk to them about >> multilink PPP; if they are from different providers, you need to look >> into multihoming and getting your own AS #. >> > > two different providers
Re: bind configuration issues
Yes, your missing something. I don't think your solution will work very well. - Original Message - From: owner-freebsd-questi...@freebsd.org To: freebsd-questions@freebsd.org Sent: Mon Oct 26 18:13:47 2009 Subject: Re: bind configuration issues Ok, tell me just how nuts this idea is. To recap, two pipes, one destination. I set up second DNS server. ns1.example.com at 70.65. (provider 1) ns2.example.com at 206.75(provider 2) A records for example.org on ns1 will give 70.65. on ns2 206.75 if provider one goes down, ns1 is gone, ns2 is still available, and so is the route to the sites. It's not the best solution, but it's better than what I have. Am I missing something that's going to come back and bite me in the butt? Thanks, Ray On Mon, Oct 26, 2009 at 2:14 PM, Gary Gatten wrote: > I googled "dns round robin failover" and there are many hits. One > interesting one is: > http://forums.devshed.com/dns-36/ha-using-round-robinworking-368800.html > > It suggests well written apps / resolvers will try to use all ip's returned > by the query starting with the preferred one, not JUST the preferred one. > Which means, just by enabling round robin with multiple A records, you MAY > get some level of HA/Failover by default. Cool, BUT, I wouldn't bet my life > on it. I'd still have something that could tweak your DNS records based on > packet loss, latency, etc. What if your circuit is "up", but is degraded by > loss, latency (load induced or otherwise), etc. > > As you mentioned, something is better than nothing - so start simple and go > from there! > > HTH! > > G > > > -Original Message- > From: owner-freebsd-questi...@freebsd.org > [mailto:owner-freebsd-questi...@freebsd.org] On Behalf Of Gary Gatten > Sent: Monday, October 26, 2009 2:07 PM > To: Ray Still; freebsd-questions@freebsd.org > Subject: RE: bind configuration issues > > I'm not intimate with bind, or anything/one actually - but that's another > story... > > Anyway, the gist is you need to "ping" some public hosts from your dns server > (or another system I guess, but easier if on the dns server). One > destination host would be reachable through one connection, and the other of > course would only be reachable through the alternate connection. Maybe use > the primary DNS servers each upstream ISP provides to you? Anyway, if both > pings are OK, then your DNS server does round-robin for the host(s) in > question. If one ping fails, then you stop handing out that IP. You can for > the route taken within ping itself, or use static host(/32) routes, etc. > > Sounds simple huh? It kinda is, and LONG ago I had a shell script to do just > this, but it's gone - and maybe bind 9+ has some sort of this functionality > available to you embedded in the bind code? Don't know. Even if you have to > write your own script to update your dns records based on your monitoring > process it's not that hard even for a scripting novice such as myself! > > G > > > -Original Message- > From: owner-freebsd-questi...@freebsd.org > [mailto:owner-freebsd-questi...@freebsd.org] On Behalf Of Ray Still > Sent: Monday, October 26, 2009 1:56 PM > To: freebsd-questions@freebsd.org > Subject: Re: bind configuration issues > > On Mon, Oct 26, 2009 at 11:55 AM, Gary Gatten wrote: >> >> You certainly don't "need" BGP for this, the DNS thing will work, but will >> be a bit kludgy and certainly not as ... "responsive" to failures - a la >> query caching, TTL's and what not. >> >> - Original Message - >> From: owner-freebsd-questi...@freebsd.org >> >> To: Ray Still >> Cc: freebsd-questions@freebsd.org >> Sent: Mon Oct 26 12:50:56 2009 >> Subject: Re: bind configuration issues >> >> On Oct 26, 2009, at 10:03 AM, Ray Still wrote: >> > Hello, >> > I am adding a redundant Internet connection to my current hosting >> > setup and >> > I need to figure out how to set up the DNS to make this work. >> >> The two issues normally aren't related. >> >> If both connections are from the same provider, talk to them about >> multilink PPP; if they are from different providers, you need to look >> into multihoming and getting your own AS #. >> > > two different providers. > >> >> > Current setup: >> > freebsd 7.0 machine, one local IP address, runs web, mail, and name >> > server. >> > static ip address in router. >> > I have two DNS servers registered, but they both point to the same ip >> >
Re: bind configuration issues
Ok, tell me just how nuts this idea is. To recap, two pipes, one destination. I set up second DNS server. ns1.example.com at 70.65. (provider 1) ns2.example.com at 206.75(provider 2) A records for example.org on ns1 will give 70.65. on ns2 206.75 if provider one goes down, ns1 is gone, ns2 is still available, and so is the route to the sites. It's not the best solution, but it's better than what I have. Am I missing something that's going to come back and bite me in the butt? Thanks, Ray On Mon, Oct 26, 2009 at 2:14 PM, Gary Gatten wrote: > I googled "dns round robin failover" and there are many hits. One > interesting one is: > http://forums.devshed.com/dns-36/ha-using-round-robinworking-368800.html > > It suggests well written apps / resolvers will try to use all ip's returned > by the query starting with the preferred one, not JUST the preferred one. > Which means, just by enabling round robin with multiple A records, you MAY > get some level of HA/Failover by default. Cool, BUT, I wouldn't bet my life > on it. I'd still have something that could tweak your DNS records based on > packet loss, latency, etc. What if your circuit is "up", but is degraded by > loss, latency (load induced or otherwise), etc. > > As you mentioned, something is better than nothing - so start simple and go > from there! > > HTH! > > G > > > -Original Message- > From: owner-freebsd-questi...@freebsd.org > [mailto:owner-freebsd-questi...@freebsd.org] On Behalf Of Gary Gatten > Sent: Monday, October 26, 2009 2:07 PM > To: Ray Still; freebsd-questions@freebsd.org > Subject: RE: bind configuration issues > > I'm not intimate with bind, or anything/one actually - but that's another > story... > > Anyway, the gist is you need to "ping" some public hosts from your dns server > (or another system I guess, but easier if on the dns server). One > destination host would be reachable through one connection, and the other of > course would only be reachable through the alternate connection. Maybe use > the primary DNS servers each upstream ISP provides to you? Anyway, if both > pings are OK, then your DNS server does round-robin for the host(s) in > question. If one ping fails, then you stop handing out that IP. You can for > the route taken within ping itself, or use static host(/32) routes, etc. > > Sounds simple huh? It kinda is, and LONG ago I had a shell script to do just > this, but it's gone - and maybe bind 9+ has some sort of this functionality > available to you embedded in the bind code? Don't know. Even if you have to > write your own script to update your dns records based on your monitoring > process it's not that hard even for a scripting novice such as myself! > > G > > > -----Original Message- > From: owner-freebsd-questi...@freebsd.org > [mailto:owner-freebsd-questi...@freebsd.org] On Behalf Of Ray Still > Sent: Monday, October 26, 2009 1:56 PM > To: freebsd-questions@freebsd.org > Subject: Re: bind configuration issues > > On Mon, Oct 26, 2009 at 11:55 AM, Gary Gatten wrote: >> >> You certainly don't "need" BGP for this, the DNS thing will work, but will >> be a bit kludgy and certainly not as ... "responsive" to failures - a la >> query caching, TTL's and what not. >> >> - Original Message - >> From: owner-freebsd-questi...@freebsd.org >> >> To: Ray Still >> Cc: freebsd-questions@freebsd.org >> Sent: Mon Oct 26 12:50:56 2009 >> Subject: Re: bind configuration issues >> >> On Oct 26, 2009, at 10:03 AM, Ray Still wrote: >> > Hello, >> > I am adding a redundant Internet connection to my current hosting >> > setup and >> > I need to figure out how to set up the DNS to make this work. >> >> The two issues normally aren't related. >> >> If both connections are from the same provider, talk to them about >> multilink PPP; if they are from different providers, you need to look >> into multihoming and getting your own AS #. >> > > two different providers. > >> >> > Current setup: >> > freebsd 7.0 machine, one local IP address, runs web, mail, and name >> > server. >> > static ip address in router. >> > I have two DNS servers registered, but they both point to the same ip >> > address an the same machine. (Yes, I should have my fingers slapped.) >> > >> > Desired setup >> > same machine, one local IP address, runs web, mail, and name server. >> > different router (Linksys RV082) with 2 static ip a
RE: bind configuration issues
I googled "dns round robin failover" and there are many hits. One interesting one is: http://forums.devshed.com/dns-36/ha-using-round-robinworking-368800.html It suggests well written apps / resolvers will try to use all ip's returned by the query starting with the preferred one, not JUST the preferred one. Which means, just by enabling round robin with multiple A records, you MAY get some level of HA/Failover by default. Cool, BUT, I wouldn't bet my life on it. I'd still have something that could tweak your DNS records based on packet loss, latency, etc. What if your circuit is "up", but is degraded by loss, latency (load induced or otherwise), etc. As you mentioned, something is better than nothing - so start simple and go from there! HTH! G -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd-questi...@freebsd.org] On Behalf Of Gary Gatten Sent: Monday, October 26, 2009 2:07 PM To: Ray Still; freebsd-questions@freebsd.org Subject: RE: bind configuration issues I'm not intimate with bind, or anything/one actually - but that's another story... Anyway, the gist is you need to "ping" some public hosts from your dns server (or another system I guess, but easier if on the dns server). One destination host would be reachable through one connection, and the other of course would only be reachable through the alternate connection. Maybe use the primary DNS servers each upstream ISP provides to you? Anyway, if both pings are OK, then your DNS server does round-robin for the host(s) in question. If one ping fails, then you stop handing out that IP. You can for the route taken within ping itself, or use static host(/32) routes, etc. Sounds simple huh? It kinda is, and LONG ago I had a shell script to do just this, but it's gone - and maybe bind 9+ has some sort of this functionality available to you embedded in the bind code? Don't know. Even if you have to write your own script to update your dns records based on your monitoring process it's not that hard even for a scripting novice such as myself! G -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd-questi...@freebsd.org] On Behalf Of Ray Still Sent: Monday, October 26, 2009 1:56 PM To: freebsd-questions@freebsd.org Subject: Re: bind configuration issues On Mon, Oct 26, 2009 at 11:55 AM, Gary Gatten wrote: > > You certainly don't "need" BGP for this, the DNS thing will work, but will be > a bit kludgy and certainly not as ... "responsive" to failures - a la query > caching, TTL's and what not. > > - Original Message - > From: owner-freebsd-questi...@freebsd.org > > To: Ray Still > Cc: freebsd-questions@freebsd.org > Sent: Mon Oct 26 12:50:56 2009 > Subject: Re: bind configuration issues > > On Oct 26, 2009, at 10:03 AM, Ray Still wrote: > > Hello, > > I am adding a redundant Internet connection to my current hosting > > setup and > > I need to figure out how to set up the DNS to make this work. > > The two issues normally aren't related. > > If both connections are from the same provider, talk to them about > multilink PPP; if they are from different providers, you need to look > into multihoming and getting your own AS #. > two different providers. > > > Current setup: > > freebsd 7.0 machine, one local IP address, runs web, mail, and name > > server. > > static ip address in router. > > I have two DNS servers registered, but they both point to the same ip > > address an the same machine. (Yes, I should have my fingers slapped.) > > > > Desired setup > > same machine, one local IP address, runs web, mail, and name server. > > different router (Linksys RV082) with 2 static ip address. > > In order to have redundancy, you need to have two real, separate > machines, each of which is running BIND, each of which is on a > separate routable IP. This is an orthogonal issue to setting up > multiple Internet connections. Yes, In an ideal world I would do this. The two machines would also be in separate buildings/cities/provinces/countries/planets (pick your level of paranoia) ;) However, reducing single points of failure is an improvement, even if I can't eliminate them. > > > How do I set up bind so that > > 1) bandwidth is shared between the two connections, > > and > > 2) if one goes down, the other keeps working. > > I had a few ideas, but they all seem to have flaws. > > You can't set up BIND to control multilink aggregation and failover; > that's not what it does. > > Regards, > -- freebsd-questions@freebsd.org > -Chuck > Thanks for the replies. Chuck, thanks for the keywords t
RE: bind configuration issues
I'm not intimate with bind, or anything/one actually - but that's another story... Anyway, the gist is you need to "ping" some public hosts from your dns server (or another system I guess, but easier if on the dns server). One destination host would be reachable through one connection, and the other of course would only be reachable through the alternate connection. Maybe use the primary DNS servers each upstream ISP provides to you? Anyway, if both pings are OK, then your DNS server does round-robin for the host(s) in question. If one ping fails, then you stop handing out that IP. You can for the route taken within ping itself, or use static host(/32) routes, etc. Sounds simple huh? It kinda is, and LONG ago I had a shell script to do just this, but it's gone - and maybe bind 9+ has some sort of this functionality available to you embedded in the bind code? Don't know. Even if you have to write your own script to update your dns records based on your monitoring process it's not that hard even for a scripting novice such as myself! G -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd-questi...@freebsd.org] On Behalf Of Ray Still Sent: Monday, October 26, 2009 1:56 PM To: freebsd-questions@freebsd.org Subject: Re: bind configuration issues On Mon, Oct 26, 2009 at 11:55 AM, Gary Gatten wrote: > > You certainly don't "need" BGP for this, the DNS thing will work, but will be > a bit kludgy and certainly not as ... "responsive" to failures - a la query > caching, TTL's and what not. > > - Original Message - > From: owner-freebsd-questi...@freebsd.org > > To: Ray Still > Cc: freebsd-questions@freebsd.org > Sent: Mon Oct 26 12:50:56 2009 > Subject: Re: bind configuration issues > > On Oct 26, 2009, at 10:03 AM, Ray Still wrote: > > Hello, > > I am adding a redundant Internet connection to my current hosting > > setup and > > I need to figure out how to set up the DNS to make this work. > > The two issues normally aren't related. > > If both connections are from the same provider, talk to them about > multilink PPP; if they are from different providers, you need to look > into multihoming and getting your own AS #. > two different providers. > > > Current setup: > > freebsd 7.0 machine, one local IP address, runs web, mail, and name > > server. > > static ip address in router. > > I have two DNS servers registered, but they both point to the same ip > > address an the same machine. (Yes, I should have my fingers slapped.) > > > > Desired setup > > same machine, one local IP address, runs web, mail, and name server. > > different router (Linksys RV082) with 2 static ip address. > > In order to have redundancy, you need to have two real, separate > machines, each of which is running BIND, each of which is on a > separate routable IP. This is an orthogonal issue to setting up > multiple Internet connections. Yes, In an ideal world I would do this. The two machines would also be in separate buildings/cities/provinces/countries/planets (pick your level of paranoia) ;) However, reducing single points of failure is an improvement, even if I can't eliminate them. > > > How do I set up bind so that > > 1) bandwidth is shared between the two connections, > > and > > 2) if one goes down, the other keeps working. > > I had a few ideas, but they all seem to have flaws. > > You can't set up BIND to control multilink aggregation and failover; > that's not what it does. > > Regards, > -- freebsd-questions@freebsd.org > -Chuck > Thanks for the replies. Chuck, thanks for the keywords to search. Some of what I'm finding looks like a solution for companies a lot bigger than me, but I'll keep looking. Gary, can you give me any clues about how to do it with just DNS? Yes, I do realize that this leaves single points of failure, but at least they would be points that I could do something about if necessary. Thanks again, Ray > > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" > > "This email is intended to be reviewed by only the intended recipient and may > contain information that is privileged and/or confidential. If you are not > the intended recipient, you are hereby notified that any review, use, > dissemination, disclosure or copying of this email and its attachments, if > any, is strictly prohibited. If you have received this email in error, please > immediately notify the sender by ret
Re: bind configuration issues
On Mon, Oct 26, 2009 at 11:55 AM, Gary Gatten wrote: > > You certainly don't "need" BGP for this, the DNS thing will work, but will be > a bit kludgy and certainly not as ... "responsive" to failures - a la query > caching, TTL's and what not. > > - Original Message - > From: owner-freebsd-questi...@freebsd.org > > To: Ray Still > Cc: freebsd-questions@freebsd.org > Sent: Mon Oct 26 12:50:56 2009 > Subject: Re: bind configuration issues > > On Oct 26, 2009, at 10:03 AM, Ray Still wrote: > > Hello, > > I am adding a redundant Internet connection to my current hosting > > setup and > > I need to figure out how to set up the DNS to make this work. > > The two issues normally aren't related. > > If both connections are from the same provider, talk to them about > multilink PPP; if they are from different providers, you need to look > into multihoming and getting your own AS #. > two different providers. > > > Current setup: > > freebsd 7.0 machine, one local IP address, runs web, mail, and name > > server. > > static ip address in router. > > I have two DNS servers registered, but they both point to the same ip > > address an the same machine. (Yes, I should have my fingers slapped.) > > > > Desired setup > > same machine, one local IP address, runs web, mail, and name server. > > different router (Linksys RV082) with 2 static ip address. > > In order to have redundancy, you need to have two real, separate > machines, each of which is running BIND, each of which is on a > separate routable IP. This is an orthogonal issue to setting up > multiple Internet connections. Yes, In an ideal world I would do this. The two machines would also be in separate buildings/cities/provinces/countries/planets (pick your level of paranoia) ;) However, reducing single points of failure is an improvement, even if I can't eliminate them. > > > How do I set up bind so that > > 1) bandwidth is shared between the two connections, > > and > > 2) if one goes down, the other keeps working. > > I had a few ideas, but they all seem to have flaws. > > You can't set up BIND to control multilink aggregation and failover; > that's not what it does. > > Regards, > -- freebsd-questions@freebsd.org > -Chuck > Thanks for the replies. Chuck, thanks for the keywords to search. Some of what I'm finding looks like a solution for companies a lot bigger than me, but I'll keep looking. Gary, can you give me any clues about how to do it with just DNS? Yes, I do realize that this leaves single points of failure, but at least they would be points that I could do something about if necessary. Thanks again, Ray > > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" > > "This email is intended to be reviewed by only the intended recipient and may > contain information that is privileged and/or confidential. If you are not > the intended recipient, you are hereby notified that any review, use, > dissemination, disclosure or copying of this email and its attachments, if > any, is strictly prohibited. If you have received this email in error, please > immediately notify the sender by return email and delete this email from your > system." ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: bind configuration issues
You certainly don't "need" BGP for this, the DNS thing will work, but will be a bit kludgy and certainly not as ... "responsive" to failures - a la query caching, TTL's and what not. - Original Message - From: owner-freebsd-questi...@freebsd.org To: Ray Still Cc: freebsd-questions@freebsd.org Sent: Mon Oct 26 12:50:56 2009 Subject: Re: bind configuration issues On Oct 26, 2009, at 10:03 AM, Ray Still wrote: > Hello, > I am adding a redundant Internet connection to my current hosting > setup and > I need to figure out how to set up the DNS to make this work. The two issues normally aren't related. If both connections are from the same provider, talk to them about multilink PPP; if they are from different providers, you need to look into multihoming and getting your own AS #. > Current setup: > freebsd 7.0 machine, one local IP address, runs web, mail, and name > server. > static ip address in router. > I have two DNS servers registered, but they both point to the same ip > address an the same machine. (Yes, I should have my fingers slapped.) > > Desired setup > same machine, one local IP address, runs web, mail, and name server. > different router (Linksys RV082) with 2 static ip address. In order to have redundancy, you need to have two real, separate machines, each of which is running BIND, each of which is on a separate routable IP. This is an orthogonal issue to setting up multiple Internet connections. > How do I set up bind so that > 1) bandwidth is shared between the two connections, > and > 2) if one goes down, the other keeps working. > I had a few ideas, but they all seem to have flaws. You can't set up BIND to control multilink aggregation and failover; that's not what it does. Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: bind configuration issues
On Oct 26, 2009, at 10:03 AM, Ray Still wrote: Hello, I am adding a redundant Internet connection to my current hosting setup and I need to figure out how to set up the DNS to make this work. The two issues normally aren't related. If both connections are from the same provider, talk to them about multilink PPP; if they are from different providers, you need to look into multihoming and getting your own AS #. Current setup: freebsd 7.0 machine, one local IP address, runs web, mail, and name server. static ip address in router. I have two DNS servers registered, but they both point to the same ip address an the same machine. (Yes, I should have my fingers slapped.) Desired setup same machine, one local IP address, runs web, mail, and name server. different router (Linksys RV082) with 2 static ip address. In order to have redundancy, you need to have two real, separate machines, each of which is running BIND, each of which is on a separate routable IP. This is an orthogonal issue to setting up multiple Internet connections. How do I set up bind so that 1) bandwidth is shared between the two connections, and 2) if one goes down, the other keeps working. I had a few ideas, but they all seem to have flaws. You can't set up BIND to control multilink aggregation and failover; that's not what it does. Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Bind 9 (Was: bsdstats) - fatal error: RUNTIME_CHECK(((pthread_mutex_destroy(((&manager->lock))) == 0)
On Mon, Jul 27, 2009 at 07:37:26PM -0800, Mel Flynn wrote: > On Monday 27 July 2009 18:35:17 Marc G. Fournier wrote: > > --On Monday, July 27, 2009 14:07:44 -0800 Mel Flynn > > > > wrote: > > > On Monday 27 July 2009 13:17:51 Anton Shterenlikht wrote: > > >> On ia64 8.0-beta1 SMP, running bsdstats-5.4_2, > > >> I get this error: > > >> > > >> # /usr/local/etc/periodic/monthly/300.statistics > > >> /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/task.c:1023: fatal > > >> error: RUNTIME_CHECK(((pthread_mutex_destroy(((&manager->lock))) == 0) ? > > >> 0 > > >> > > >> : 34) == 0) failed > > > > > > That error from bind, > > > > > >> [:1: unexpected operator > > > > > > Is not handled gracefully in the bsdstats script. > > > > Is there something I can do to improve the script to handle it better? > > Well, if OP can provide sh -x /usr/local/etc/periodic/monthly/300.statistics > output, it's easier to see which variable is empty as a result of a resolver > error. Then fix the test expression and either exit or use a retry_x_times > mechanism. # script zzz sh -x /usr/local/etc/periodic/monthly/300.statistics -nodelay Script started on Tue Jul 28 11:14:53 2009 + [ -r /etc/defaults/periodic.conf ] + . /etc/defaults/periodic.conf + periodic_conf_files='/etc/periodic.conf /etc/periodic.conf.local' + local_periodic=/usr/local/etc/periodic + daily_output=root + daily_show_success=YES + daily_show_info=YES + daily_show_badconfig=NO + daily_clean_disks_enable=NO + daily_clean_disks_files='[#,]* .#* a.out *.core *.CKP .emacs_[0-9]*' + daily_clean_disks_days=3 + daily_clean_disks_verbose=YES + daily_clean_tmps_enable=NO + daily_clean_tmps_dirs=/tmp + daily_clean_tmps_days=3 + daily_clean_tmps_ignore='.X*-lock .X11-unix .ICE-unix .font-unix .XIM-unix' + daily_clean_tmps_ignore='.X*-lock .X11-unix .ICE-unix .font-unix .XIM-unix quota.user quota.group' + daily_clean_tmps_verbose=YES + daily_clean_preserve_enable=YES + daily_clean_preserve_days=7 + daily_clean_preserve_verbose=YES + daily_clean_msgs_enable=YES + daily_clean_msgs_days='' + daily_clean_rwho_enable=YES + daily_clean_rwho_days=7 + daily_clean_rwho_verbose=YES + daily_clean_hoststat_enable=YES + daily_backup_passwd_enable=YES + daily_backup_aliases_enable=YES + daily_calendar_enable=NO + daily_accounting_enable=YES + daily_accounting_compress=NO + daily_accounting_flags=-q + daily_accounting_save=3 + daily_news_expire_enable=YES + daily_status_disks_enable=YES + daily_status_disks_df_flags='-l -h' + daily_status_zfs_enable=NO + daily_status_ata_raid_enable=NO + daily_status_gmirror_enable=NO + daily_status_graid3_enable=NO + daily_status_gstripe_enable=NO + daily_status_gconcat_enable=NO + daily_status_network_enable=YES + daily_status_network_usedns=YES + daily_status_rwho_enable=YES + daily_status_mailq_enable=YES + daily_status_mailq_shorten=NO + daily_status_include_submit_mailq=YES + daily_status_security_enable=YES + daily_status_mail_rejects_enable=YES + daily_status_mail_rejects_logs=3 + daily_status_mail_rejects_shorten=NO + daily_status_named_enable=YES + daily_status_named_usedns=YES + daily_status_ntpd_enable=NO + daily_queuerun_enable=YES + daily_submit_queuerun=YES + daily_local=/etc/daily.local + daily_status_security_inline=NO + daily_status_security_output=root + daily_status_security_noamd=NO + daily_status_security_logdir=/var/log + daily_status_security_diff_flags='-b -u' + daily_status_security_chksetuid_enable=YES + daily_status_security_chkmounts_enable=YES + daily_status_security_chkuid0_enable=YES + daily_status_security_passwdless_enable=YES + daily_status_security_logincheck_enable=YES + daily_status_security_ipfwdenied_enable=YES + daily_status_security_ipfdenied_enable=YES + daily_status_security_pfdenied_enable=YES + daily_status_security_ipfwlimit_enable=YES + daily_status_security_ipf6denied_enable=YES + daily_status_security_kernelmsg_enable=YES + daily_status_security_loginfail_enable=YES + daily_status_security_tcpwrap_enable=YES + weekly_output=root + weekly_show_success=YES + weekly_show_info=YES + weekly_show_badconfig=NO + weekly_locate_enable=YES + weekly_whatis_enable=YES + weekly_catman_enable=NO + weekly_noid_enable=NO + weekly_noid_dirs=/ + weekly_status_pkg_enable=NO + pkg_version=pkg_version + pkg_version_index=/usr/ports/INDEX-8 + weekly_local=/etc/weekly.local + monthly_output=root + monthly_show_success=YES + monthly_show_info=YES + monthly_show_badconfig=NO + monthly_accounting_enable=YES + monthly_local=/etc/monthly.local + [ -z '' ] + source_periodic_confs_defined=yes + source_periodic_confs + local i sourced_files + sourced_files=:/etc/periodic.conf: + [ -r /etc/periodic.conf ] + . /etc/periodic.conf + monthly_statistics_enable=YES + monthly_statistics_report_devices=YES + monthly_statistics_report_ports=YES + sourced_files=:/etc/periodic.conf::/etc/periodic.conf.local: + [ -r /etc/periodic.conf.local ] + periodic_conf=/etc/periodic.conf + umask + oldmask=0022 + umask 066 + version=5.4 + chec
Re: Bind 9 (Was: bsdstats) - fatal error: RUNTIME_CHECK(((pthread_mutex_destroy(((&manager->lock))) == 0)
On Monday 27 July 2009 18:35:17 Marc G. Fournier wrote: > --On Monday, July 27, 2009 14:07:44 -0800 Mel Flynn > > wrote: > > On Monday 27 July 2009 13:17:51 Anton Shterenlikht wrote: > >> On ia64 8.0-beta1 SMP, running bsdstats-5.4_2, > >> I get this error: > >> > >> # /usr/local/etc/periodic/monthly/300.statistics > >> /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/task.c:1023: fatal > >> error: RUNTIME_CHECK(((pthread_mutex_destroy(((&manager->lock))) == 0) ? > >> 0 > >> > >> : 34) == 0) failed > > > > That error from bind, > > > >> [:1: unexpected operator > > > > Is not handled gracefully in the bsdstats script. > > Is there something I can do to improve the script to handle it better? Well, if OP can provide sh -x /usr/local/etc/periodic/monthly/300.statistics output, it's easier to see which variable is empty as a result of a resolver error. Then fix the test expression and either exit or use a retry_x_times mechanism. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Bind 9 (Was: bsdstats) - fatal error: RUNTIME_CHECK(((pthread_mutex_destroy(((&manager->lock))) == 0)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Monday, July 27, 2009 14:07:44 -0800 Mel Flynn wrote: > On Monday 27 July 2009 13:17:51 Anton Shterenlikht wrote: >> On ia64 8.0-beta1 SMP, running bsdstats-5.4_2, >> I get this error: >> >> # /usr/local/etc/periodic/monthly/300.statistics >> /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/task.c:1023: fatal >> error: RUNTIME_CHECK(((pthread_mutex_destroy(((&manager->lock))) == 0) ? 0 >> : 34) == 0) failed > > That error from bind, > >> [:1: unexpected operator > > Is not handled gracefully in the bsdstats script. Is there something I can do to improve the script to handle it better? - -- Marc G. FournierHub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scra...@hub.org MSN . scra...@hub.org Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpuY+UACgkQ4QvfyHIvDvOquwCdGpyNjkbx2e/jt9TB48RX6JrD mJEAoL+l0a5UI3xCX/2/F+MJB5hPgIR/ =uH7U -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Bind 9 (Was: bsdstats) - fatal error: RUNTIME_CHECK(((pthread_mutex_destroy(((&manager->lock))) == 0)
On Monday 27 July 2009 13:17:51 Anton Shterenlikht wrote: > On ia64 8.0-beta1 SMP, running bsdstats-5.4_2, > I get this error: > > # /usr/local/etc/periodic/monthly/300.statistics > /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/task.c:1023: fatal > error: RUNTIME_CHECK(((pthread_mutex_destroy(((&manager->lock))) == 0) ? 0 > : 34) == 0) failed That error from bind, > [:1: unexpected operator Is not handled gracefully in the bsdstats script. The annoyance is that ISC Bind finds it not useful to print errno, which is what you'd need to figure out why this lock can't be destroyed. It is however a programming error in bind, or a rare case of stack corruption by the kernel. If you see this error a lot or can reliably reproduce it, I'd file a PR. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: BIND
Jack Raats wrote: This morning I tried to install BIND, the DNS server. I downloaded the handbook (English version) and tried to follow the instructions giving in the handbook. But the handbook is outdated OR FreeBSD 7.2-RELEASE-p2 is not correct. I'm missing make-localhost in /etc/namedb. Can any help me??? Your copy of the handbook out of date. Try following these instructions: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-dns.html Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Bind to Localhost from Jail
On Fri, Mar 13, 2009 at 12:59 PM, Dave wrote: > Hi all, > > I'm trying to get cPanel installed on my host, and to run it from jail. > The > installer script that cPanel provides, however, seems to be confused by the > fact that it cannot test the daemons it has installed by checking if they > are listening on localhost. Is there any way to allow services running in > jail to bind on localhost? > > I noticed that there was a patch committed to the stable branch that > allowed > for jails to have multiple or no ip addresses. Is this perhaps a solution > to the problem I've outlined above? > > If anyone can provide any insight it would be much appreciated! > > Thanks, > Dave > How does any system to know if you're talking to the host localhost, or the jail's localhost? I see a logical flaw that would make that somewhat difficult. Since the point of IP addresses are supposed to be unique (let's not get into rfc1918 addresses, or my localhost has your localhost IP), how can that be safely determined? Now, if it was 127.0.0.10 on the host, and 127.0.0.1 on the jail, and 127.0.0.2 on a 2nd jail, etc -- that could work. can you trick cPanel by using /etc/hosts to say localhost (name of a machine) maps to your jail's IP? Can you provide any other workaround that will allow such scripts to dynamically and correctly find the information they're looking for? Couple ideas, HTH --Tim ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Bind BIND 9.3.5 configuration
On Sun, Oct 19, 2008 at 06:22:27AM -0700, Kevin wrote: > I installed bind 9.3.5 on my new FreeBSD 6.3 server. I copied > named.conf directly from my old server (originally from the Internet), Since you've done this, you should use mergemaster to interactively merge the changes in the system default src/etc/namedb/named.conf into yours. This should solve any errors you receive. > Q1. Bind gave me errors on the following lines due to missing files, I > have only empty.db, localhost-forward.db and localhost-reverse.db. > Should I modify all localhost.rev to localhost-reverse.db? Is it safe > to remove all lines about localhost-v6.rev? See above. > Q2. Regarding the following lines, it seems that I should uncomment > the forwarders, is it the the same IP in /etc/resolv.conf? Or I need > to ask my ISP? > --- > // If you've got a DNS server around at your upstream provider, enter > // its IP address here, and enable the line below. This will make you > // benefit from its cache, thus reduce overall DNS traffic in the Internet. > /* > forwarders { > 127.0.0.1; > }; > */ No, you don't need to ask your ISP, and no, you don't need to enable forwarders unless you want to. You should read the official BIND docs on what forwarders do, to get the full understanding. :-) > Q3. About the following comments, should I enable a local name server? > and how to do it exactly? I have added 127.0.0.1 in resolv.conf, but > how to enable it in /etc/rc.conf? > -- > // If you enable a local name server, don't forget to enter 127.0.0.1 > // first in your /etc/resolv.conf so this server will be queried. > // Also, make sure to enable it in /etc/rc.conf. > > I have used this configuration for several years and always quite > confused. I have put my named.conf at > http://www.msofficeforums.com/named.conf . Please give me some > suggestions. Thanks! You should put "nameserver 127.0.0.1" in /etc/resolv.conf, that way your own local machine as a resolver (e.g. will rely on the BIND/named daemon). /etc/rc.conf is used to enable BIND/named on startup. You should place the following there: named_enable="yes" -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND DNS Patching on 6.1, 6.2
Grant Peel wrote: Hi all, Thanks to Lars I have come up with the following (to upgrade BIND for the DNS caching issue)...(short of updateing all source). Download the latest port BIND95.9.5.x (p2 I think), 9.5.0.2 -- correct. Extract it to the ports directory, make -DWITH_REPLACE_BASE You should get an OPTIONS dialogue here which will allow you to achieve the required result. Use 'make config' to force the issue if necessary. make install make clean Is the above correct? Yes, that will work just fine. Also, Will the installation leave all my current (BIND) configs alone? It will not trash /etc/namedb/named.conf -- actually, I think it won't touch anything under /etc/namedb so it should 'just work' with your existing configuration. Remember to remove any 'port 53' clauses from 'query source' statements in named.conf or this will all have been for nothing. If you're going to do the 'REPLACE_BASE' thing, then you should add WITHOUT_BIND=yes to /etc/make.conf (/etc/src.conf in 7.x and above) -- otherwise you'll revert to the system version of BIND whenever you update. There are half a dozen BIND related make flags that you can pick and choose from if you want finer control. Alternatively, you can leave the base system as-is, install the port under /usr/local as usual, and just use variables like the following in /etc/rc.conf: named_enable="YES" named_program="/usr/local/sbin/named" named_flags="-c /etc/namedb/named.conf" This means you'll run named-2.5.0.2 from the port (which is the important bit) but unless you fiddle with your $PATH, you'll tend to get all the adjunct programs like dig, host, rndc from the base system. Either way, it should all be pretty seamless. Which way you choose is a matter of taste and convenience rather than necessity. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: BIND DNS Patching on 6.1, 6.2
Hi all, Thanks to Lars I have come up with the following (to upgrade BIND for the DNS caching issue)...(short of updateing all source). Download the latest port BIND95.9.5.x (p2 I think), Extract it to the ports directory, make -DWITH_REPLACE_BASE make install make clean Is the above correct? Also, Will the installation leave all my current (BIND) configs alone? -Grant - Original Message - From: "Lars Kristiansen" <[EMAIL PROTECTED]> To: "gpeel" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, August 29, 2008 8:38 PM Subject: Re: BIND DNS Patching on 6.1, 6.2 gpeel skrev: I was thinking I would try the BIND959.5.0 port, but it apprears that this version is still vulneralbe. The port dns/bind95 is patched: $ named -version BIND 9.5.0-P2 Easily installed with the option WITH_REPLACE_BASE. Regards, Lars ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND DNS Patching on 6.1, 6.2
Grant Peel skrev: Lars, Thanks for the reply. I have installed many hundreds of ports, but an feeling a little nervouse about this one. Would you mind creating a simplified step by step for how to perform this one? If so, Please include the make lines ... Thanks a billion, -Grant iirc, all I did at the time was to read the ports Makefile and other relevant files, then portinstall -p and select "Replace base BIND with this version" when the options screen is displayed. Then restart named and check that everything is working like it should. dig @localhost +short porttest.dns-oarc.net TXT will hopefully now give a result that includes the word GREAT. Lars - Original Message - From: "Lars Kristiansen" <[EMAIL PROTECTED]> To: "gpeel" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, August 29, 2008 8:38 PM Subject: Re: BIND DNS Patching on 6.1, 6.2 gpeel skrev: I was thinking I would try the BIND959.5.0 port, but it apprears that this version is still vulneralbe. The port dns/bind95 is patched: $ named -version BIND 9.5.0-P2 Easily installed with the option WITH_REPLACE_BASE. Regards, Lars ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND DNS Patching on 6.1, 6.2
Lars, Thanks for the reply. I have installed many hundreds of ports, but an feeling a little nervouse about this one. Would you mind creating a simplified step by step for how to perform this one? If so, Please include the make lines ... Thanks a billion, -Grant - Original Message - From: "Lars Kristiansen" <[EMAIL PROTECTED]> To: "gpeel" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, August 29, 2008 8:38 PM Subject: Re: BIND DNS Patching on 6.1, 6.2 gpeel skrev: I was thinking I would try the BIND959.5.0 port, but it apprears that this version is still vulneralbe. The port dns/bind95 is patched: $ named -version BIND 9.5.0-P2 Easily installed with the option WITH_REPLACE_BASE. Regards, Lars ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND DNS Patching on 6.1, 6.2
gpeel skrev: I was thinking I would try the BIND959.5.0 port, but it apprears that this version is still vulneralbe. The port dns/bind95 is patched: $ named -version BIND 9.5.0-P2 Easily installed with the option WITH_REPLACE_BASE. Regards, Lars ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND DNS Patching on 6.1, 6.2
Hi Again, When I posted this question originally, I had forgotten that I had a devel server running FreeBSD 6.2-RELEASE. I tried the 6.3 patch, and it would not make properly. I was thinking I would try the BIND959.5.0 port, but it apprears that this version is still vulneralbe. So I suppose the only question is, what branch + version should one upgrade to to secure this. (I assume 6.3 RELENG or 6 Stable). COmments please, -Grant On Fri, 29 Aug 2008 14:29:13 -0400, gpeel wrote > Hi all, > > I have ten webservers that I would like nothing more than to update > to 6.3 or > 7.x > > But right now I just dont have time. > > I was wondering if anyone has tried the patches BIND DNS Poioning > listed on the freebsd homepage (security advisories) on 6.1 and/or > 6.2 and if they worked OK. > > -Grant > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND won't resolve my IPs (not upstream or something?)
At 05:41 AM 8/9/2008, Redd Vinylene wrote: I got this FreeBSD server called mother (80.252.2.2). On it, I've made two jails, camel (80.252.2.3) and box (80.252.2.4 through to 80.252.2.127). The problem is that reverse lookups for any of the IPs preceding .4 on box fails. If I connect to IRC with .5 for instance, it times out and reverts back to .4, whose lookup works just fine. BIND runs on camel. Maybe the problem is that BIND is not upstream for all those IPs? (I don't know what that means, a friend just told me) Or that I haven't configured the reverse for any of the other IPs? I would really like to keep BIND running on camel, as its dedicated to all my vital network services, whereas box is the home of all my users, and thus expendable ;) Is there any way to modify BIND on camel, or must I set up an additional one on box? My (hopefully) relevant configuration files can be found here -- http://pastie.org/250469 -- much obliged, and thanks! You need to check that you have zone files for both forward and reverse lookups, and those zones are defined in named.conf -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND won't resolve my IPs (not upstream or something?)
At 06:55 AM 8/9/2008, Redd Vinylene wrote: I'm pretty sure I do, though my apologies if I'm wrong, did you check my pastie? On Sat, Aug 9, 2008 at 1:48 PM, Derek Ragona <[EMAIL PROTECTED]> wrote: > At 05:41 AM 8/9/2008, Redd Vinylene wrote: > > I got this FreeBSD server called mother (80.252.2.2). On it, I've made > two jails, camel (80.252.2.3) and box (80.252.2.4 through to > 80.252.2.127). The problem is that reverse lookups for any of the IPs > preceding .4 on box fails. If I connect to IRC with .5 for instance, > it times out and reverts back to .4, whose lookup works just fine. > BIND runs on camel. Maybe the problem is that BIND is not upstream for > all those IPs? (I don't know what that means, a friend just told me) > Or that I haven't configured the reverse for any of the other IPs? I > would really like to keep BIND running on camel, as its dedicated to > all my vital network services, whereas box is the home of all my > users, and thus expendable ;) Is there any way to modify BIND on > camel, or must I set up an additional one on box? My (hopefully) > relevant configuration files can be found here -- > http://pastie.org/250469 -- much obliged, and thanks! > > You need to check that you have zone files for both forward and reverse > lookups, and those zones are defined in named.conf > > -Derek > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. Well, I never let my read of these files suffice. You should check them with the tools from bind: named-checkconf nemed-checkzone If they pass those tests, then check the resolution using just a single ip that is NOT jailed on this server using dig or nslookup. If those are working then adjust your jails. If you go step-by-step you will quickly get it working. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND won't resolve my IPs (not upstream or something?)
I'm pretty sure I do, though my apologies if I'm wrong, did you check my pastie? On Sat, Aug 9, 2008 at 1:48 PM, Derek Ragona <[EMAIL PROTECTED]> wrote: > At 05:41 AM 8/9/2008, Redd Vinylene wrote: > > I got this FreeBSD server called mother (80.252.2.2). On it, I've made > two jails, camel (80.252.2.3) and box (80.252.2.4 through to > 80.252.2.127). The problem is that reverse lookups for any of the IPs > preceding .4 on box fails. If I connect to IRC with .5 for instance, > it times out and reverts back to .4, whose lookup works just fine. > BIND runs on camel. Maybe the problem is that BIND is not upstream for > all those IPs? (I don't know what that means, a friend just told me) > Or that I haven't configured the reverse for any of the other IPs? I > would really like to keep BIND running on camel, as its dedicated to > all my vital network services, whereas box is the home of all my > users, and thus expendable ;) Is there any way to modify BIND on > camel, or must I set up an additional one on box? My (hopefully) > relevant configuration files can be found here -- > http://pastie.org/250469 -- much obliged, and thanks! > > You need to check that you have zone files for both forward and reverse > lookups, and those zones are defined in named.conf > > -Derek > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. -- http://www.home.no/reddvinylene ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND won't resolve my IPs (not upstream or something?)
Maybe mother's /etc/pf.conf could also be of relevance? - camel="80.252.2.3" box="80.252.2.4" ext_if="rl0" set block-policy return set skip on { lo0 } scrub in pass out keep state block in pass in on $ext_if inet proto tcp from any to any port { 22 } keep state pass in on $ext_if inet proto tcp from any to $camel port { 25, 80, 110 } keep state pass in on $ext_if inet proto udp from any to $camel port 53 keep state pass in on $ext_if inet proto tcp from any to $box port { 113, 6000: } keep state pass in on $ext_if inet proto icmp from any to any keep state - Thanks. On Sat, Aug 9, 2008 at 12:41 PM, Redd Vinylene <[EMAIL PROTECTED]> wrote: > I got this FreeBSD server called mother (80.252.2.2). On it, I've made > two jails, camel (80.252.2.3) and box (80.252.2.4 through to > 80.252.2.127). The problem is that reverse lookups for any of the IPs > preceding .4 on box fails. If I connect to IRC with .5 for instance, > it times out and reverts back to .4, whose lookup works just fine. > BIND runs on camel. Maybe the problem is that BIND is not upstream for > all those IPs? (I don't know what that means, a friend just told me) > Or that I haven't configured the reverse for any of the other IPs? I > would really like to keep BIND running on camel, as its dedicated to > all my vital network services, whereas box is the home of all my > users, and thus expendable ;) Is there any way to modify BIND on > camel, or must I set up an additional one on box? My (hopefully) > relevant configuration files can be found here -- > http://pastie.org/250469 -- much obliged, and thanks! > > -- > http://www.home.no/reddvinylene > -- http://www.home.no/reddvinylene ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[RESOLVED]Re: bind sdb using ldap: load zone creating database failure
Ok, I got it zone "domain.com" { type master; database "ldap ldap://192.168.0.2/ou=domain.com,ou=dns,o=domain,dc=com 172800"; }; works fine. by the way, what does mean this number? 172800? rvenne a écrit : Hi list, I'm trying to use [EMAIL PROTECTED] 7.0_releng on a openldap [EMAIL PROTECTED] backend. openldap works fine. but I'm unable to make work bind. here's my named.conf options { directory "/etc/namedb"; pid-file"/var/run/named/pid"; statistics-file "/var/stats/named.stats"; listen-on { 127.0.0.1; 192.168.0.194; }; listen-on-v6 { none; }; //forward only; forwarders { 192.168.0.2; }; allow-query { 127.0.0.1; 0.0.0.0/0; }; allow-recursion { 127.0.0.1; }; }; zone "domain.com" { type master; database "ldap ldap://192.168.0.2/ou=domain.com,ou=dns,o=domain,dc=com";; }; named gives followed errors: domain.com/IN: loading zone: creating database: failure regards -- Richard VENNE IT Administrator Administrateur réseaux système & sécurité Afin de respecter de l'environnement, merci de n'imprimer cet email qu'en cas de nécessité absolue. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind DNS
On May 22, 2008, at 9:10 PM, Ruel Luchavez wrote: Hi ALL, Is it possible in BIND DNS to block images in a certain sites? like for example the popular friends site ( friendster), i want to block most images in that site so that client will be irritated that their images don't load perfectly. but s till they can visit their site? DNS is not the right level to be doing that unless you know that the images are actually served from a different server than the other content on the site (which is unlikely). An HTTP proxy, Squid in particular, will be the right tool. About a year ago, I saw a description where someone had put in a filter in Squid to blur or rotate all images. The screen shots of that where hilarious, but I can't remember exactly where this was posted. Cheers, -j ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind DNS
At 09:07 AM 5/23/2008, Steve Bertrand wrote: Derek Ragona wrote: At 09:10 PM 5/22/2008, Ruel Luchavez wrote: Hi ALL, Is it possible in BIND DNS to block images in a certain sites? like for example the popular friends site ( friendster), i want to block most images in that site so that client will be irritated that their images don't load perfectly. but s till they can visit their site? Any idea guys? thans define in your hosts any host or URL you want to block as the localhost, 127.0.0.1 You can google for whole host files to use to block a bunch of different annoying sites. I assumed by the OP's original message that this was a workplace-type environment, and figured that he wouldn't want to hand-manage this type of thing. Also, pardon my ignorance, but if you were to DNS redirect a domain name to a specific IP with BIND, wouldn't you have to create a DNS zone for each domain name? Steve no, you usually have /etc/nsswitch.conf set to check files before dns, so hosts is checked first. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind DNS
Derek Ragona wrote: At 09:10 PM 5/22/2008, Ruel Luchavez wrote: Hi ALL, Is it possible in BIND DNS to block images in a certain sites? like for example the popular friends site ( friendster), i want to block most images in that site so that client will be irritated that their images don't load perfectly. but s till they can visit their site? Any idea guys? thans define in your hosts any host or URL you want to block as the localhost, 127.0.0.1 You can google for whole host files to use to block a bunch of different annoying sites. I assumed by the OP's original message that this was a workplace-type environment, and figured that he wouldn't want to hand-manage this type of thing. Also, pardon my ignorance, but if you were to DNS redirect a domain name to a specific IP with BIND, wouldn't you have to create a DNS zone for each domain name? Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind DNS
At 09:10 PM 5/22/2008, Ruel Luchavez wrote: Hi ALL, Is it possible in BIND DNS to block images in a certain sites? like for example the popular friends site ( friendster), i want to block most images in that site so that client will be irritated that their images don't load perfectly. but s till they can visit their site? Any idea guys? thans define in your hosts any host or URL you want to block as the localhost, 127.0.0.1 You can google for whole host files to use to block a bunch of different annoying sites. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind DNS
are images on different serwer than rest of site? On Fri, 23 May 2008, Ruel Luchavez wrote: Hi ALL, Is it possible in BIND DNS to block images in a certain sites? like for example the popular friends site ( friendster), i want to block most images in that site so that client will be irritated that their images don't load perfectly. but s till they can visit their site? Any idea guys? thans ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind DNS
Is it possible in BIND DNS to block images in a certain sites? like for example the popular friends site ( friendster), i want to block most images in that site so that client will be irritated that their images don't load perfectly. but s till they can visit their site? Any idea guys? DNS is a name to address resolution protocol. It has no knowledge of web content. What you are after is some sort of web content filter. For home use, I use Squid and DansGuardian (both in ports). Still though, it's very difficult to block only *certain* images, and not others from a particular site. Regards, Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bind: Can't assign requested address using ssh (or anything else) -- resolution
> > $ ssh -X -N -L 127.0.0.3:13390:192.168.1.44:3390 [EMAIL PROTECTED] > > [EMAIL PROTECTED]'s password: > > bind: Can't assign requested address > > channel_setup_fwd_listener: cannot listen to port: 13390 > > Could not request local forwarding. > > Ofcourse it fails, you are trying to bind to address 127.0.0.3, > however there is no such address assigned to a local network > interface. Either: > > You don't explain what this 127.0.0.3 is. This does it. > 2) ifconfig lo0 add 127.3/32 Thanks for responding! The vpn software I need to use requires me to configure and bind a VPN connection from 127.0.0.x:port to the loopback. It is a handy way of grabbing an entirely unique IP that doesn't collide with whatever network you're on. Of course, it probably isn't the best idea if a bunch of different apps start to pull stuff like this -- but I wasn't the brainiac that came up with this idea. Anyway, it seems to be a fairly common way of doing this, so I'm explaining in detail to benefit future searches. Some methods (SSH) allow me to manually select the IP/port, so for my example I use it. Others (Juniper Networks) just go and pick the IP for me, and can assign any number of connections depending upon configuration. In a Windows world, since there're no controls and stupid things are allowed to happen, the IP address/port assignment is done on the fly, and you then have to view the active VPN connections to figure out what IP address/port are in use. With a real OS, privileged things like this need to be done by a privileged user before the client can assign to it. Since they don't change without human intervention (the number is permanent based upon the order they load -- 127.2, 127.3, etc.) and are assigned in a logical fashion, I should be able to bind the new addresses that it will use to lo0 and it should Just Work. And it does. tsclient can now load and get me onto the Windows Server I need to control. It's a hollow victory -- I feel so *dirty* when I work with Windows, but I have to if I want to get paid... The Juniper Network client info: ===setup information RDP Direct option: Remote Server: Client Port: 33890 Server Port: 3389 == Restarted the Secure Application manager. =error info=== In the Secure Application Manager Window, when I click on the Details Tab. I see the application I added with an error: cannot bind to the port 33890. after ifconfig== Now it works. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bind: Can't assign requested address using ssh (or anything else)
On Monday 21 January 2008 22:00:33 perlcat wrote: > Trying to access a vpn using ssh on 6.2 - STABLE. Haven't found an > answer anywhere, and so I must be totally missing the right questions to > ask or configurations to look at. > > This problem is consistent regardless of port chosen or access method. I > can duplicate at will with ssh. Here's the command that fails: > > $ ssh -X -N -L 127.0.0.3:13390:192.168.1.44:3390 [EMAIL PROTECTED] > [EMAIL PROTECTED]'s password: > bind: Can't assign requested address > channel_setup_fwd_listener: cannot listen to port: 13390 > Could not request local forwarding. Ofcourse it fails, you are trying to bind to address 127.0.0.3, however there is no such address assigned to a local network interface. Either: 1) change 127.0.0.3 to 127.0.0.1 You don't explain what this 127.0.0.3 is. 2) ifconfig lo0 add 127.3/32 HTH, Nikos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind configuration in FreeBSD
On Fri, Oct 05, 2007 at 05:29:39PM +0500, Narek Gharibyan wrote: > Hi, Please don't top-post. > I as know default version (without port upgrading) is Bind 9.3.3 in Freebsd > 6.2. You can see the version, executing named -v command. Do a > ps -ax | grep named > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of dhaneshk k > Sent: Friday, October 05, 2007 5:09 PM > To: freebsd-questions@freebsd.org > Subject: Bind configuration in FreeBSD > > Hi friends , > > I have a FreeBSD fresh installation in a new server machine. > >Here I wants to run my DNS server , by default I found the in > /etc/namedb dir, named.conf file & master dir etc in the m/c after > OS installation , so I configured my DNS entries(I mean named.conf and > zone file for my domain I configured ) , and after that I tried to start > /etc/rc.d/named start > but no message that it is starting or not . I think that you made a small mistake. If you want to start a daemon, you have to enable it in /etc/rc.conf, otherwise it won't start (every rc script sources /etc/rc.conf with the line 'load_rc_config'). Try adding named_enable="YES" to /etc/rc.conf, and try again. If you look in /etc/defaults/rc.conf, and search for 'named', you can see that it is disabled by default. You can also see there the rest of the options you can set for named. Hope this helps, Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgphjyH0ZdKS9.pgp Description: PGP signature
RE: Bind configuration in FreeBSD
Hi, I as know default version (without port upgrading) is Bind 9.3.3 in Freebsd 6.2. You can see the version, executing named -v command. Do a ps -ax | grep named and see whether named is running or not. Also you can find the Bind logs in /var/named/var/log directory (chrooted directory), if it is running check your configuration with dig or nslookup if not - use /usr/sbin/named-checkconf and /usr/sbin/named-checkzone to inspect the problem. Please post your error text to help you furthermore. Regards -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dhaneshk k Sent: Friday, October 05, 2007 5:09 PM To: freebsd-questions@freebsd.org Subject: Bind configuration in FreeBSD Hi friends , I have a FreeBSD fresh installation in a new server machine. Here I wants to run my DNS server , by default I found the in /etc/namedb dir, named.conf file & master dir etc in the m/c after OS installation , so I configured my DNS entries(I mean named.conf and zone file for my domain I configured ) , and after that I tried to start /etc/rc.d/named start but no message that it is starting or not . I would like to ask you whether I have to install , bind 8 or bind 9 through /usr/ports/dns to make this machine as a DNS server or by default (I mean fresh installation) the bind is coming? (because I can see /etc/namedb dir and named.conf file ,master dir , etc ... there) pls guide me to setup Bind in FreeBSD6.2 to make A DNS server for my own domain thanks in Advance kk _ Search from any Web page with powerful protection. Get the FREE Windows Live Toolbar Today! http://toolbar.live.com/?mkt=en-in__ _ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind configuration in FreeBSD
You need to enable the service: $ sudo vi /etc/rc.conf >> named_enable="YES" :wq $ sudo /etc/rc.d/named restart The bind in-tree is 9.3.4 and the chroot is already setup for you by default. You don't want to go installing a bitrot version from Ports. ~BAS On Fri, 2007-10-05 at 12:08 +, dhaneshk k wrote: > but no message that it is starting or not . ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND to listen on all interfaces?
On Tue, Jul 03, 2007, Nejc Škoberne wrote: > I also tried to specify the ADSL IP address in named.conf (it is static), > but it is > still a no go. I don't have such problems with other daemons! Any ideas? Is the interface already up when you are starting BIND? I guess it is not. I haven't tested myself but you might try to add the very same IP you use for your ADSL interface as an alias to the lo0 device. This way the IP is available all the time, thus BIND should be able to listen on it. While it might look strange to have to same IP on two different interfaces (lo0 and ADSL in your case) IIRC it should work flawlessly. Just give it a try and report back if it works or not. -cs ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND to listen on all interfaces?
On Wed, Jul 04, 2007 at 03:14:28PM +1000, Mikhail Goriachev wrote: > Nejc Škoberne wrote: > > Hello, > > > > I am running BIND (from base system) on my FreeBSD 5.3 machine. The box is > > connected to outer world via ADSL connection (tun0 device). If the named is > > started when the machine is connected to the internet, then everything is > > OK, > > I get this by saying netstat -n -a: > > > > udp4 0 0 X.X.X.X.53 *.* > > udp4 0 0 127.0.0.1.53 *.* > > udp4 0 0 10.0.1.3.53*.* > > > > but at boot time, the named starts before the PPP connection is started, so > > the tun0 interface is not up yet. So that's why I get this: > > > > udp4 0 0 127.0.0.1.53 *.* > > udp4 0 0 10.0.1.3.53*.* > > > > In BIND manual, it says: > > > > "If no listen-on is specified, the server will listen on port 53 on all > > interfaces." > > > > I also tried to specify the ADSL IP address in named.conf (it is static), > > but it is > > still a no go. I don't have such problems with other daemons! Any ideas? > > > > An idea: Assuming you're using ppp, let it restart named after it > connects to the Internet. Have a /etc/ppp/ppp.linkup and put the > following or similar into it: > > adsl: > ! /etc/rc.d/named restart > > > Read the ppp man pages for further details. > > > Regards, > Mikhail. > > -- > Mikhail Goriachev > Webanoide > > Telephone: +61 (0)3 62252501 > Mobile Phone: +61 (0)4 38255158 > E-Mail: [EMAIL PROTECTED] > Web: www.webanoide.org Another option can be the use of interface-interval: interface-interval The server will scan the network interface list every interface-interval minutes. The default is 60 minutes. The maximum value is 28 days (40320 minutes). If set to 0, interface scanning will only occur when the configuration file is loaded. After the scan, the server will begin listening for queries on any newly discovered interfaces (provided they are allowed by the listen-on configuration), and will stop listening on interfaces that have gone away. (from BIND ARM). HTH, Yuri pgp8CM2KmWqHH.pgp Description: PGP signature
Re: BIND to listen on all interfaces?
Nejc Škoberne wrote: > Hello, > > I am running BIND (from base system) on my FreeBSD 5.3 machine. The box is > connected to outer world via ADSL connection (tun0 device). If the named is > started when the machine is connected to the internet, then everything is OK, > I get this by saying netstat -n -a: > > udp4 0 0 X.X.X.X.53 *.* > udp4 0 0 127.0.0.1.53 *.* > udp4 0 0 10.0.1.3.53*.* > > but at boot time, the named starts before the PPP connection is started, so > the tun0 interface is not up yet. So that's why I get this: > > udp4 0 0 127.0.0.1.53 *.* > udp4 0 0 10.0.1.3.53*.* > > In BIND manual, it says: > > "If no listen-on is specified, the server will listen on port 53 on all > interfaces." > > I also tried to specify the ADSL IP address in named.conf (it is static), but > it is > still a no go. I don't have such problems with other daemons! Any ideas? An idea: Assuming you're using ppp, let it restart named after it connects to the Internet. Have a /etc/ppp/ppp.linkup and put the following or similar into it: adsl: ! /etc/rc.d/named restart Read the ppp man pages for further details. Regards, Mikhail. -- Mikhail Goriachev Webanoide Telephone: +61 (0)3 62252501 Mobile Phone: +61 (0)4 38255158 E-Mail: [EMAIL PROTECTED] Web: www.webanoide.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND slave records not updating
On Tue, 2007-02-13 at 10:00 -0600, Derek Ragona wrote: > I run multiple FreeBSD versions with Bind and have not had a problem with > records being updated. Are you properly setting the new serial numbers in > the master record files? > Thanks. Do you mean the master zone files where the BSD server are pulling from. I update via a GUI on the server running Bluequartz GUI. The zone file serial number changes from 2007020501 to 2007021301 after changing one today. The other BSD server hosting slave records is pulling the updates fine, just this one that is not. Is there anywhere in the logs to find what is happening. All I've been able to find in logs is on the master server indicating notifies sent to the IP address of the problem server. -- Robert ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND slave records not updating
I run multiple FreeBSD versions with Bind and have not had a problem with records being updated. Are you properly setting the new serial numbers in the master record files? -Derek At 09:47 AM 2/13/2007, Robert Fitzpatrick wrote: I'm not a member of any bind list, so I was hoping to be able to ask my question here. I have primary DNS with bind 9.2.4 on Linux servers where there are web GUI's for management. I keep slave records on two FreeBSD servers that serve as our ns1 and ns2, one is 6.1 with the bind port bind9-9.3.3 and it works fine. The other is FreeBSD 5.4-RELEASE with bind9-base-9.3.4, not sure what the base difference is, can someone tell me? This 5.4 server is not updating when changes are made to the primary. I see in the logs on the primary that notifies are sent and the 9.3.3 server, which is at a different facility, updates within minutes, the 5.4 machine on the local network does not. I can't find any bind log information in /var/log/messages on the FreeBSD servers, where would that be? I have to remove the '.bak' zone file and restart the bind process, then it brings over the new zone file as it should re-creating the '.bak' file. I checked the perms on all the files involved, comparing to the 6.1 machine. The zone files all owned by the bind process user. zone "example.com" { type slave; file "slave/example.com.bak"; masters { 10.0.0.48; }; allow-query { 0.0.0.0/0; }; }; esmtp# ls -lah /var/named/etc/namedb/slave/tpghotels.com.bak -rw-r--r-- 1 bind wheel 635B Feb 13 08:19 /var/named/etc/namedb/slave/example.com.bak Again, this exact same setup on the other BSD server works perfectly. The allow-transfer on the primary seems to be working fine since deleting the zone file on the slave and restarting pulls the zone fine. This is our workaround for now, but a pain. Is there a problem with running the different bind9 versions? I can't really do anything about the primary server considering we rely on yum and recommended updates by the system repositories. So, should I keep my slave BSD boxes on that same version 9.2.4? Thanks in advance! -- Robert ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND tool for setting up secondary records?
On Friday 26 January 2007 10:50, Robert Fitzpatrick wrote: > I am not a member of a BIND list, so I thought I'd ask here first if > anyone knows of a script tool that will query a primary name server and > setup secondary records on another BIND server? Or any other solution > for doing mass entries of domains to a BIND server to setup secondary > records with the same primary master? If you set up a slave domain it will automatically query and stay in sync with the master nameserver. I use scripts on both ends for most new domains. Here's the files from the slave side: === begin addconf.sh === #!/bin/sh DATADIR="/etc/namedb/conf" TEMPLATE="/etc/namedb/templates/default.bind" usage() { echo "Usage: $0 \"domain.name\" [templatefile]" exit 1; } if [ "$2" ] ; then if [ -r $2 ] ; then TEMPLATE=$2 else usage fi fi if [ "$1" ] ; then DOMAIN=$1 else usage fi echo -n "Configuring ${DOMAIN} using ${TEMPLATE}.." cat ${TEMPLATE} | sed -e "s/%%DOMAIN%%/${DOMAIN}/g" > ${DATADIR}/${DOMAIN}.bind echo " done." === end addconf.sh === === begin default.bind === zone "%%DOMAIN%%" { type slave; file "slave/%%DOMAIN%%.bak"; masters { my.master.server.ip; }; allow-query { 0.0.0.0/0; }; }; === end default.bind === === begin make-conf.sh === #!/bin/sh inputfile=/etc/namedb/templates/named.conf.in outputfile=/etc/namedb/named.conf backupfile=/etc/namedb/backups/named.conf.old confdir=/etc/namedb/conf if [ -r ${outputfile} ] ; then echo "Backing up current file to ${backupfile}.." mv -f ${outputfile} ${backupfile} fi echo -n "Generating ${outputfile}".. cp -f ${inputfile} ${outputfile} for conffile in ${confdir}/*.bind; do echo "include \"${conffile}\";" >> $outputfile done echo " done." === end make-conf.sh === For named.conf.in you just want your normal named.conf file that doesn't include any of the domains defined in ${confdir}. Figuring out the rest of it I leave as an exercise for the reader, but I'm happy to answer specific questions. JN ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND 9.3.2 on FreeBSD 6.1-release-p2
Did you run it in foregroun debug mode or ktrace(1) it yet? Turn on querylog and see if you're getting worked? ~BAS On Tue, 2 Jan 2007, patrick wrote: I'm running BIND 9.3.2 on FreeBSD 6.1, and am noticing that it gets out of control after running for a while. PIDUID THR PRI NICE SIZERES STATETIME WCPU COMMAND 60480 53 1 1320 195M 194M RUN 41.7H 75.54% named After restarting it, its CPU usage goes back down to what it should be, as does its memory usage. I really don't want to babysit this process, so I'm trying to find the cause of this. I have "max-cache-size" set to "150M", as before I turned this on, this process would just grow and grow until it hit FreeBSD's limit and would stop responding all together, not to mention eating up as much CPU time as it could. I never had this problem at all with BIND 8, and am wondering if there's something I'm doing wrong with BIND 9 to have this problem? Has anyone else experienced this? Any help would be greatly appreciated. Patrick ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" l8* -lava (Brian A. Seklecki - Pittsburgh, PA, USA) http://www.spiritual-machines.org/ "...from back in the heady days when "helpdesk" meant nothing, "diskquota" meant everything, and lives could be bought and sold for a couple of pages of laser printout - and frequently were." ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bind problem
Hi Robin, On Tuesday 10 October 2006 16:22, Robin Tiwari wrote: > i've configured dns server in freeBSD 6.1 but when i query the server it > wont resolve my domain name. i've added in resolv.conf also and my bind > daemon is also running without any errors. i couldnt figure out the > problem. if any suggestion please help me Can you send us your configuration files (or at least the important parts of them)? -- Lothar pgph5hHaogxsc.pgp Description: PGP signature
Re: Bind problem
Lisa, Your forward file should be something like this: $TTL3600 @ IN SOA ns.jellico.com. dnsadmin.jellico.com. ( 2003071101 ; serial 3H ; refresh 1H ; retry 1W ; expiry 1D ); minimum ; DNS Servers @ IN NS ns.jellico.com. @ IN NS ns2.jellico.com. ; Machine Names localhost IN A127.0.0.1 mailIN A208.44.26.225 pop IN A208.44.26.225 @ IN A208.44.26.225 ; Aliases www IN CNAME@ ww IN CNAME@ w IN CNAME@ ; MX Record @ IN MX 10 mail.jellico.com. Just correct the IP's and add the rest of your hosts, and correct any names that may be incorrect. Make sure you name the file the same as bind is looking for in: /etc/namedb/named.conf If you have specific questions to any of the file entries you can email me directly. -Derek At 01:20 PM 7/11/2006, Lisa Casey wrote: Hi, The installed bind is not in /usr/local/bin that is where the port is installed. You might want to do a: # which bind and set rc.conf to the right value for the program. -Derek At 04:34 PM 7/10/2006, Lisa Casey wrote: - Original Message - From: "Jonathan Chen" <[EMAIL PROTECTED]> To: "Lisa Casey" <[EMAIL PROTECTED]> Cc: Sent: Monday, July 10, 2006 3:43 PM Subject: Re: Bind problem Did you remember to add: named_program="/usr/local/sbin/named" to /etc/rc.conf? Yes. /etc/rc.conf has the following lines for named: named_enable="YES" named_program="/usr/local/sbin/named" named_flags="-u bind -g bind -c /etc/namedb/named.conf" Lisa Casey This actually didn't quite answer the problem, but it did lead me in the right direction to solve it. which bind, of course, doesn't work and which named just gives me the path to the named executable as given in /etc.rc.conf But, this got me to thinking so I did a find / -name named -print And found something interesting. I have named executables in both /usr/local/sbin and /usr/sbin So I changed the line in /etc/rc.conf that read: named_program="/usr/local/sbin/named" to named_program="/usr/sbin/named" and rebooted the box. So far, so good. named -v gives me BIND 9.3.0 and in /var/messages the reboot info shows the same when named loads: Jul 11 13:40:50 netlink kernel: Mounting root from ufs:/dev/da0s1a Jul 11 13:40:50 netlink named[293]: starting BIND 9.3.0 -u bind -c /etc/namedb/n amed.conf -t /var/named Jul 11 13:40:51 netlink named[293]: command channel listening on 127.0.0.1#953 (It's also picking up the command channel, so I guess I did that right). I have one last problem (or at least I hope so!). I maybe ought to ask this in a bind newsgroup, but there are enough folks on this list running bind on FreeBSD that someone ought to know. Evidently Bind 9 doesn't like my zone files whereas Bind 8 was OK with them. A little background: My main domain name is jellico.comI also host several virtual domains using IP based virtual domains in Apache2. So each of my virtual domains has been assigned an IP address out of my Class C. In /etc/namedb/M (the directory where I keep my zone files that this DNS server is master for) I have (among other zones) jellico.com.db which is my forward file for the domain and 26.44.208.in-addr.arpa which is the reverse zone file for the domain. I have always had my virtual domains configured into my forward file (jellico.com.db) so as to enable forward DNS resolution on those. They are configured into jellico.com.db like this: jellico.tn.us. IN A 208.44.26.225 multi-226 IN A 208.44.26.226 multi-227 IN A 208.44.26.227 multi-228 IN A 208.44.26.228 multi-229 IN A 208.44.26.229 multi-230 IN A 208.44.26.230 tspma.com. IN A 208.44.26.231 copperhill.com. IN A 208.44.26.232 multi-233 IN A 208.44.26.233 www.jellico.net.IN A 208.44.26.234 multi-235 IN A 208.44.26.235 stair-way-to-heaven.com.IN A 208.44.26.236 multi-237 IN A 208.44.26.237 kcsvo.com. IN A 208.44.26.238 multi-239 IN A 208.44.26.239 multi-240 IN A 208.44.26.240 wingsofvictorychurch.org. IN A 208.44.26.241 multi-242 IN A 208.44.26.242 multi-243 IN A 208.44
Re: Bind problem
Hi, The installed bind is not in /usr/local/bin that is where the port is installed. You might want to do a: # which bind and set rc.conf to the right value for the program. -Derek At 04:34 PM 7/10/2006, Lisa Casey wrote: - Original Message - From: "Jonathan Chen" <[EMAIL PROTECTED]> To: "Lisa Casey" <[EMAIL PROTECTED]> Cc: Sent: Monday, July 10, 2006 3:43 PM Subject: Re: Bind problem Did you remember to add: named_program="/usr/local/sbin/named" to /etc/rc.conf? Yes. /etc/rc.conf has the following lines for named: named_enable="YES" named_program="/usr/local/sbin/named" named_flags="-u bind -g bind -c /etc/namedb/named.conf" Lisa Casey This actually didn't quite answer the problem, but it did lead me in the right direction to solve it. which bind, of course, doesn't work and which named just gives me the path to the named executable as given in /etc.rc.conf But, this got me to thinking so I did a find / -name named -print And found something interesting. I have named executables in both /usr/local/sbin and /usr/sbin So I changed the line in /etc/rc.conf that read: named_program="/usr/local/sbin/named" to named_program="/usr/sbin/named" and rebooted the box. So far, so good. named -v gives me BIND 9.3.0 and in /var/messages the reboot info shows the same when named loads: Jul 11 13:40:50 netlink kernel: Mounting root from ufs:/dev/da0s1a Jul 11 13:40:50 netlink named[293]: starting BIND 9.3.0 -u bind -c /etc/namedb/n amed.conf -t /var/named Jul 11 13:40:51 netlink named[293]: command channel listening on 127.0.0.1#953 (It's also picking up the command channel, so I guess I did that right). I have one last problem (or at least I hope so!). I maybe ought to ask this in a bind newsgroup, but there are enough folks on this list running bind on FreeBSD that someone ought to know. Evidently Bind 9 doesn't like my zone files whereas Bind 8 was OK with them. A little background: My main domain name is jellico.comI also host several virtual domains using IP based virtual domains in Apache2. So each of my virtual domains has been assigned an IP address out of my Class C. In /etc/namedb/M (the directory where I keep my zone files that this DNS server is master for) I have (among other zones) jellico.com.db which is my forward file for the domain and 26.44.208.in-addr.arpa which is the reverse zone file for the domain. I have always had my virtual domains configured into my forward file (jellico.com.db) so as to enable forward DNS resolution on those. They are configured into jellico.com.db like this: jellico.tn.us. IN A 208.44.26.225 multi-226 IN A 208.44.26.226 multi-227 IN A 208.44.26.227 multi-228 IN A 208.44.26.228 multi-229 IN A 208.44.26.229 multi-230 IN A 208.44.26.230 tspma.com. IN A 208.44.26.231 copperhill.com. IN A 208.44.26.232 multi-233 IN A 208.44.26.233 www.jellico.net.IN A 208.44.26.234 multi-235 IN A 208.44.26.235 stair-way-to-heaven.com.IN A 208.44.26.236 multi-237 IN A 208.44.26.237 kcsvo.com. IN A 208.44.26.238 multi-239 IN A 208.44.26.239 multi-240 IN A 208.44.26.240 wingsofvictorychurch.org. IN A 208.44.26.241 multi-242 IN A 208.44.26.242 multi-243 IN A 208.44.26.243 There are a few others, but you get the idea. I have also always had my virtual domains setup in my reverse file so as to enable reverse DNS resolution on these. This section of my reverse file looks like so: 225 IN PTR jellico.tn.us. 226 IN PTR multi-226.jellico.com. 227 IN PTR multi-227.jellico.com. 228 IN PTR multi-228.jellico.com. 229 IN PTR multi-229.jellico.com. 230 IN PTR multi-230.jellico.com. 231 IN PTR tspma.com. 232 IN PTR copperhill.com. 233 IN PTR multi-233.jellico.com. 234 IN PTR www.jellico.net. 234 IN PTR multi-234.jellico.com. 235 IN PTR multi-235.jellicocom. 236 IN PTR stairway-to-heaven.com. Bind 9 is OK with my reverse file, but it doesn't like any entry in my forward file that ends in a dot (so as not to append jellico.com to it). When I rebooted the box, as soon as the nameserver loads I get these error messages in /var/messages: Jul 11 13:40:51 netlink named[293]: M/jellico.com.db:222: ignoring out-of-zone d ata (mail.campbellcounty.com) Jul 11 13:40:51 netlink named[293]: M/jellico.com.db:224: ignoring out-of-zone d ata (campbellcounty.com) Jul 11 13:40:51 netlink named[293]: M/jellico.com.db:522: ignorin
Re: Bind problem
The installed bind is not in /usr/local/bin that is where the port is installed. You might want to do a: # which bind and set rc.conf to the right value for the program. -Derek At 04:34 PM 7/10/2006, Lisa Casey wrote: - Original Message - From: "Jonathan Chen" <[EMAIL PROTECTED]> To: "Lisa Casey" <[EMAIL PROTECTED]> Cc: Sent: Monday, July 10, 2006 3:43 PM Subject: Re: Bind problem Did you remember to add: named_program="/usr/local/sbin/named" to /etc/rc.conf? Yes. /etc/rc.conf has the following lines for named: named_enable="YES" named_program="/usr/local/sbin/named" named_flags="-u bind -g bind -c /etc/namedb/named.conf" Lisa Casey ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind problem
On Monday 10 July 2006 13:34, Lisa Casey wrote: > - Original Message - > From: "Jonathan Chen" <[EMAIL PROTECTED]> > To: "Lisa Casey" <[EMAIL PROTECTED]> > Cc: > Sent: Monday, July 10, 2006 3:43 PM > Subject: Re: Bind problem > > > Did you remember to add: > > > >named_program="/usr/local/sbin/named" > > > > to /etc/rc.conf? > > Yes. /etc/rc.conf has the following lines for named: > > named_enable="YES" > named_program="/usr/local/sbin/named" > named_flags="-u bind -g bind -c /etc/namedb/named.conf" > > > Lisa Casey Bind 9 doesn't use the -g flag in the same way bind 8 used to. From named(8) -g Run the server in the foreground and force all logging to stderr. Try dropping the -g bind flag from rc.conf I remember having a similar problem a while back when I switched to bind9. Beech -- --- Beech Rintoul - Sys. Administrator - [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign | Alaska Paradise \ / - NO HTML/RTF in e-mail | 201 East 9Th Avenue Ste.310 X - NO Word docs in e-mail | Anchorage, AK 99501 / \ - Please visit Alaska Paradise - http://www.alaskaparadise.com --- pgpknzVdYFEvJ.pgp Description: PGP signature
Re: Bind problem
- Original Message - From: "Jonathan Chen" <[EMAIL PROTECTED]> To: "Lisa Casey" <[EMAIL PROTECTED]> Cc: Sent: Monday, July 10, 2006 3:43 PM Subject: Re: Bind problem Did you remember to add: named_program="/usr/local/sbin/named" to /etc/rc.conf? Yes. /etc/rc.conf has the following lines for named: named_enable="YES" named_program="/usr/local/sbin/named" named_flags="-u bind -g bind -c /etc/namedb/named.conf" Lisa Casey ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind problem
On Mon, Jul 10, 2006 at 03:11:41PM -0400, Lisa Casey wrote: > Hi All, > > I seem to have a bit of a problem with my Bind installation on FreeBSD 5.3. > When I first setup this box, I installed the Bind 8.4 from the ports. Soon > afterwards, I decided to go with Bind 9 so I installed that from the ports. > Now Bind seems to have an identity problem. Did you remember to add: named_program="/usr/local/sbin/named" to /etc/rc.conf? -- Jonathan Chen <[EMAIL PROTECTED]> --- "I love deadlines. I like the whooshing sound they make as they fly by" - Douglas Adams ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND inside a jail on FreeBSD 6.0
Thanks, that did the trick. I'm not running this in a jail because I'm paranoid or anything -- I just need a test environment, and I don't have an extra machine kicking around. :) Patrick On 5/1/06, David Robillard <[EMAIL PROTECTED]> wrote: BIND is trying to setup a chroot(8) before it starts. If you're already inside a jail, then IMHO it is a little overkill (i.e. Running BIND in a chroot inside a jail). Check the BIND related values in rc.conf(5). The chroot(8) startup is triggered via this one: named_chrootdir="/var/named"# Chroot directory (or "" not to auto-chroot it) So try setting it to named_chrootdir="" and it should disable the chroot code from the startup script. Of course, if you still need to chroot(8) your named(8) install inside your jail, then you're at the same point. Consider running another jail perhaps? Or use BIND's view feature. Hope this helps, David > Thanks, > > Patrick > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions- > [EMAIL PROTECTED]" -- David Robillard UNIX systems administrator, CISSP Montreal: +1 514 966 0122 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND inside a jail on FreeBSD 6.0
On May 1, 2006, at 7:11 AM, David Robillard wrote: BIND is trying to setup a chroot(8) before it starts. If you're already inside a jail, then IMHO it is a little overkill (i.e. Running BIND in a chroot inside a jail). Check the BIND related values in rc.conf(5). The chroot(8) startup is triggered via this one: named_chrootdir="/var/named"# Chroot directory (or "" not to auto-chroot it) So try setting it to named_chrootdir="" At least on my 6.0 system (upgraded from 5.4), that is the default in /etc/defaults/rc.conf so if you did not change it in /etc/rc.conf it should just work inside the jail anyway. Check this to make sure what you are doing. Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND inside a jail on FreeBSD 6.0
-- Message: 23 Date: Fri, 28 Apr 2006 19:36:22 -0600 From: "Chad Leigh -- Shire.Net LLC" <[EMAIL PROTECTED]> Subject: Re: BIND inside a jail on FreeBSD 6.0 To: patrick <[EMAIL PROTECTED]> Cc: freebsd-questions@freebsd.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Apr 28, 2006, at 6:57 PM, patrick wrote: I'm trying to run BIND inside a jail on FreeBSD 6.0, and I'm encountering the following problem: [EMAIL PROTECTED] /var/named]# /etc/rc.d/named start mount_devfs: Operation not permitted /etc/rc.d/named: WARNING: devfs_domount(): Unable to mount devfs on /var/named/dev devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted Starting named. And then it doesn't start... (I realize that BIND already runs in a chroot'd environment, but I'm running a second copy of BIND on an existing development server as a secondary test environment.) The problem looks like it originates in /etc/rc.d/named: # Mount a devfs in the chroot directory if needed # umount ${named_chrootdir}/dev 2>/dev/null devfs_domount ${named_chrootdir}/dev devfsrules_hide_all devfs -m ${named_chrootdir}/dev rule apply path null unhide devfs -m ${named_chrootdir}/dev rule apply path random unhide I tried mounting the devfs outside the jail to the jail's /var/named/dev, and then commenting out these lines above, but named will still not start. Does anyone have any suggestions? BIND is trying to setup a chroot(8) before it starts. If you're already inside a jail, then IMHO it is a little overkill (i.e. Running BIND in a chroot inside a jail). Check the BIND related values in rc.conf(5). The chroot(8) startup is triggered via this one: named_chrootdir="/var/named"# Chroot directory (or "" not to auto-chroot it) So try setting it to named_chrootdir="" and it should disable the chroot code from the startup script. Of course, if you still need to chroot(8) your named(8) install inside your jail, then you're at the same point. Consider running another jail perhaps? Or use BIND's view feature. Hope this helps, David Thanks, Patrick ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions- [EMAIL PROTECTED]" -- David Robillard UNIX systems administrator, CISSP Montreal: +1 514 966 0122 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND inside a jail on FreeBSD 6.0
On Apr 28, 2006, at 6:57 PM, patrick wrote: I'm trying to run BIND inside a jail on FreeBSD 6.0, and I'm encountering the following problem: [EMAIL PROTECTED] /var/named]# /etc/rc.d/named start mount_devfs: Operation not permitted /etc/rc.d/named: WARNING: devfs_domount(): Unable to mount devfs on /var/named/dev devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted Starting named. And then it doesn't start... (I realize that BIND already runs in a chroot'd environment, but I'm running a second copy of BIND on an existing development server as a secondary test environment.) The problem looks like it originates in /etc/rc.d/named: # Mount a devfs in the chroot directory if needed # umount ${named_chrootdir}/dev 2>/dev/null devfs_domount ${named_chrootdir}/dev devfsrules_hide_all devfs -m ${named_chrootdir}/dev rule apply path null unhide devfs -m ${named_chrootdir}/dev rule apply path random unhide I tried mounting the devfs outside the jail to the jail's /var/named/dev, and then commenting out these lines above, but named will still not start. Does anyone have any suggestions? mount a devfs into the jails /dev and you should be all set. I am running bind in a jail under fbsd 6 no problem and I did not have to do anything special except set up the jail according to man jail Chad Thanks, Patrick ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions- [EMAIL PROTECTED]" --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind as a chaching nameserver
Denis R. wrote: http://cr.yp.to/djbdns/guarantee.html Richard, besides simple you want a _secure_ caching name server. Yes, you can type "named_enable" in rc.conf and be done with it, just don't forget to periodically check the security updates web page for BIND exploits. Thanks for the advice guys. I've got named up and running and so far I think its caching the DNS requests (well its serving them OK). I'm not really going to see the benefits of this on SpamAassassin till its database is full of requests is their anywhere (i.e. root-servers.net) that I can get a bind file which reduced this time period? Cheers Richard ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind as a chaching nameserver
AND make sure that either /etc/resolv.conf doesn't exist or that it contains a single nameserver line like this: nameserver 127.0.0.1 otherwise your local nameserver isn't queried. You see, there's really nothing else to do on a standard installation of freebsd... 1- named_enable="YES" in /etc/rc.conf 2- either delete /etc/resolv.conf or use nameserver 127.0.0.1 The default /etc/namedb/named.conf that comes installed does exactly what you want. -- Miguel Qua, 2006-04-26 às 08:05 +0100, Martin Hepworth escreveu: > Richard > > just set the forwarders to another nameserver in the named.conf and that's > it.. > > this will speed up SA massively. > > -- > martin > > On 4/25/06, Richard Collyer <[EMAIL PROTECTED]> wrote: > > > > Hello, > > > > I've recently been getting a lot of trouble with SpamAssassin performing > > a lot of rDNS lookups which is causing network issues (timeouts etc to > > DNS servers). > > > > I am trying to install BIND (or djbdns) as a simple caching nameserver. > > Just to take some of the load off the networks DNS servers (my ISPs). > > > > However I am having trouble finding a good tutorial to follow. > > > > I've looked at > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-dns.html > > but its mainly going on about being a nameserver which is not what I am > > after, wanting to keep it more simple than that. > > > > [EMAIL PROTECTED]:/usr/local/etc] $ named -v > > BIND 9.3.1 > > > > Can anyone suggest me a good tutorial to follow, I've googled but mostly > > they are for debain/redhat and some of the commands and files are > > different. > > > > Cheers > > Richard ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind as a chaching nameserver
http://cr.yp.to/djbdns/guarantee.html Richard, besides simple you want a _secure_ caching name server. Yes, you can type "named_enable" in rc.conf and be done with it, just don't forget to periodically check the security updates web page for BIND exploits. Regards! Richard Collyer wrote: > Hello, > > I've recently been getting a lot of trouble with SpamAssassin performing > a lot of rDNS lookups which is causing network issues (timeouts etc to > DNS servers). > > I am trying to install BIND (or djbdns) as a simple caching nameserver. > Just to take some of the load off the networks DNS servers (my ISPs). > > However I am having trouble finding a good tutorial to follow. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind as a chaching nameserver
Richard Collyer wrote: Hello, I've recently been getting a lot of trouble with SpamAssassin performing a lot of rDNS lookups which is causing network issues (timeouts etc to DNS servers). I am trying to install BIND (or djbdns) as a simple caching nameserver. Just to take some of the load off the networks DNS servers (my ISPs). However I am having trouble finding a good tutorial to follow. I've looked at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-dns.html but its mainly going on about being a nameserver which is not what I am after, wanting to keep it more simple than that. [EMAIL PROTECTED]:/usr/local/etc] $ named -v BIND 9.3.1 Can anyone suggest me a good tutorial to follow, I've googled but mostly they are for debain/redhat and some of the commands and files are different. DJB's instructions for running a cache on a workstation is the simplest set of instructions I know of. I've used them for years with great success o all my servers. Good for web and mail servers as well SA. http://cr.yp.to/djbdns/run-cache.html I also recommend the SpamAssassin Wiki. Look under the heading "Performance Tips:". http://wiki.apache.org/spamassassin/UsingSpamAssassin DAve -- This message was checked by forty monkeys and found to not contain any SPAM whatsoever. Your monkeys may vary ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind as a chaching nameserver
On Wed, Apr 26, 2006 at 09:27:27AM +0100, Richard Collyer wrote: > Yep I've set the named.conf up correctly but when I do "ndc start" it > tells me that it is not found. With BIND 9.3.1, you'd probably want 'rndc', but even then, '/etc/rc.d/named start' would do it for you, if you have named_enable="YES" in your /etc/rc.conf. -- Riemer PalstraAmsterdam, The Netherlands [EMAIL PROTECTED]http://www.palstra.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind as a chaching nameserver
On Wed, April 26, 2006 8:05 am, Martin Hepworth wrote: > Richard > > just set the forwarders to another nameserver in the named.conf and that's > it.. > > this will speed up SA massively. > > -- Yep I've set the named.conf up correctly but when I do "ndc start" it tells me that it is not found. I'll do some more digging. Cheers -- Richard Collyer [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind as a chaching nameserver
Richard just set the forwarders to another nameserver in the named.conf and that's it.. this will speed up SA massively. -- martin On 4/25/06, Richard Collyer <[EMAIL PROTECTED]> wrote: > > Hello, > > I've recently been getting a lot of trouble with SpamAssassin performing > a lot of rDNS lookups which is causing network issues (timeouts etc to > DNS servers). > > I am trying to install BIND (or djbdns) as a simple caching nameserver. > Just to take some of the load off the networks DNS servers (my ISPs). > > However I am having trouble finding a good tutorial to follow. > > I've looked at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-dns.html > but its mainly going on about being a nameserver which is not what I am > after, wanting to keep it more simple than that. > > [EMAIL PROTECTED]:/usr/local/etc] $ named -v > BIND 9.3.1 > > Can anyone suggest me a good tutorial to follow, I've googled but mostly > they are for debain/redhat and some of the commands and files are > different. > > Cheers > Richard > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > [EMAIL PROTECTED]" > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind as a chaching nameserver
> Hello, > > I've recently been getting a lot of trouble with SpamAssassin performing > a lot of rDNS lookups which is causing network issues (timeouts etc to > DNS servers). > > I am trying to install BIND (or djbdns) as a simple caching nameserver. > Just to take some of the load off the networks DNS servers (my ISPs). > > However I am having trouble finding a good tutorial to follow. > > I've looked at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-dns.html > but its mainly going on about being a nameserver which is not what I am > after, wanting to keep it more simple than that. > > [EMAIL PROTECTED]:/usr/local/etc] $ named -v > BIND 9.3.1 > > Can anyone suggest me a good tutorial to follow, I've googled but mostly > they are for debain/redhat and some of the commands and files are > different. > > Cheers > Richard Richard, What you need is a caching DNS. See para 25.6.7. If you don't use forwarders this will bypass your ISPs DNS. There are other solutions too, try Google for them. Rob ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind as a chaching nameserver
For a caching nameserver simply follow the instructions in named.conf. Enable named in rc.conf, and start the daemon. -Derek At 05:50 PM 4/25/2006, Richard Collyer wrote: Hello, I've recently been getting a lot of trouble with SpamAssassin performing a lot of rDNS lookups which is causing network issues (timeouts etc to DNS servers). I am trying to install BIND (or djbdns) as a simple caching nameserver. Just to take some of the load off the networks DNS servers (my ISPs). However I am having trouble finding a good tutorial to follow. I've looked at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-dns.html but its mainly going on about being a nameserver which is not what I am after, wanting to keep it more simple than that. [EMAIL PROTECTED]:/usr/local/etc] $ named -v BIND 9.3.1 Can anyone suggest me a good tutorial to follow, I've googled but mostly they are for debain/redhat and some of the commands and files are different. Cheers Richard ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bind and multiple a records
On 23/4/06 07:24, "Chad Leigh -- Shire.Net LLC" <[EMAIL PROTECTED]> wrote: > On FreeBSD 6.0 with bind9, if I define a host to have multiple A > records, such that some IP addresses are listed more than once, for > example: > > . > . > . > www 600 IN A 192.168.1.1 > 600 IN A 192.168.1.2 > 600 IN A 192.168.1.1 > . > . > . > > > Will those addresses listed more than once show up more often as the > "answer" to name server requests (or more often as the first address > since it lists all addresses in response alternating the order)?? If it doesn't you could cheat thusly: www IN CNAME www1 IN CNAME www2 IN CNAME www3 www1IN A 192.168.1.1 www2IN A 192.168.1.1 www3IN A 192.168.1.2 It would still be a crappy solution though :) Ceri -- That must be wonderful! I don't understand it at all. -- Moliere ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bind and multiple a records
On Apr 23, 2006, at 10:21 AM, Chuck Swiger wrote: Chad Leigh -- Shire.Net LLC wrote: On FreeBSD 6.0 with bind9, if I define a host to have multiple A records, such that some IP addresses are listed more than once, for example: [ ... ] Will those addresses listed more than once show up more often as the "answer" to name server requests (or more often as the first address since it lists all addresses in response alternating the order)?? The last I'd heard, BIND implemented multiple-RR round-robin'ing but not relative weighting if a RR is specified several times. Too bad that they don't have the simplest implementation, which would be just to cycle through the entries as found in the declaration file. No explicit weighting would be necessary. Note that you're probably never going to achieve fine-grained control by using DNS load-balancing anyway, since client-side caching behavior is more significant than what your side does. Not needing fine grained control. Say I have 3:2 defined in the declaration. Anywhere from 1:1 to 2:1 at any moment in time would be ok... Just a general distribution. If you actually need load-balancing to do something, you're better off implementing it between a front-end DTS box (an Alteon or something like that if need be) and a bunch of back-end servers which actually implement meaningful load-balancing based on the workload of your back-end servers... If it were worth the money to do so I would agree... Chad -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions- [EMAIL PROTECTED]" --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bind and multiple a records
Chad Leigh -- Shire.Net LLC wrote: On FreeBSD 6.0 with bind9, if I define a host to have multiple A records, such that some IP addresses are listed more than once, for example: [ ... ] Will those addresses listed more than once show up more often as the "answer" to name server requests (or more often as the first address since it lists all addresses in response alternating the order)?? The last I'd heard, BIND implemented multiple-RR round-robin'ing but not relative weighting if a RR is specified several times. Note that you're probably never going to achieve fine-grained control by using DNS load-balancing anyway, since client-side caching behavior is more significant than what your side does. If you actually need load-balancing to do something, you're better off implementing it between a front-end DTS box (an Alteon or something like that if need be) and a bunch of back-end servers which actually implement meaningful load-balancing based on the workload of your back-end servers... -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND zone transfers
> On Wed, Feb 08, 2006 at 12:45:02PM -, [EMAIL PROTECTED] wrote: >> Under FreeBSD 4.8 BIND was making zone transfers normally. In my >> network, >> Windows 2000 is the master and bind is the salve. Recently, the server >> was upgraded to FreeBSD 6.0, and suddenly BIND stopped making zone >> transfers, except for the first zone, which is transferred just as it >> should be. Zone transfers are taking place from a W2K server. I am >> seeing this problem with BIND 9.3.2 and BIND 9.3.1 > > Saw this in the BIND FAQ, maybe it applies to your situation: > > > Q: Zone transfers from my BIND 9 master to my Windows 2000 slave fail. >Why? > > A: This may be caused by a bug in the Windows 2000 DNS server where DNS >messages larger than 16K are not handled properly. This can be worked >around by setting the option "transfer-format one-answer;". Also >check whether your zone contains domain names with embedded spaces or >other special characters, like "John\032Doe\213s\032Computer", since >such names have been known to cause Windows 2000 slaves to >incorrectly reject the zone. > > > -- >- Tim Utschig <[EMAIL PROTECTED]> > I did not properly explain the situation. The Windows 2000 server is functioning as a secondary server for the parent organization's DNS, and I am using BIND to download the zones to the local offices, from the W2K server, to help reduce network traffic. Sorry this was not clear the first time. Jay ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"