Undeliverable: bind-users Digest V6 #265

System Administrator administrator at home.grytsyuk.com
Fri Oct 8 07:57:45 UTC 2004


Your message
      To: 
      Subject: bind-users Digest V6 #265
      Sent:	Fri Oct 08 03:57:44 2004


did not reach the following recipient(s):
vitaliy at home.grytsyuk.com on Fri Oct 08 03:57:44 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 #265
Received: from mail pickup service by s1.home.grytsyuk.com with Microsoft SMTPSVC; Fri, 8 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.90; Fri, 08 Oct 2004 00:52:22 -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 mta237.mail.scd.yahoo.com with SMTP; Fri, 08 Oct 2004 00:52:19 -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 45F56284FE; Fri,  8 Oct 2004 07:52:08 +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 E1B4C5C8C8;	Fri,  8 Oct 2004 07:51:18 +0000 (UTC)	(envelope-from bind-users-bounce at isc.org)
Received: with ECARTIS (v1.0.0; list bind-users); Fri, 08 Oct 2004 07:50:01 +0000 (UTC)
Date: Fri, 08 Oct 2004 07:50:01 +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 #265
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: <20041008075118.E1B4C5C8C8 at rc3.isc.org>
X-GFI-P2E: S1
X-OriginalArrivalTime: 08 Oct 2004 07:57:32.0299 (UTC) FILETIME=[771F9DB0:01C4AD0C]

bind-users Digest	Thu, 07 Oct 2004	Volume: 06  Issue: 265

In This Issue:
		serial number format in dynamic dns update
		Re: serial number format in dynamic dns update
		Re: serial number format in dynamic dns update
		upgrade bind8.x to bind9.x in RH6.2
		Re: upgrade bind8.x to bind9.x in RH6.2
		Re: serial number format in dynamic dns update
		Re: serial number format in dynamic dns update
		Re: upgrade bind8.x to bind9.x in RH6.2
		Divided Permissions for DDNS?
		Re: serial number format in dynamic dns update
		Re: upgrade bind8.x to bind9.x in RH6.2
		Re: Divided Permissions for DDNS?
		Re: upgrade bind8.x to bind9.x in RH6.2
		Re: daemon shutdown time with large zones (bind 9.2.4)
		IPv6 prefixes in ACLs in BIND 9.3.0 and 9.2.4 ?
		Re: serial number format in dynamic dns update
		Re: serial number format in dynamic dns update
		DNS update via dhcp and static entries
		strange behavior of bind
		Re: Many '...query: . IN NS' in query log file
		zone transfer deferred due to quota
		Re: daemon shutdown time with large zones (bind 9.2.4)
		Undeliverable: bind-users Digest V6 #264
		How to handle short TTLs?
		Re: DNS update via dhcp and static entries
		Re: strange behavior of bind
		Re: Many '...query: . IN NS' in query log file
		Re: IPv6 prefixes in ACLs in BIND 9.3.0 and 9.2.4 ?
		Re: How to handle short TTLs?
		Re: DNS update via dhcp and static entries
		Re: DNS update via dhcp and static entries
		Re: How to handle short TTLs?
		Re: DNS update via dhcp and static entries
		Re: DNS update via dhcp and static entries
		Re: Many '...query: . IN NS' in query log file
		DNS Slave server CANNOT get zone files from Master Server
		Re: DNS Slave server CANNOT get zone files from Master Serve
		Re: DNS Slave server CANNOT get zone files from Master Serve
		Re: upgrade bind8.x to bind9.x in RH6.2 
		Re: strange behavior of bind 
		Re: How to handle short TTLs? 

----------------------------------------------------------------------

Date: Thu, 7 Oct 2004 04:15:12 -0700 (PDT)
From: saravanan ganapathy <sarav_gsa at yahoo.com>
Subject: serial number format in dynamic dns update

Hai,
  RFC suggests that serial number in SOA, should be in
the format of YYYYMMDDnn. 

How dyn.dns updates the serial number using this
format? 

What is the next serial number using dyndns update, if
the current serial number is '2004103199'?

Kindly clarify me


Sarav

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

------------------------------

Subject: Re: serial number format in dynamic dns update
From: Ketil Froyn <isc_bind at ketil.froyn.name>
Date: Thu, 07 Oct 2004 12:59:13 +0100

On Thu, 2004-10-07 at 12:15, saravanan ganapathy wrote:
> Hai,
>   RFC suggests that serial number in SOA, should be in
> the format of YYYYMMDDnn. 
> 
> How dyn.dns updates the serial number using this
> format? 
> 
> What is the next serial number using dyndns update, if
> the current serial number is '2004103199'?

An update to BIND adds 1 to the serial number, so the next number would
be 2004103200. Encoding a date in the serial number is just something
people do, and if the serial number were limited to the date format, you
would only be allowed to do 100 updates per 24 hours, which seems like a
somewhat arbitrary and unnecessary limitation.

For details on serial number arithmetic, see RFC1982:

  http://www.faqs.org/rfcs/rfc1982.html

For details on DNS UPDATE, see RFC2136, and specifically section 3.6 on
autoincrementing the serial number on updates:

  http://www.faqs.org/rfcs/rfc2136.html

The RFCs don't say that the server should add 1 on each update, but if
you want it to add something different, you can just include the new
serial you want in each update. As long as it increases (in the sense 
defined in RFC1982), it shouldn't make any difference.

I'm not sure which RFC says the format SHOULD(?) be YYYYMMDDnn, but I'll
guess that it is just a suggestion, and if it isn't, it is deprecated.

Ketil Froyn
ketil at froyn.name
http://ketil.froyn.name/


------------------------------

Date: Thu, 07 Oct 2004 15:20:00 +0200
From: Stefan Puiu <stefanpuiu at itcnetworks.ro>
Subject: Re: serial number format in dynamic dns update


I think that format is suggested if you only manually update your zone 
(by editing the zone file). Any DDNS update would trigger the 
incrementation of the serial number as specified in RFC 1982. I didn't 
have the patience to read the RFC thoroughly, but I noticed that in the 
BIND 9 code, they do something like this (it's a define): :

new_serial = (old_serial + 1) & 0xFFFFFFFF;
if (new_serial == 0) {
    new_serial = 1;
}

So, your serial number will become 2004103200. I suggest you read the 
RFC for the gory details.

saravanan ganapathy wrote:

>Hai,
>  RFC suggests that serial number in SOA, should be in
>the format of YYYYMMDDnn. 
>
>How dyn.dns updates the serial number using this
>format? 
>
>What is the next serial number using dyndns update, if
>the current serial number is '2004103199'?
>
>Kindly clarify me
>
>
>Sarav
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around 
>http://mail.yahoo.com 
>
>
>  
>


------------------------------

Date: Thu, 7 Oct 2004 07:29:58 -0700 (PDT)
From: saravanan ganapathy <sarav_gsa at yahoo.com>
Subject: upgrade bind8.x to bind9.x in RH6.2

Hai,
  Due to some reasons, still I am using RH6.2 where
bind8.2 is running. Now I need to upgrade to bind 9.x 
and got the following error when I start named after
upgradation 

# /etc/rc.d/init.d/named start

Starting named: named: -u not supported on Linux
kernels older than 2.3.99-pre3 or 2.2.18 when using
threads
                                                      
    [FAILED]

If I haven't specified '-u named' option in named
script, then it will try to start bind as root user.

Is there any way I can run bind using 'named' user?


Sarav




		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

------------------------------

Date: Thu, 7 Oct 2004 07:41:29 -0700
From: Steve Friedl <steve at unixwiz.net>
Subject: Re: upgrade bind8.x to bind9.x in RH6.2

On Thu, Oct 07, 2004 at 07:29:58AM -0700, saravanan ganapathy wrote:
> Hai,
>   Due to some reasons, still I am using RH6.2 where
> bind8.2 is running. Now I need to upgrade to bind 9.x 
> and got the following error when I start named after
> upgradation 
> 
> # /etc/rc.d/init.d/named start
> 
> Starting named: named: -u not supported on Linux
> kernels older than 2.3.99-pre3 or 2.2.18 when using
> threads
>                                                       
>     [FAILED]
> 
> If I haven't specified '-u named' option in named
> script, then it will try to start bind as root user.
> 
> Is there any way I can run bind using 'named' user?

Rebuild BIND and add --disable-threads to the ./configure args

Steve

-- 
Stephen J Friedl | Security Consultant |  UNIX Wizard  |   +1 714 544-6561
www.unixwiz.net  | Tustin, Calif. USA  | Microsoft MVP | steve at unixwiz.net

------------------------------

Date: Thu, 07 Oct 2004 07:47:56 -0700
From: Norman Zhang <norman.zhang at rd.arkonnetworks.com>
Subject: Re: serial number format in dynamic dns update

>RFC suggests that serial number in SOA, should be in
>the format of YYYYMMDDnn. 
>
>How dyn.dns updates the serial number using this
>format? 
>
>What is the next serial number using dyndns update, if
>the current serial number is '2004103199'?

I'm not sure if this has been discussed, Verisign is pushing for a new 
format.

http://www.verisign.com/products-services/naming-and-directory-services/naming-services/page_005513.html

In bind 9.2.3 and dhcp 3.0.1, I can only use yyyymmdd format. Is this by 
design?

Regards,
Norman

------------------------------

Date: Thu, 7 Oct 2004 16:16:55 +0100
From: Simon Hobson <shobson0309 at colony.com>
Subject: Re: serial number format in dynamic dns update

Norman Zhang wrote:
>  >RFC suggests that serial number in SOA, should be in
>>the format of YYYYMMDDnn.
>>
>>How dyn.dns updates the serial number using this
>>format?
>>
>>What is the next serial number using dyndns update, if
>>the current serial number is '2004103199'?
>
>I'm not sure if this has been discussed, Verisign is pushing for a new
>format.
>
>http://www.verisign.com/products-services/naming-and-directory-services/naming-services/page_005513.html
>
>In bind 9.2.3 and dhcp 3.0.1, I can only use yyyymmdd format. Is this by
>design?

Well with Bind 9.2.2 and dhcp 3.0.1 (what I'm running here) there is 
no such constraint - DHCPD doesn't know or care what the serial 
number is. As far as Bind is concerned (and I assume any RFC 
compliant DNS server) the serial number is just a number, nothing 
more, nothing less. If it HAPPENS to be something 'human friendly' 
then that's a plus, but Bind just doesn't care - to it 2004100700 is 
just a large integer (0x7774265c if I've got it right !). As long as 
it keeps getting larger (whether by 1 to 2004100701 or by 100 to 
2004100800) then no-one actually cares !

What verisign are saying doesn't affect this - they are merely 
recognising that with the new update regime, they are likely to 
exceed 100 updates/day and so the ddddmmyyxx format would break down, 
so they are simply reverting to treating the serial number as a 
number and have chosen to use the unix time in seconds which is a) 
guaranteed to increase until 2038, and b) can be translated to a time 
in case anyone did want to work out when an update occurred.

If you use DDNS, you CAN use yyyymmddxx (but the date will become 
meaningless over a while), you CAN do the Verisign method, or you CAN 
just start at ONE and keep incrementing - BIND DOESN'T CARE !

Simon

-- 

NOTE: This is a throw-away email address which will reach me for as 
long as it stays spam-free, remove date for real address.

Simon Hobson MA MIEE, Technology Specialist
Colony Gift Corporation Limited
Lindal in Furness, Ulverston, Cumbria, LA12 0LD
Tel 01229 461100, Fax 01229 461101

Registered in England No. 1499611
Regd. Office : 100 New Bridge Street, London, EC4V 6JA.

------------------------------

Date: Thu, 7 Oct 2004 08:02:23 -0700 (PDT)
From: saravanan ganapathy <sarav_gsa at yahoo.com>
Subject: Re: upgrade bind8.x to bind9.x in RH6.2

I did upgradation using rpm package. Is there any way
to disable threads in this method?

Sarav 


--- Steve Friedl <steve at unixwiz.net> wrote:

> On Thu, Oct 07, 2004 at 07:29:58AM -0700, saravanan
> ganapathy wrote:
> > Hai,
> >   Due to some reasons, still I am using RH6.2
> where
> > bind8.2 is running. Now I need to upgrade to bind
> 9.x 
> > and got the following error when I start named
> after
> > upgradation 
> > 
> > # /etc/rc.d/init.d/named start
> > 
> > Starting named: named: -u not supported on Linux
> > kernels older than 2.3.99-pre3 or 2.2.18 when
> using
> > threads
> >                                                   
>    
> >     [FAILED]
> > 
> > If I haven't specified '-u named' option in named
> > script, then it will try to start bind as root
> user.
> > 
> > Is there any way I can run bind using 'named'
> user?
> 
> Rebuild BIND and add --disable-threads to the
> ./configure args
> 
> Steve
> 
> -- 
> Stephen J Friedl | Security Consultant |  UNIX
> Wizard  |   +1 714 544-6561
> www.unixwiz.net  | Tustin, Calif. USA  | Microsoft
> MVP | steve at unixwiz.net
> 



		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

------------------------------

Date: Thu, 7 Oct 2004 17:35:06 +0200 (MEST)
From: "Tom Schmitt" <TomSchmitt at gmx.de>
Subject: Divided Permissions for DDNS?


Hi,

I run a Bind 9.3 with DDNS authenticated via TSIG, which works fine.

Now I have a domain in which more than one source must have the rights to do
dynamic updates via TSIG. 
Is there a way to avoid collisions? To give the right-permissions in a way,
that a record that is written by source_A not could be deleted by source_B?

And, one step further, is it still possible for an administrator to have the
rights to delete records regardless of the ownership by source_A or
source_B?

Thanks,
Tom.

-- 
GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
+++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++


------------------------------

Date: Thu, 07 Oct 2004 09:13:47 -0700
From: Norman Zhang <norman.zhang at rd.arkonnetworks.com>
Subject: Re: serial number format in dynamic dns update

Simon Hobson wrote:
> If you use DDNS, you CAN use yyyymmddxx (but the date will become 
> meaningless over a while), you CAN do the Verisign method, or you CAN 
> just start at ONE and keep incrementing - BIND DOESN'T CARE !

Thanks for the explanation. So the format should be yyyymmddxx not 
yyyymmddxxxx? I tried yyyymmddxxxx, and got

** server can't find mail.hq.arkonnetworks.com: SERVFAIL

I'll read up on Verisign method, it looks like a plausible method.

Regards,
Norman

------------------------------

Date: Thu, 7 Oct 2004 09:21:55 -0700
From: Steve Friedl <steve at unixwiz.net>
Subject: Re: upgrade bind8.x to bind9.x in RH6.2

On Thu, Oct 07, 2004 at 08:02:23AM -0700, saravanan ganapathy wrote:
> I did upgradation using rpm package. Is there any way
> to disable threads in this method?

I have no idea - I never use RPMs: I always build from source,

Instructions can be found here:

	Building and configuring BIND 9 in a chroot jail
	http://www.unixwiz.net/techtips/bind9-chroot.html

Good luck,
Steve

--- 
Stephen J Friedl | Security Consultant |  UNIX Wizard  |   +1 714 544-6561
www.unixwiz.net  | Tustin, Calif. USA  | Microsoft MVP | steve at unixwiz.net

------------------------------

From: Paul Vixie <vixie at sa.vix.com>
Subject: Re: Divided Permissions for DDNS?
Date:  07 Oct 2004 16:24:25 +0000

> Now I have a domain in which more than one source must have the rights to
> do dynamic updates via TSIG.  Is there a way to avoid collisions? To give
> the right-permissions in a way, that a record that is written by source_A
> not could be deleted by source_B?

no.  not in bind, and not in rfc2136.  source_A and source_B could choose to
cooperate, by adding a TXT RR or some other marker whose text must match the
creator's identity as a prerequisite of subsequent updates.  but DNS UPDATE
has no arbitration mechanism for non-cooperating updators.

i once thought that some rule of the form "a host ought to be allowed to
change the PTR for its own address" would be useful, but ip source address
authorization/authentication is unsafe in an anti-BCP38 world like ours.
perhaps a similar rule involving IPSEC will evolve over time.
-- 
Paul Vixie

------------------------------

Date: Thu, 07 Oct 2004 19:36:10 +0200
From: Stefan Puiu <stefanpuiu at itcnetworks.ro>
Subject: Re: upgrade bind8.x to bind9.x in RH6.2


You shouldn't be able to do that, you can switch threading support 
on/off only at compile-time (using the ./configure option mentioned 
above). Upgrading your kernel could also be an option, but I don't know 
if this solution suits your environment.

saravanan ganapathy wrote:

>I did upgradation using rpm package. Is there any way
>to disable threads in this method?
>
>Sarav 
>
>
>--- Steve Friedl <steve at unixwiz.net> wrote:
>
>  
>
>>On Thu, Oct 07, 2004 at 07:29:58AM -0700, saravanan
>>ganapathy wrote:
>>    
>>
>>>Hai,
>>>  Due to some reasons, still I am using RH6.2
>>>      
>>>
>>where
>>    
>>
>>>bind8.2 is running. Now I need to upgrade to bind
>>>      
>>>
>>9.x 
>>    
>>
>>>and got the following error when I start named
>>>      
>>>
>>after
>>    
>>
>>>upgradation 
>>>
>>># /etc/rc.d/init.d/named start
>>>
>>>Starting named: named: -u not supported on Linux
>>>kernels older than 2.3.99-pre3 or 2.2.18 when
>>>      
>>>
>>using
>>    
>>
>>>threads
>>>                                                  
>>>      
>>>
>>   
>>    
>>
>>>    [FAILED]
>>>
>>>If I haven't specified '-u named' option in named
>>>script, then it will try to start bind as root
>>>      
>>>
>>user.
>>    
>>
>>>Is there any way I can run bind using 'named'
>>>      
>>>
>>user?
>>
>>Rebuild BIND and add --disable-threads to the
>>./configure args
>>
>>Steve
>>
>>-- 
>>Stephen J Friedl | Security Consultant |  UNIX
>>Wizard  |   +1 714 544-6561
>>www.unixwiz.net  | Tustin, Calif. USA  | Microsoft
>>MVP | steve at unixwiz.net
>>
>>    
>>
>
>
>
>		
>_______________________________
>Do you Yahoo!?
>Declare Yourself - Register online to vote today!
>http://vote.yahoo.com
>
>
>  
>


------------------------------

Date: Thu, 7 Oct 2004 09:47:09 -0700 (PDT)
From: Chris Timmons <cwt at networks.cwu.edu>
Subject: Re: daemon shutdown time with large zones (bind 9.2.4)


> - did you try that with or without ISC_MEM_USE_INTERNAL_MALLOC (or
>   both)?  After re-checking the patch, I noticed it was not effective
>   when ISC_MEM_USE_INTERNAL_MALLOC is enabled.  (sorry, this was my
>   bad again).

I tried it without ISC_MEM_USE_INTERNAL_MALLOC (since that was the
original worst-case), and the time stayed about the same as the
worst-case.

> - did you see the long period to shutdown the server even just after
>   starting it?  If the bottleneck is not really in the memory
>   management but in that code traversing the DB structure, the problem
>   should occur even if the server does no actual work (i.e., only just
>   loading and destroying the DB).

My testing scenario has been to run the daemon in the foreground with
"-g", and then shutdown via ^C as soon as the large zone has been loaded.
So we are just loading and destroying the DB.

-Chris

------------------------------

Subject: IPv6 prefixes in ACLs in BIND 9.3.0 and 9.2.4 ?
From: Jason Vas Dias <jvdias at redhat.com>
Date: Thu, 07 Oct 2004 12:50:16 -0400

How can I specify an IPv6 address prefix in an ACL ?

This problem occurs on both BIND 9.3.0 and BIND 9.2.4 .

Whenever I try to specify an IPv6 address prefix in an ACL,
named-checkconf fails with :

   missing ';' before '/'
   expected IP match list element near '/'


I've tried:

acl test {
	fec0:ac10:40a5:1/64;
};

acl test {
	fec0:ac10:40a5:0001/64;
};

acl test {
	fec0:ac10:40a5:0001 / 64;
};

acl test {
	fec0:ac10:40a5:1:/64;
};

acl test {
	f.e.c.0.a.c.1.0.4.0.a.5.0.0.0.1/64;
};

The Bv9ARM states:

"
The elements which constitute an address match list can be any of the
following:

      * an IP address (IPv4 or IPv6)
        
      * an IP prefix (in the `/'-notation)
"

Since both IPv4 and IPv6 addresses can be specified,
I'm led to assume "IP prefix" means 'IPv4 or IPv6 prefix' - am I wrong ?

Am I missing something ?
Anyone have any ideas how to do this ?



------------------------------

Subject: Re: serial number format in dynamic dns update
From: David Botham <DBotham at OptimusSolutions.com>
Date: Thu, 7 Oct 2004 14:19:11 -0400

bind-users-bounce at isc.org wrote on 10/07/2004 07:15:12 AM:
> Hai,
>   RFC suggests that serial number in SOA, should be in
> the format of YYYYMMDDnn. 
> 
> How dyn.dns updates the serial number using this
> format? 

The format above is for serial numbers managed by humans.  Since humans do 
not manage the serial number of dynamic zones, there is no need for this 
format.


[clip...]


Dave...


------------------------------

Subject: Re: serial number format in dynamic dns update
From: David Botham <DBotham at OptimusSolutions.com>
Date: Thu, 7 Oct 2004 14:28:10 -0400

bind-users-bounce at isc.org wrote on 10/07/2004 12:13:47 PM:
> Simon Hobson wrote:
> > If you use DDNS, you CAN use yyyymmddxx (but the date will become 
> > meaningless over a while), you CAN do the Verisign method, or you CAN 
> > just start at ONE and keep incrementing - BIND DOESN'T CARE !
> 
> Thanks for the explanation. So the format should be yyyymmddxx not 
> yyyymmddxxxx? I tried yyyymmddxxxx, and got

Yes, that is about right.  The serial number is a 32 bit number.  The 
number of digits you have shown above would give you number more than 32 
bits.

Dave...


> 
> ** server can't find mail.hq.arkonnetworks.com: SERVFAIL
> 
> I'll read up on Verisign method, it looks like a plausible method.

A 32 bit number can be as large as 4,294,967,296.  Start the SOA for your 
dynamic zones at 1 and let them grown from there.  After you have applied 
4 Billion, 200 or so Million updates you will have to worry about 
adjusting your serial numbers.


Dave...

> 
> Regards,
> Norman
> 



------------------------------

From: Andreas Moroder <amoroder at sb-brixen [nospam].it>
Subject: DNS update via dhcp and static entries
Date: Thu, 07 Oct 2004 15:14:29 +0200

Hello,

this is a little bit OT but I did not find a dhcp newsgroup.
Our dhcp updates the dns and all works well except for machines where we 
have set fixed IP addresse via MAC.
Is it dhcp that does not send the updates or can it be a problem in bin ?

Thanks

------------------------------

From: john_doe_rules at yahoo.de (john doe)
Subject: strange behavior of bind
Date:  7 Oct 2004 05:26:31 -0700

Hi there,

i have a problem with my bind (9.2.3) I want to run bind in two
instances of one maschine(ext-DNS and int-DNS). I`ve already
configured bind. And it works fine for each config-file.
I bound the one DNS-instance on an Address xxx.xxx.xxx.152 the other
on xxx.xxx.xxx.172. If i start one or the other, all works fine. I can
querry local Addresses/Domains and non-local Addresses/Domains. But
when i start them both, they`re acting strange. I can querry local
Addresses/Domains on both of them, but only one of them answers
querries for non-local Addresses/Domains such as cisco.com. Both have
their forwarders. It is allways the second started instance of bind
that works fine. If i start xxx.xxx.xxx.152 and then xxx.xxx.xxx.171
then xxx.xxx.xxx.172 works fine, the other one gets timeouts. If i
start at first xxx.xxx.xxx.171 and in second xxx.xxx.xxx.152 then
xxx.xxx.xxx.152 works fine. If i stop one of them the other one works
fine.
If i make a netstat -ln ig goth the following lines:

tcp        0      0 xxx.xxx.xxx.152:53        0.0.0.0:*              
LISTEN
tcp        0      0 xxx.xxx.xxx.171:53        0.0.0.0:*              
LISTEN
udp        0      0 xxx.xxx.xxx.152:53        0.0.0.0:*
udp        0      0 xxx.xxx.xxx.171:53        0.0.0.0:*

which is Ok i guess, but i also get this line, which maybe causes the
problem:

udp        0      0 0.0.0.0:53              0.0.0.0:*

Why is the Port 53 bound to udp 0.0.0.0? In the named-int.conf i
define:
listen-on port 53 { xxx.xxx.xxx.152; }; 
similar in the named-ext.conf:
listen-on port 53 { xxx.xxx.xxx.171; }; 

I hope somebody can help me. And please forgive my poor english. 

Torsten

------------------------------

Subject: Re: Many '...query: . IN NS' in query log file
From: Nicolas Ecarnot <nicolas.ecarnot at alussinan.org>
Date: 07 Oct 2004 08:35:32 GMT

David Botham <DBotham at OptimusSolutions.com> wrote in
news:ck1i5t$lso$1 at sf1.isc.org: 

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

It seems clear, but is this normal that those servers asks that every ten 
second ?
Aren't they supposed to keep a cache of this kind of information ?

-- 
Nicolas Ecarnot

------------------------------

From: "afaf" <afaf.e at menara.ma>
Subject: zone transfer deferred due to quota
Date: Thu, 7 Oct 2004 10:49:51 -0000

Hi;
    I have upgraded a dns server wich is configured as a slave from 9.2.3 to 9.3.0 
but in my log file , i have got a strange message : "zone zone_name/IN: zone transfer deferred due to quota"
What does this mean ?



Best regards,

------------------------------

Date: Fri, 08 Oct 2004 03:57:33 +0900
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei at isl.rdc.toshiba.co.jp>
Subject: Re: daemon shutdown time with large zones (bind 9.2.4)

>>>>> On Thu, 7 Oct 2004 09:47:09 -0700 (PDT), 
>>>>> Chris Timmons <cwt at networks.cwu.edu> said:

>> - did you try that with or without ISC_MEM_USE_INTERNAL_MALLOC (or
>> both)?  After re-checking the patch, I noticed it was not effective
>> when ISC_MEM_USE_INTERNAL_MALLOC is enabled.  (sorry, this was my
>> bad again).

> I tried it without ISC_MEM_USE_INTERNAL_MALLOC (since that was the
> original worst-case), and the time stayed about the same as the
> worst-case.

>> - did you see the long period to shutdown the server even just after
>> starting it?  If the bottleneck is not really in the memory
>> management but in that code traversing the DB structure, the problem
>> should occur even if the server does no actual work (i.e., only just
>> loading and destroying the DB).

> My testing scenario has been to run the daemon in the foreground with
> "-g", and then shutdown via ^C as soon as the large zone has been loaded.
> So we are just loading and destroying the DB.

I see, thanks for the information.  Then I tend to agree that the
problem is in the data structure or the algorithm.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei at isl.rdc.toshiba.co.jp

------------------------------

From: "System Administrator" <administrator at home.grytsyuk.com>
Subject: Undeliverable: bind-users Digest V6 #264
Date: 7 Oct 2004 03:57:40 -0400

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