Very Computer

Look closely at the indentation--the forwarders section should be inside
the options section.

--
Warren Block * Rapid City, South Dakota * USA

{ snip }

Quote:>> When I run named-checkconf, I get 'unknown option "forwarders"'.  :-(
> Look closely at the indentation--the forwarders section should be inside
> the options section.

Hmm, curious.  OK, config file altered, and upon starting named (using the
-c switch to point to the desired configuration file), I get ...

Jan 31 03:48:05 lievre named[94835]: starting BIND 9.2.1 -c /etc/namedb/named.conf
Jan 31 03:48:05 lievre named[94835]: none:0: open: /etc/rndc.key: file not found
Jan 31 03:48:05 lievre named[94835]: couldn't add command channel 127.0.0.1#953: file not found

Do I *really* have to get involved keys, and rndc and so forth?  Can't I
just start named from rc.local, and let it run?  If I try a lookup with
named running, I get 'connection refused' .. :-(

: I'm setting up a caching-only nameserver with BIND9.  Some questions: is
: there documentation that covers _BIND 9_, as everything I've found so far,
: has different sections concerning 4, 8, and 9.  Also, is there something
: wrong with my named.conf file (the following having been written by
: following to the letter (I hope) the documentation in ../doc/arm in the
: source directory...

: // $FreeBSD: src/etc/namedb/named.conf,v 1.6.2.4 2001/12/05 22:10:12 cjc Exp $

: acl "voute.net" { 192.168.0/24; };

: options {
:        directory "/etc/namedb";
:        pid-file "named.pid";
:        allow-query { "voute.net"; };
: };

This }; is misplaced, forwarders should be inside options.

:        forwarders {
:                212.198.0.91;
:                212.198.2.51;
:        };

: zone "." {
:        type hint;
:        file "named.root";
: };

: zone "0.0.127.IN-ADDR.ARPA" {
:        type master;
:        file "localhost.rev";
: };

: 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.IP6.INT" {
:        type master;
:        file "localhost.rev";
: };

: When I run named-checkconf, I get 'unknown option "forwarders"'.  :-(

: Also, when I start it with /usr/sbin/named, the logs say fatal error, as
: there is no such file as /etc/named.conf.  Erm, yes, but the file should be
: '/etc/namedb/named.conf'.  Why is it still looking for a file in /etc ?

It seems to me that you are mixing bind8 and bind9. If you install bind9
from ports, it should read its named.conf from /usr/local/etc. If you have
directly compiled the source, indeed it will probably check in /etc.

: Thanks.

--

Michel TALON

: { snip }

:>> When I run named-checkconf, I get 'unknown option "forwarders"'.  :-(

:> Look closely at the indentation--the forwarders section should be inside
:> the options section.

: Hmm, curious.  OK, config file altered, and upon starting named (using the
: -c switch to point to the desired configuration file), I get ...

: Jan 31 03:48:05 lievre named[94835]: starting BIND 9.2.1 -c /etc/namedb/named.conf
: Jan 31 03:48:05 lievre named[94835]: none:0: open: /etc/rndc.key: file not found
: Jan 31 03:48:05 lievre named[94835]: couldn't add command channel 127.0.0.1#953: file not found

: Do I *really* have to get involved keys, and rndc and so forth?  Can't I
: just start named from rc.local, and let it run?  If I try a lookup with
: named running, I get 'connection refused' .. :-(

Yes, this is the main hassle with bind9, you need to setup keys. In turn you
may have entropy problems to generate them. This is solved by setting
something like
rand_irqs="1 9 10"
in /etc/rc.conf.

--

Michel TALON

begin  quoting words of D.C.:

Quote:> Do I *really* have to get involved keys, and rndc and so forth?

Yes, you do. It's a security measure, so why object?

--
* -- http://www.veryComputer.com/: F86289CE
++ Running FreeBSD 4.7 ++ Debian GNU/Linux (Woody)

On Fri, 31 Jan 2003 03:09:21 +0000,
[snip]

Quote:>  Also, is there something
> wrong with my named.conf file

Yes.

Quote:> // $FreeBSD: src/etc/namedb/named.conf,v 1.6.2.4 2001/12/05 22:10:12 cjc Exp $

> acl "voute.net" { 192.168.0/24; };

> options {
>    directory "/etc/namedb";
>    pid-file "named.pid";
>    allow-query { "voute.net"; };

You don't own that domain. Fix that.

This looks like the _perfect_ opportunity to do that, too.

--
  j p d (at) d s b (dot) t u d e l f t (dot) n l .

Quote:>> acl "voute.net" { 192.168.0/24; };

>> options {
>>        directory "/etc/namedb";
>>        pid-file "named.pid";
>>        allow-query { "voute.net"; };

> You don't own that domain. Fix that.

But if his name server listens on an internal interface only, and he assigns
only ip addresses from the 192.168.0/24 network?

Simon

Quote:>I'm setting up a caching-only nameserver with BIND9.  Some questions: is
>there documentation that covers _BIND 9_, as everything I've found so far,
>has different sections concerning 4, 8, and 9.  Also, is there something
>wrong with my named.conf file (the following having been written by
>following to the letter (I hope) the documentation in ../doc/arm in the
>source directory...

You might want to try dnscache from the djbdns port.

Dnscache does caching only. Pretty easy to configure[1]. So no need for
keys etc etc. If you want a name service then there's tinydns.

It's small, simple and it's more likely to be secure.

I have never needed to patch/upgrade djbdns for security reasons. It's
written by Dan Bernstein who also wrote qmail which I've never had to patch
for security reasons either.

AFAIK Bind 9 is brought to you by about the same people who did Bind 8.

Link.
[1] See examples at http://cr.yp.to/djbdns.html
********************************



********************************

Why do you use RFC1918 ips? That is just _one_ reason to use a domain that
you're sure will _never_ _possibly_ or even _imossibly_ turn around and bite
you in the arse.

If the guy likes voute, he'd use something like voute.local, for example.
If he wants to be really really sure, he registers his own domain and
uses that, or, what I'd do, internal.$domain as a domain (and give that
out as a default (search)domain to the local machines).

--
  j p d (at) d s b (dot) t u d e l f t (dot) n l .

: You might want to try dnscache from the djbdns port.

: Dnscache does caching only. Pretty easy to configure[1]. So no need for
: keys etc etc. If you want a name service then there's tinydns.

: It's small, simple and it's more likely to be secure.

: I have never needed to patch/upgrade djbdns for security reasons. It's
: written by Dan Bernstein who also wrote qmail which I've never had to patch
: for security reasons either.

: AFAIK Bind 9 is brought to you by about the same people who did Bind 8.

I see i have pronounced the name that must not be pronounced and have
attracted bad weather on the newsgroup :-)

--

Michel TALON

Quote:>>> acl "voute.net" { 192.168.0/24; };

>>> options {
>>>      directory "/etc/namedb";
>>>      pid-file "named.pid";
>>>      allow-query { "voute.net"; };
>> You don't own that domain. Fix that.
> But if his name server listens on an internal interface only, and he assigns
> only ip addresses from the 192.168.0/24 network?

Which is what I keep trying to tell him.  sendmail, apache, everything else
that could possibly have contact with 'the outside world', answers to the
real domain that I _do_ own (zeouane.org).  The domain 'voute.net' is
kept for historical reasons, and has never once interfered in any way with
the 'real' Internet.

--
Desmond Coughlan

http: // www . zeouane . org

On Sat, 1 Feb 2003 12:24:19 +0000,
[snip]

Quote:>>> You don't own that domain. Fix that.

>> But if his name server listens on an internal interface only, and he assigns
>> only ip addresses from the 192.168.0/24 network?

> Which is what I keep trying to tell him.  sendmail, apache, everything else

You don't even try, so don't pretend you do. You simply ignore me and
continue to _publicly_ malpractice.

Quote:> that could possibly have contact with 'the outside world', answers to the
> real domain that I _do_ own (zeouane.org).  The domain 'voute.net' is
> kept for historical reasons, and has never once interfered in any way with
> the 'real' Internet.

Not a good show, dwelling on errors past. What about moving to
voute.zeouane.org (or voute.net.zeouane.org, if you must)? Add a default
search path and you're all set.

You say it will never interfere, or at least it seems to not do that now.
But can you _guarantee_ it will never, ever, taking into account all
possible changes that you haven't thought up yet you could do?

It may seem pedantic, but a simple change turns a possible pain and bad
example into a neat setup and good example for the rest of us.

--
  j p d (at) d s b (dot) t u d e l f t (dot) n l .

Quote:>>> But if his name server listens on an internal interface only, and he assigns
>>> only ip addresses from the 192.168.0/24 network?
>> Which is what I keep trying to tell him.  sendmail, apache, everything else
> You don't even try, so don't pretend you do. You simply ignore me and
> continue to _publicly_ malpractice.

I answered you on 5 June 2002, and said ...

        'I've been using that domain name for five years now.  During that
        time, there have been no problems with the use of the name, within my
        network.  All traffic that leaves my network is 'masqueraded', and to
        the "outside" world looks like it came from a noos address.  Sendmail,
        ssh, apache, whatever ... everything here that sends packets outwith my
        network, has been configured to ensure that the name "voute.net"
        appears nowhere other than inside the LAN.

        With respect, I don't need to change _anything_.'

Of course, I didn't own 'zeouane.org' at that time, which is why I used the
word 'noos' in my response (noos being my ISP).  Now, all traffic that
leaves this network is stamped 'zeouane.org'.  

Quote:>> that could possibly have contact with 'the outside world', answers to the
>> real domain that I _do_ own (zeouane.org).  The domain 'voute.net' is
>> kept for historical reasons, and has never once interfered in any way with
>> the 'real' Internet.
> Not a good show, dwelling on errors past. What about moving to
> voute.zeouane.org (or voute.net.zeouane.org, if you must)? Add a default
> search path and you're all set.

I wouldn't call it an 'error'.  When I set up the network here, there
wasn't even a modem connected to the machine, so it really was _100%_
internal.  'voute' is the name of the street where I was living when I
installed the box.

Quote:> You say it will never interfere, or at least it seems to not do that now.
> But can you _guarantee_ it will never, ever, taking into account all
> possible changes that you haven't thought up yet you could do?

> It may seem pedantic, but a simple change turns a possible pain and bad
> example into a neat setup and good example for the rest of us.

It does seem pedantic, yes.  

--
Desmond Coughlan

http: // www . zeouane . org

On Sun, 2 Feb 2003 16:40:55 +0000,

Which is still no guarantee since some applications pass domain names within
their protocol that your masquerading s/w doesn't know about.

Quote:>    With respect, I don't need to change _anything_.'

> Of course, I didn't own 'zeouane.org' at that time, which is why I used the
> word 'noos' in my response (noos being my ISP).  Now, all traffic that
> leaves this network is stamped 'zeouane.org'.  

On the outside, yes, not on the inside. Eg, mail and usenet. Apart from
your claimed masqueraind you still continue to publicly advertize a broken
setup. So, in this case, you are the leak, and you don't even realise it.

Quote:>>> that could possibly have contact with 'the outside world', answers to the
>>> real domain that I _do_ own (zeouane.org).  The domain 'voute.net' is
>>> kept for historical reasons, and has never once interfered in any way with
>>> the 'real' Internet.

>> Not a good show, dwelling on errors past. What about moving to
>> voute.zeouane.org (or voute.net.zeouane.org, if you must)? Add a default
>> search path and you're all set.

> I wouldn't call it an 'error'.  When I set up the network here, there
> wasn't even a modem connected to the machine, so it really was _100%_
> internal.  'voute' is the name of the street where I was living when I
> installed the box.

Call it folly of youth, then. And even when you have lots of acceptable
options and perfect opportunity you refuse to change now that you know
better. Or at least should. And you do so, _publicly_.

Quote:>> You say it will never interfere, or at least it seems to not do that now.
>> But can you _guarantee_ it will never, ever, taking into account all
>> possible changes that you haven't thought up yet you could do?

>> It may seem pedantic, but a simple change turns a possible pain and bad
>> example into a neat setup and good example for the rest of us.

> It does seem pedantic, yes.  

But then, when you can't even configure yourself, what about software that
does things behind your back?

Funny thing how you pretend to answer but simply sidestep the issues.
Is it that you don't understand, or don't want to understand?

--
  j p d (at) d s b (dot) t u d e l f t (dot) n l .

Quote:>>       'I've been using that domain name for five years now.  During that
>>       time, there have been no problems with the use of the name, within
>>       my network.  All traffic that leaves my network is 'masqueraded',
>>       and to the "outside" world looks like it came from a noos address.
>>       Sendmail, ssh, apache, whatever ... everything here that sends
>>       packets outwith my network, has been configured to ensure that the
>>       name "voute.net" appears nowhere other than inside the LAN.
> Which is still no guarantee since some applications pass domain names
> within their protocol that your masquerading s/w doesn't know about.

How does this deal grab you: find an example of where my 'domain name' has
caused _any_ problems by interfering with the _real_ 'voute.net', and I
shall change it forthwith.

{ snip }

--
Desmond Coughlan

http: // www . zeouane . org