Undeliverable: bind-users Digest V6 #264
System Administrator
administrator at home.grytsyuk.com
Thu Oct 7 07:57:40 UTC 2004
Your message
To:
Subject: bind-users Digest V6 #264
Sent: Thu Oct 07 03:57:39 2004
did not reach the following recipient(s):
vitaliy at home.grytsyuk.com on Thu Oct 07 03:57:39 2004
The e-mail account does not exist at the organization this message
was sent to. Check the e-mail address, or contact the recipient
directly to find out the correct address.
<s1.home.grytsyuk.com #5.1.1>
-- Attached file included as plaintext by Ecartis --
i>?Reporting-MTA: dns; s1.home.grytsyuk.com
Final-Recipient: RFC822; vitaliy at home.grytsyuk.com
Action: failed
Status: 5.1.1
X-Supplementary-Info: s1.home.grytsyuk.com
X-Display-Name: vitaliy at home.grytsyuk.com
-- Attached file included as plaintext by Ecartis --
i>?Thread-Topic: bind-users Digest V6 #264
Received: from mail pickup service by s1.home.grytsyuk.com with Microsoft SMTPSVC; Thu, 7 Oct 2004 03:57:32 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Apparently-To: v_grytsyuk at yahoo.com via 66.218.79.93; Thu, 07 Oct 2004 00:51:53 -0700
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
X-Originating-IP: [204.152.184.167]
Return-Path: <bind-users-bounce at isc.org>
Received: from 204.152.184.167 (EHLO sf1.isc.org) (204.152.184.167) by mta416.mail.scd.yahoo.com with SMTP; Thu, 07 Oct 2004 00:51:53 -0700
Received: from rc3.isc.org (rc3.isc.org [IPv6:2001:4f8:3:bb::25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sf1.isc.org (Postfix) with ESMTP id 4B6A0284F1; Thu, 7 Oct 2004 07:51:42 +0000 (UTC) (envelope-from bind-users-bounce at isc.org)
Received: from rc3.isc.org (rc3.isc.org [204.152.187.25]) by rc3.isc.org (Postfix) with ESMTP id 43F4C5C8C8; Thu, 7 Oct 2004 07:50:59 +0000 (UTC) (envelope-from bind-users-bounce at isc.org)
Received: with ECARTIS (v1.0.0; list bind-users); Thu, 07 Oct 2004 07:50:00 +0000 (UTC)
Date: Thu, 07 Oct 2004 07:50:00 +0000 (UTC)
From: "BIND Users Mailing List" <bind-users at isc.org>
To: "bind-users digest users" <ecartis at isc.org>
Subject: bind-users Digest V6 #264
Precedence: bulk
List-Unsubscribe: <mailto:bind-users-request at isc.org?Subject=unsubscribe>
List-Id: <bind-users.isc.org>
X-List-ID: <bind-users.isc.org>
Message-ID: <20041007075059.43F4C5C8C8 at rc3.isc.org>
X-GFI-P2E: S1
X-OriginalArrivalTime: 07 Oct 2004 07:57:32.0772 (UTC) FILETIME=[4CFE0A40:01C4AC43]
bind-users Digest Wed, 06 Oct 2004 Volume: 06 Issue: 264
In This Issue:
Re: hesiod and 9.3.0/8.2.3
Re: sending notifies from slave server
connection reset for zone notify
Reasons no to use TSIG?
Restriction for large zones?
Re: sending notifies from slave server
Re: Restriction for large zones?
Re: Reasons no to use TSIG?
Re: sending notifies from slave server
Re: sending notifies from slave server
Re: sending notifies from slave server
Many '...query: . IN NS' in query log file
What is wrong with this bind configuration?
Re: Many '...query: . IN NS' in query log file
Re: What is wrong with this bind configuration?
Re: What is wrong with this bind configuration?
Re: What is wrong with this bind configuration?
Re: daemon shutdown time with large zones (bind 9.2.4)
Re: Restriction for large zones?
Re: daemon shutdown time with large zones (bind 9.2.4)
----------------------------------------------------------------------
Subject: Re: hesiod and 9.3.0/8.2.3
Date: Wed, 06 Oct 2004 10:07:36 +0200
From: Danny Braniss <danny at cs.huji.ac.il>
[...]
> So far I haven't seen an error.
the error was in 8.2.3 that was not setting the Auth. bit for hesiod.
see Mark's resp.
>
[...]
> >you think i could find work there as a runaway dns manager? :-)
> dunno. It's also been quite I few years since I was a student in Givat Ram.
it's now Edmond Safra Campus, and we are School of Computer Science & Eng.
as someone before said, ... what's in a name, a rose by any other name is
still a rose ... (sorry W.S., it's been sometime)
> I can't get to ns. Is it inside a firewall?
>
good question, i remmember configuring named so that the hesiod stuff would
not leek out, but looking at the conf files i can't figure out what
magic does it :-) time for RTFM, but nice to know that i did something right.
danny
------------------------------
Subject: Re: sending notifies from slave server
Date: Wed, 06 Oct 2004 09:39:36 +0100
From: Jim Reid <jim at rfc1035.com>
>>>>> "saravanan" == saravanan ganapathy <sarav_gsa at yahoo.com> writes:
saravanan> But why slave servers send a notification? To whom it will send?
Because RFC1996 says so. Please read it. I quote:
2. Definitions and Invariants
..
Notify Set set of servers to be notified of changes to some
zone. Default is all servers named in the NS RRset,
except for any server also named in the SOA MNAME.
Some implementations will permit the name server
administrator to override this set or add elements to
it (such as, for example, stealth servers).
------------------------------
From: "bizbox" <bizbox at yahoo.com>
Subject: connection reset for zone notify
Date: Wed, 6 Oct 2004 12:25:48 +0800
hi,
i am currently running a slave DNS server with BIND while one of my
customer is sending their master zone to me with zone notify using djbdns ,i
got the following error:
Oct 06 10:03:51.684 xfer-in: error: transfer of domainname.com/IN' from
192.168.0.1#53: failed while receiving responses: connection reset
Oct 06 10:03:51.684 xfer-in: info: transfer of 'domainname.com/IN' from
192.168.0.2#53: end of transfer
where 192.168.0.1 is the fictional pridns IP of my client running djbdns and
192.168.0.2 is the secondary IP of my DNS server running BIND.
rgds
bizbox
------------------------------
From: "Walkenhorst, Benjamin" <Benjamin.Walkenhorst at telekom.de>
Subject: Reasons no to use TSIG?
Date: Wed, 6 Oct 2004 12:59:09 +0200
Hello everyone,
I am exploring the possibilities TSIG offers; for the environment I work
in TSIG seems fine, since it is easy to set up and offers a reasonable degree
of security from employees doing zone transfers or hammering my machines
with recursive queries.
And since I am about to use TSIG as widely as possible, I would like to know
if there are any reasons not to use TSIG.
I can think of just one: TSIG cannot be used to verify zone-content the way DNSSEC
can. Also, regular queries don't get covered by this.
But otherwise?
(In case it matters, we currently have a test setup where TSIG is used for
"allow-transfer {}" and "allow-notify {}".)
Benjamin Walkenhorst
------------------------------
Date: Wed, 6 Oct 2004 17:15:53 +0200 (MEST)
From: "Tom Schmitt" <TomSchmitt at gmx.de>
Subject: Restriction for large zones?
Hi,
one of my dns-zones is growing large and has now nearly 100 thousands
records. My question is: Is there a limit how large a zone could be?
Or is there a limit of any kind at which the performance is no longer
acceptable?
Thanks,
Tom.
--
+++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl
------------------------------
Subject: Re: sending notifies from slave server
From: David Botham <DBotham at OptimusSolutions.com>
Date: Wed, 6 Oct 2004 11:20:53 -0400
bind-users-bounce at isc.org wrote on 10/06/2004 02:37:59 AM:
> Hai,
> I am using bind 9.2.1 in my debian system and it
> works well both in master & slave servers.
>
> When the zone transfer completes, I was noticed that "
> zone abc.com/IN: sending notifies (serial 11) " &
> zone 211.19.20.in-addr.arpa/IN: sending notifies
> (serial 11) " in the slave server.
> Generally the primary server will send a
> notification and the slave servers will accept. But
> why slave servers send a notification? To whom it will
> send?
By default named will send notifies to all name servers listed in the NS
RR set for a given zone, except for the name server listed in the dname
field of the SOA RR, regardless of whether named loaded the zone as a
master or slave. This behavior is driven by RFC 1996.
You probably don't want the slave(s) sending the notify. Use the
following zone syntax to turn this behavior off:
zone "foo.net"{
type slave;
file "foo.net.db";
masters{192.168.1.10;};
notify no;
};
Notice the use of "notify no;". This statement turns off notify for this
zone. Read the BIND ARM for details regarding other notify tweaking
features such as "also-notify" and "notify-source-..."
hth,
Dave...
>
> Sarav
>
>
>
>
> _______________________________
> Do you Yahoo!?
> Declare Yourself - Register online to vote today!
> http://vote.yahoo.com
>
------------------------------
Subject: Re: Restriction for large zones?
Date: Wed, 06 Oct 2004 16:38:34 +0100
From: Jim Reid <jim at rfc1035.com>
>>>>> "Tom" == Tom Schmitt <TomSchmitt at gmx.de> writes:
Tom> one of my dns-zones is growing large and has now nearly 100
Tom> thousands records. My question is: Is there a limit how large
Tom> a zone could be?
Yes. With BIND9, it's the limitations imposed by your hardware and
OS. ie How much RAM you can put in the box and how much VM the OS and
CPU allows a process to address. Zones with millions of RRs occupying
in excess of 1 GB are not unknown: the .de TLD for example. Though if
you have a zone file of the order of 100K RRs, it might be worth
considering partitioning the zone to make the data management issues
easier. These could include delegation of content control, smaller
zone transfers => faster propagation of new zone copies, etc, etc.
Tom> Or is there a limit of any kind at which
Tom> the performance is no longer acceptable?
Of course there is. But that'll depend on your definitions of
"performance" and "unacceptable". Usually, organisational problems
around the management of large data sets crop up long before the
physical limits of the name server are reached. You could also do
capacity planning to figure out when you'll need a bigger box or what
happens when the name server reaches the limits of what's possible on
your current platform.
------------------------------
Subject: Re: Reasons no to use TSIG?
From: David Botham <DBotham at OptimusSolutions.com>
Date: Wed, 6 Oct 2004 11:43:00 -0400
bind-users-bounce at isc.org wrote on 10/06/2004 06:59:09 AM:
> Hello everyone,
>
> I am exploring the possibilities TSIG offers; for the environment I work
> in TSIG seems fine, since it is easy to set up and offers a reasonable
degree
> of security from employees doing zone transfers or hammering my machines
> with recursive queries.
>
> And since I am about to use TSIG as widely as possible, I would like to
know
> if there are any reasons not to use TSIG.
>
> I can think of just one: TSIG cannot be used to verify zone-content the
way DNSSEC
> can. Also, regular queries don't get covered by this.
I do not consider the fact that TSIG can't verify zone content a check in
the minus column. There are a great number of things that TSIG does not
do by design. Verifying zone content is one of them. Others are (in no
particular order):
Making coffee
Tying my shoes
Negotiate SSL connections
etc...
:)
TSIG does a great job at what it is designed to do (imho).
However, if you are interested in interoperation in a Windows environment
for DDNS updates, you may want to look at this:
http://www.microsoft.com/windows2000/techinfo/reskit/samplechapters/cncf/cncf_imp_eqjg.asp
Specifically, skip to the seciton on "DNS Standards for Secure Dynamic
Update".
hth,
Dave...
>
> But otherwise?
> (In case it matters, we currently have a test setup where TSIG is used
for
> "allow-transfer {}" and "allow-notify {}".)
>
> Benjamin Walkenhorst
>
------------------------------
Subject: Re: sending notifies from slave server
Date: Wed, 06 Oct 2004 16:46:29 +0100
From: Jim Reid <jim at rfc1035.com>
>>>>> "David" == David Botham <DBotham at OptimusSolutions.com> writes:
David> By default named will send notifies to all name servers
David> listed in the NS RR set for a given zone, except for the
David> name server listed in the dname field of the SOA RR,
David> regardless of whether named loaded the zone as a master or
David> slave. This behavior is driven by RFC 1996.
David> You probably don't want the slave(s) sending the notify.
Nope. Switching this off can be harmful. Suppose Slave A has lost
connectivity to the master server but could have received a NOTIFY and
done a zone transfer from Slave B. Would it be better for A to hand
out stale data for the zone or retrieve an up-to-date version from B?
Leaving NOTIFY switched on -- BIND's default behaviour -- is harmless.
------------------------------
Date: Wed, 6 Oct 2004 11:02:20 -0500 (CDT)
From: Barry Finkel <b19141 at achilles.ctd.anl.gov>
Subject: Re: sending notifies from slave server
saravanan ganapathy <sarav_gsa at yahoo.com> wrote:
> I am using bind 9.2.1 in my debian system and it
>works well both in master & slave servers.
>
>When the zone transfer completes, I was noticed that "
>zone abc.com/IN: sending notifies (serial 11) " &
>zone 211.19.20.in-addr.arpa/IN: sending notifies
>(serial 11) " in the slave server.
> Generally the primary server will send a
>notification and the slave servers will accept. But
>why slave servers send a notification? To whom it will
>send?
Others have already posted answers, but I will post one more. It is
perfectly legal for a slave server to transfer a zone from another
slave, if the zones are configured to do that. Therefore, a slave
server sends NOTIFY packets to the servers in the "Notify Set".
----------------------------------------------------------------------
Barry S. Finkel
Computing and Instrumentation Solutions Division
Argonne National Laboratory Phone: +1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 222, Room D209 Internet: BSFinkel at anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994
------------------------------
Subject: Re: sending notifies from slave server
From: David Botham <DBotham at OptimusSolutions.com>
Date: Wed, 6 Oct 2004 13:15:20 -0400
bind-users-bounce at isc.org wrote on 10/06/2004 11:46:29 AM:
> >>>>> "David" == David Botham <DBotham at OptimusSolutions.com> writes:
>
> David> By default named will send notifies to all name servers
> David> listed in the NS RR set for a given zone, except for the
> David> name server listed in the dname field of the SOA RR,
> David> regardless of whether named loaded the zone as a master or
> David> slave. This behavior is driven by RFC 1996.
>
> David> You probably don't want the slave(s) sending the notify.
Perhaps I should have worded this as:
If you don't want the slave(s) sending the notify.
Dave...
>
> Nope. Switching this off can be harmful. Suppose Slave A has lost
> connectivity to the master server but could have received a NOTIFY and
> done a zone transfer from Slave B. Would it be better for A to hand
> out stale data for the zone or retrieve an up-to-date version from B?
> Leaving NOTIFY switched on -- BIND's default behaviour -- is harmless.
>
------------------------------
Subject: Many '...query: . IN NS' in query log file
From: Nicolas Ecarnot <nicolas.ecarnot at alussinan.org>
Date: 06 Oct 2004 16:37:35 GMT
Hi,
I'm a bind beginner and I set up a bind9 master public server.
This seem to work fine according to my tests and those of some dns web
checker, but now in my query log file, amongst the 'good' queries, I get
hundreds of line like those :
client 81.206.200.71#1026: query: . IN NS
What does this mean ?
Is this normal, or are they misconfigured dns servers ?
This does not seem to trouble my dns server, just inflate the logs.
Is there a way to avoid that ?
--
Nicolas Ecarnot
------------------------------
From: "mistrzu" <mistrzu24 at NOSPAM.gazeta.pl>
Subject: What is wrong with this bind configuration?
Date: Wed, 6 Oct 2004 18:16:48 +0200
Hello,
I have got two domains: exapmple-domain.com and shop.example-domain.com.
configuration files:
named.conf:
zone "exapmple-domain.com" IN {
type master;
file "exapmple-domain.com.zone";
allow-update { none; };
};
zone "shop.exapmple-domain.com" IN {
type master;
file "shop.exapmple-domain.com.zone";
allow-update { none; };
};
exapmple-domain.com.zone:
$TTL 86400
$ORIGIN exapmple-domain.com.
@ IN SOA dns1.example-domain.com mail1example-domain.com. (
2004100601
43200
3600
2419200
86400)
@ IN NS dns1
@ IN NS dns2
@ IN MX 5 mail
dns1 IN A 10.0.0.1
dns2 IN A 10.0.0.2
@ IN A 10.0.0.1
www IN A 10.0.0.1
mail IN A 10.0.0.1
shop.example-domain.com.zone:
$TTL 86400
$ORIGIN shop.example-domain.com.
@ IN SOA dns1.example-domain.com. mail1.example-domain.com (
2004100601
43200
3600
2419200
86400)
@ IN NS dns1.example-domain.com.
@ IN NS dns2.example-domain.com.
@ IN A 10.0.0.1
www IN A 10.0.0.1
@ IN MX 5 mail.example-domain.com.
example-domain.com. IN A 10.0.0.1
When i write using other dns:
host shop.example-domain.com
i have got:
Host shop.example-domain.com not found: 3(NXDOMAIN)
and dig command said:
$ dig shop.example-domain.com
; <<>> DiG 9.2.1 <<>> shop.example-domain.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32014
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;shop.example-domain.com. IN A
;; AUTHORITY SECTION:
example-domain.com. 86400 IN SOA
dns1.example-domain.com mail1.example-domain.com. 2004100601 43200 3600
2419200 86400
;; Query time: 7 msec
;; SERVER: 62.233.128.17#53(62.233.128.17)
;; WHEN: Wed Oct 6 18:12:10 2004
;; MSG SIZE rcvd: 82
Whai did I do wrong?
regards
Marcin
------------------------------
Subject: Re: Many '...query: . IN NS' in query log file
From: David Botham <DBotham at OptimusSolutions.com>
Date: Wed, 6 Oct 2004 15:42:50 -0400
bind-users-bounce at isc.org wrote on 10/06/2004 12:37:35 PM:
> Hi,
>
> I'm a bind beginner and I set up a bind9 master public server.
> This seem to work fine according to my tests and those of some dns web
> checker, but now in my query log file, amongst the 'good' queries, I get
> hundreds of line like those :
>
> client 81.206.200.71#1026: query: . IN NS
I am fairly certain this log entry indicates that the computer at IP
address 81.206.200.71 is asking your name server for the NS RR's for the
root zone.
Dave...
>
> What does this mean ?
> Is this normal, or are they misconfigured dns servers ?
> This does not seem to trouble my dns server, just inflate the logs.
> Is there a way to avoid that ?
>
> --
> Nicolas Ecarnot
>
------------------------------
Date: Wed, 06 Oct 2004 21:47:05 +0200
From: Alexander Dalloz <alexander.dalloz at uni-bielefeld.de>
Subject: Re: What is wrong with this bind configuration?
Am Mi, den 06.10.2004 schrieb mistrzu um 18:16:
> Whai did I do wrong?
> Marcin
Dig for your several mistypings: misspelled "example" and missing
trailing dots.
Alexander
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.8-1.521smp
Serendipity 21:46:06 up 7 days, 12 users, load average: 1.15, 1.26, 1.33
-- Attached file included as plaintext by Ecartis --
-- File: signature.asc
-- Desc: Dies ist ein digital signierter Nachrichtenteil
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQBBZEu54ZduiO1pVlMRAhTiAJ96iC/j4gotXSSdauudv/PYbmQe4wCgqJKH
HmZeIai8WmTDfoYx1xZ0LJ0=
=sBgH
-----END PGP SIGNATURE-----
------------------------------
Subject: Re: What is wrong with this bind configuration?
From: David Botham <DBotham at OptimusSolutions.com>
Date: Wed, 6 Oct 2004 15:47:22 -0400
bind-users-bounce at isc.org wrote on 10/06/2004 12:16:48 PM:
> Hello,
>
> I have got two domains: exapmple-domain.com and shop.example-domain.com.
I seriously doubt you own those two domains. You will have to post the
real domain name to get help here.
[clipped text that has been tampered with and therefore is of little value
in troubleshooting]
> ;; Query time: 7 msec
> ;; SERVER: 62.233.128.17#53(62.233.128.17)
You missed the actual IP address of your real name server?
Please, post the real domain. You will be happy with the results you
get...
Dave...
[clip...]
------------------------------
Subject: Re: What is wrong with this bind configuration?
From: David Botham <DBotham at OptimusSolutions.com>
Date: Wed, 6 Oct 2004 15:56:38 -0400
bind-users-bounce at isc.org wrote on 10/06/2004 03:47:05 PM:
> Am Mi, den 06.10.2004 schrieb mistrzu um 18:16:
> > Whai did I do wrong?
>
> > Marcin
>
> Dig for your several mistypings: misspelled "example" and missing
> trailing dots.
I think both of these items are a consequence of the fact that the OP
replaced the real domain name with the "example" stuff. In doing so the
OP dropped trailing dots and misspelled things.
When posting you should post unaltered configs (exception that makes the
rule is removing TSIG keys and such). Also, tell us what the actual
domain name is and we may be able to help. Otherwise the problem
statement starts to sound something like:
"I am having a problem with some stuff. I can't tell you what that stuff
is, but, I was wondering if you could tell me what I am doing wrong..."
Dave...
>
> Alexander
>
>
> --
[clip..]
------------------------------
Date: Wed, 6 Oct 2004 14:50:18 -0700 (PDT)
From: Chris Timmons <cwt at networks.cwu.edu>
Subject: Re: daemon shutdown time with large zones (bind 9.2.4)
It would appear that FreeBSD's free(3) isn't the main issue here; I built
an image with the patch, and the performance is about the same as before.
More information about the bind-users
mailing list