Re: bind 192.168.1.1 to all interfaces

[Patrick Lamaiziere]

Le Sun, 23 Dec 2012 14:17:47 +0200,
Eugen Konkov kes-...@yandex.ru 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 192.168.1.1 to all interfaces

[jb]

Eugen Konkov kes-kes at 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 - slaving the root zone and signature expired

[Warren Block]

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 - slaving the root zone and signature expired

[Damien Fleuriot]

On 25 October 2012 18:33, Warren Block wbl...@wonkity.com 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

[Damien Fleuriot]

On 25 October 2012 18:55, Damien Fleuriot m...@my.gd wrote:
 On 25 October 2012 18:33, Warren Block wbl...@wonkity.com 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 and LDAP support

[Damien Fleuriot]

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

[Matthew Seaman]

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 9.8.1-P1 with OpenSSL 1.0.0 issues..

[James Edwards]

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

[Jerry]

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

[Matthew Seaman]

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: could not configure root hints from 'named.root': file not found

[Matthew]

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

[Matthew]

Krad,
Thank you for the tip. I've changed the . to the correct value.
Matthew

On 1 October 2010 21:16, CyberLeo Kitsanacyber...@cyberleo.net  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
cyber...@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

[krad]

On 1 October 2010 21:16, CyberLeo Kitsana cyber...@cyberleo.net 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
 cyber...@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

[CyberLeo Kitsana]

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

[Ian Smith]

In freebsd-questions Digest, Vol 317, Issue 13, Message: 14
On Sat, 3 Jul 2010 14:20:01 -0700 Chris Maness ch...@chrismaness.com 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

[Chris Maness]

On Thu, Jul 1, 2010 at 7:33 AM, Matthew Seaman
m.sea...@infracaninophile.co.uk 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

[Matthew Seaman]

-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

[Chris Maness]

On Sat, Jul 3, 2010 at 12:52 PM, Matthew Seaman
m.sea...@infracaninophile.co.uk 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

[Chris Maness]

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
2. No spurious traffic will be 

Re: BIND Refusing to Resolve for External Hosts

[Chris Maness]

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

[Matthew Seaman]

-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

[krad]

On 30 June 2010 15:34, Chris Maness ch...@chrismaness.com wrote:

 On Wed, Jun 30, 2010 at 1:49 AM, krad kra...@googlemail.com wrote:
 
 
  On 29 June 2010 07:20, Chris Maness ch...@chrismaness.com 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 

Re: BIND Refusing to Resolve for External Hosts

[Chris Maness]

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 ch...@chrismaness.com wrote:
 On Wed, Jun 30, 2010 at 1:49 AM, krad kra...@googlemail.com wrote:


 On 29 June 2010 07:20, Chris Maness ch...@chrismaness.com 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 {
     

Re: BIND Refusing to Resolve for External Hosts

[Matthew Seaman]

-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

[krad]

On 29 June 2010 07:20, Chris Maness ch...@chrismaness.com 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;// F.ROOT-SERVERS.NET.
};
notify no;
 };
 */

 /*  Serving the following zones locally will prevent any queries
 

Re: BIND Refusing to Resolve for External Hosts

[Chris Maness]

On Wed, Jun 30, 2010 at 1:49 AM, krad kra...@googlemail.com wrote:


 On 29 June 2010 07:20, Chris Maness ch...@chrismaness.com 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;    // F.ROOT-SERVERS.NET.
        };
        notify no;
 };
 

Re: BIND Refusing to Resolve for External Hosts

[Bogdan Webb]

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

[Giorgos Keramidas]

On Wed, 28 Oct 2009 15:49:15 -0700 (PDT), Aflatoon Aflatooni 
aaflato...@yahoo.com 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

[Chuck Swiger]

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 configuration issues

[Gary Gatten]

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 owner-freebsd-questi...@freebsd.org
To: Ray Still rstil...@gmail.com
Cc: freebsd-questions@freebsd.org 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





font size=1
div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 
1.0pt 0in'
/div
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.
/font

___
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]

On Mon, Oct 26, 2009 at 11:55 AM, Gary Gatten ggat...@waddell.com 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 
 owner-freebsd-questi...@freebsd.org
 To: Ray Still rstil...@gmail.com
 Cc: freebsd-questions@freebsd.org 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

[Gary Gatten]

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 ggat...@waddell.com 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 
 owner-freebsd-questi...@freebsd.org
 To: Ray Still rstil...@gmail.com
 Cc: freebsd-questions@freebsd.org 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





font size=1
div style='border:none;border-bottom:double windowtext 2.25pt;padding

RE: bind configuration issues

[Gary Gatten]

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 ggat...@waddell.com 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 
 owner-freebsd-questi...@freebsd.org
 To: Ray Still rstil...@gmail.com
 Cc: freebsd-questions@freebsd.org 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

Re: bind configuration issues

[Ray Still]

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 ggat...@waddell.com 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 ggat...@waddell.com 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 
 owner-freebsd-questi...@freebsd.org
 To: Ray Still rstil...@gmail.com
 Cc: freebsd-questions@freebsd.org 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

Re: bind configuration issues

[Gary Gatten]

Yes, your missing something.  I don't think your solution will work very well.

- Original Message -
From: owner-freebsd-questi...@freebsd.org owner-freebsd-questi...@freebsd.org
To: freebsd-questions@freebsd.org 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 ggat...@waddell.com 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 ggat...@waddell.com 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 
 owner-freebsd-questi...@freebsd.org
 To: Ray Still rstil...@gmail.com
 Cc: freebsd-questions@freebsd.org 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

Re: bind configuration issues

[Gary Gatten]

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' rstil...@gmail.com; 'freebsd-questions@freebsd.org' 
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 owner-freebsd-questi...@freebsd.org
To: freebsd-questions@freebsd.org 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 ggat...@waddell.com 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 ggat...@waddell.com 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 
 owner-freebsd-questi...@freebsd.org
 To: Ray Still rstil...@gmail.com
 Cc: freebsd-questions@freebsd.org 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

Re: bind configuration issues

[Steve Bertrand]

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

[Steve Bertrand]

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]

On Mon, Oct 26, 2009 at 6:42 PM, Steve Bertrand st...@ibctech.ca 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 9 (Was: bsdstats) - fatal error: RUNTIME_CHECK(((pthread_mutex_destroy(((manager-lock))) == 0)

[Anton Shterenlikht]

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
 
  mel.flynn+fbsd.questi...@mailing.thruhere.net 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
+ checkin_server=rpt.bsdstats.org
+ 

Re: Bind 9 (Was: bsdstats) - fatal error: RUNTIME_CHECK(((pthread_mutex_destroy(((manager-lock))) == 0)

[Mel Flynn]

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 9 (Was: bsdstats) - fatal error: RUNTIME_CHECK(((pthread_mutex_destroy(((manager-lock))) == 0)

[Marc G. Fournier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



- --On Monday, July 27, 2009 14:07:44 -0800 Mel Flynn 
mel.flynn+fbsd.questi...@mailing.thruhere.net 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)

[Mel Flynn]

On Monday 27 July 2009 18:35:17 Marc G. Fournier wrote:
 --On Monday, July 27, 2009 14:07:44 -0800 Mel Flynn

 mel.flynn+fbsd.questi...@mailing.thruhere.net 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

[Matthew Seaman]

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

[Tim Judd]

On Fri, Mar 13, 2009 at 12:59 PM, Dave sed.entary...@gmail.com 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

[Jeremy Chadwick]

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

[Matthew Seaman]

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

[Grant Peel]

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]

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

[Lars Kristiansen]

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

[gpeel]

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 DNS Patching on 6.1, 6.2

[Lars Kristiansen]

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 won't resolve my IPs (not upstream or something?)

[Derek Ragona]

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?)

[Redd Vinylene]

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]

Re: BIND won't resolve my IPs (not upstream or something?)

[Redd Vinylene]

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?)

[Derek Ragona]

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]

[RESOLVED]Re: bind sdb using ldap: load zone creating database failure

[rvenne]

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

[Steve Bertrand]

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 DNS

[Derek Ragona]

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

[Wojciech Puchar]

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

[Steve Bertrand]

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

[Derek Ragona]

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

[Jeffrey Goldberg]

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: Can't assign requested address using ssh (or anything else)

[Nikos Vassiliadis]

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: Can't assign requested address using ssh (or anything else) -- resolution

[perlcat]

  $ 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: WINS server name
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 configuration in FreeBSD

[Narek Gharibyan]

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

[Roland Smith]

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

[Brian A. Seklecki]

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?

[Yuri Pankov]

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?

[Christoph Schug]

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?

[Mikhail Goriachev]

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

[Derek Ragona]

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 slave records not updating

[Robert Fitzpatrick]

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 tool for setting up secondary records?

[John Nielsen]

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

[Brian A. Seklecki]

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

[Lothar Braun]

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 Casey]

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: freebsd-questions@freebsd.org
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: ignoring 
out-of-zone d

ata (jellico.tn.us)
Jul 11 13:40:51 netlink named[293]: M/jellico.com.db:528: ignoring 
out

Re: Bind problem

[Derek Ragona]

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: freebsd-questions@freebsd.org
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

Re: Bind problem

[Jonathan Chen]

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 problem

[Lisa Casey]

- Original Message - 
From: Jonathan Chen [EMAIL PROTECTED]

To: Lisa Casey [EMAIL PROTECTED]
Cc: freebsd-questions@freebsd.org
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

[Beech Rintoul]

On Monday 10 July 2006 13:34, Lisa Casey wrote:
 - Original Message -
 From: Jonathan Chen [EMAIL PROTECTED]
 To: Lisa Casey [EMAIL PROTECTED]
 Cc: freebsd-questions@freebsd.org
 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

[Derek Ragona]

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: freebsd-questions@freebsd.org
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 inside a jail on FreeBSD 6.0

[patrick]

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

[David Robillard]

--

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

[Chad Leigh -- Shire.Net LLC]

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

[Chad Leigh -- Shire.Net LLC]

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

[Richard Collyer]

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

[bsd]

 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

[Martin Hepworth]

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

[Richard Collyer]

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

[Riemer Palstra]

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

[DAve]

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

[Denis R.]

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

[Miguel Ramos]

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

[Derek Ragona]

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

[Chad Leigh -- Shire.Net LLC]

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

[Ceri Davies]

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

[Chuck Swiger]

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

[Reko Turja]

- Original Message - 
From: [EMAIL PROTECTED]

To: freebsd-questions@freebsd.org
Sent: Wednesday, February 08, 2006 2:45 PM
Subject: BIND zone transfers

Any suggestions as to how to proceed would be greatly appreciated.  Thanks
in advance for your assistance.


Do you have the Win2k IP address defined as a NS to which zone transfer is 
allowed? (Can't get the BIND documentation atm so cannot tell the exact 
setting name...


-Reko 


___
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

[Tim Utschig]

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:

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

-- 
   - Tim Utschig [EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]