How to upgrade

[sasa sasa]

Hi List,
 
I want to know how to upgrade from BIND 9.4.2 to latest version?
 
Thanks.
Blue


  ___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Double messages in comp.protocols.dns.bind

[Barry Margolin]

It looks like there are two mail-to-news gateways running for 
bind-users, so every message to the list is being posted twice to the 
newsgroup.  Here's a diff between the headers of two recent dups.

*** /tmp/header1  Sat Aug 22 11:09:39 2009
--- /tmp/header2  Sat Aug 22 11:09:43 2009
***
*** 1 
! Path: 
news.eternal-september.org!feeder.eternal-september.org!eternal-september
.org!news.glorb.com!news2.glorb.com!news.glorb.com!news.isc.org!nobody
--- 1 
! Path: 
news.eternal-september.org!feeder.eternal-september.org!eternal-september
.org!news.glorb.com!news2.glorb.com!news.glorb.com!news.isc.org!not-for-m
ail
***
*** 6,10 
! Organization: none
! Lines: 109
! Sender: n...@isc.org
! Approved: use...@isc.org
! Message-ID: 
--- 6,9 
! Organization: Internet Systems Consortium
! Lines: 105
! Approved: bind-users@lists.isc.org
! Message-ID: 
***
*** 12 
! NNTP-Posting-Host: news.isc.org
--- 11 
! NNTP-Posting-Host: webster.isc.org
***
*** 14 
! X-Trace: sf1.isc.org 1250387967 12225 204.152.184.108 (16 Aug 2009 
01:59:27 GMT)
--- 13,14 
! Content-Type: TEXT/plain; charset=us-ascii
! X-Trace: sf1.isc.org 1250387949 12182 204.152.184.12 (16 Aug 2009 
01:59:09 GMT)
***
*** 16,18 
! NNTP-Posting-Date: Sun, 16 Aug 2009 01:59:27 + (UTC)
! Return-Path: 
! X-Original-Message-ID: 
<200908160159.n7g1x3q8019...@metis.hicks-net.net>
--- 16,20 
! NNTP-Posting-Date: Sun, 16 Aug 2009 01:59:09 + (UTC)
! To: bind-users@lists.isc.org
! Return-Path: 
! X-Original-To: bind-us...@webster.isc.org
! Delivered-To: bind-us...@webster.isc.org
***
*** 25 
--- 28,31 
+ Precedence: list
+ List-Id: BIND Users Mailing List 
+ List-Unsubscribe: ,
+  
***
*** 31,32 
! Errors-To: bind-users-boun...@isc.org
! Xref: news.eternal-september.org comp.protocols.dns.bind:2013
--- 37 
! Xref: news.eternal-september.org comp.protocols.dns.bind:2014

-- 
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Format of 'dig -k' "TSIG key file"?

[Joseph S D Yao]

On Sat, Aug 22, 2009 at 02:45:19PM +0200, Hauke Lampe wrote:
> Joseph S D Yao wrote:
> 
> > It turned out that this latter file was needed, but for some
> > inexplicable reason perhaps having to do with library routines [I have
> > not gone chasing down the code], it ALSO wants the "mynet.private" file!
> 
> The nsupdate manpages mentions this behaviour in the "BUGS" section:
> 
> | BUGS
> |   The TSIG key is redundantly stored in two separate files. This
> |   is a consequence of nsupdate using the DST library for its
> |   cryptographic operations, and may change in future releases.
> 
> Maybe the dig manpage should, too, until it changes in future releases.


Given that the "new" 'nslookup' uses common library routines, this makes
sense.  And I believe someone even mentioned that, which was a big hint.
I am just not used to looking in the 'nslookup' manual entry for
information on 'dig'.  ;-)


-- 
/*\
**
** Joe Yao  j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Format of 'dig -k' "TSIG key file"?

[Hauke Lampe]

Joseph S D Yao wrote:

> It turned out that this latter file was needed, but for some
> inexplicable reason perhaps having to do with library routines [I have
> not gone chasing down the code], it ALSO wants the "mynet.private" file!

The nsupdate manpages mentions this behaviour in the "BUGS" section:

| BUGS
|   The TSIG key is redundantly stored in two separate files. This
|   is a consequence of nsupdate using the DST library for its
|   cryptographic operations, and may change in future releases.

Maybe the dig manpage should, too, until it changes in future releases.


Hauke.
--- dig.1.orig	2009-08-22 13:41:49.0 +0200
+++ dig.1	2009-08-22 14:44:52.0 +0200
@@ -200,9 +200,10 @@
 .PP
 To sign the DNS queries sent by
 \fBdig\fR
-and their responses using transaction signatures (TSIG), specify a TSIG key file using the
+and their responses using transaction signatures (TSIG), specify a pair of TSIG key files using the
 \fB\-k\fR
-option. You can also specify the TSIG key itself on the command line using the
+option, which can be generated by
+\fBdnssec\-keygen\fR. You can also specify the TSIG key itself on the command line using the
 \fB\-y\fR
 option;
 \fIhmac\fR
@@ -561,6 +562,8 @@
 .SH "BUGS"
 .PP
 There are probably too many query options.
+.PP
+The TSIG key is redundantly stored in two separate files. This is a consequence of dig using the DST library for its cryptographic operations, and may change in future releases.
 .SH "COPYRIGHT"
 Copyright \(co 2004\-2009 Internet Systems Consortium, Inc. ("ISC")
 .br


signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Reverse delegation - refused on my DNS

[Michael Monnerie]

"Mark Andrews"  schrieb:
> You do however have a delegation mismatch.
> 
> 48-28.164.69.212.in-addr.arpa. 86400 IN NS  dns1.zmi.at.
> 48-28.164.69.212.in-addr.arpa. 86400 IN NS  dns2.zmi.at.
> ;; Received 91 bytes from 82.98.222.6#53(dns2.serico.de) in 717 ms
> 
> 48-28.164.69.212.in-addr.arpa. 3600 IN  NS  power4u.zmi.at.
> 48-28.164.69.212.in-addr.arpa. 3600 IN  NS  dns2.zmi.at.
> 48-28.164.69.212.in-addr.arpa. 3600 IN  NS  dns1.zmi.at.
> ;; Received 161 bytes from 212.69.162.197#53(dns1.zmi.at) in 999 ms

Yes, the registered dns are dns[12], power4u is our old DNS which will be
replaced soon, but we still have it in the config until them. Shouldn't be
harmful, I hope.

Thanks for checking!

mfg zmi

(and sorry, again sending from webmail)


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FW: Delegating reverse DNS to a customer

[Chris Hills]

On 18/08/09 20:32, Kevin Darcy wrote:

No, you can't do a "sideways" delegation like that.

The correct solution, as stated elsewhere, is to get
251.250.63.in-addr.arpa delegated directly from ARIN to the customer.


Strictly speaking it is legal to use DNAME at the apex of a zone since 
DNAME only redirects descendant domains.


For example:-

251.250.63.in-addr.arpa. IN DNAME rev.cust.example.com.

And in the customer's zone:-
1.rev.cust.example.com. IN PTR ip63-250-251-1.cust.example.com.
ip63-250-251-1.cust.example.com. IN A 63.250.251.1

I do not disagree that in arin region swip is the way to go. Just 
showing that there is MTOWTDI!


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Porblems with Lycos.com host lookup.

[Mark Andrews]

In message <200908220352.n7m3qfwn030...@drugs.dv.isc.org>, Mark Andrews writes:
> 
> In message <65afb5970908210654s56231ce1g461a251fe9afa...@mail.gmail.com>, 
> Matt 
> writes:
> > Hi all,
> > 
> > 
> > 
> > We are seeing odd behaviour when attempting to look up the following url
> > from a range of Redhat servers.
> 
> The lycos.com servers are returning malformed responses.  The NS
> RRset should not be for lycosmail.lycos.com.  See RFC 1034 and RFC
> 2308.  This response is wrong whether you are following RFC 1034
> or RFC 1034 as modified by RFC 2308.
> 
> bigmail1.lycosmail.lycos.com. 3600 IN   CNAME   mail-bigmail1.bo3.lycos.com.
> lycosmail.lycos.com.3600IN  NS  ns1.lycos.com.
> lycosmail.lycos.com.3600IN  NS  ns2.lycos.com.
> lycosmail.lycos.com.3600IN  NS  ns3.lycos.com.
> lycosmail.lycos.com.3600IN  NS  ns4.lycos.com.
> ;; Received 214 bytes from 209.202.248.141#53(ns1.lycos.com) in 266 ms

The only time the above response is correct is when the query type is
ANY or CNAME.
 
> Since lycosmail.lycos.com, bo3.lycos.com and lycos.com all have the
> same servers this should have been the following for the A query
> (the NS RRset is optional).
> 
> bigmail1.lycosmail.lycos.com. 3600 IN   CNAME   mail-bigmail1.bo3.lycos.com.
> mail-bigmail1.bo3.lycos.com. 3332 INA   209.202.248.251
> bo3.lycos.com.3600IN  NS  ns1.lycos.com.
> bo3.lycos.com.3600IN  NS  ns2.lycos.com.
> bo3.lycos.com.3600IN  NS  ns3.lycos.com.
> bo3.lycos.com.3600IN  NS  ns4.lycos.com.
> 
> and the following for the MX and  queries (the NS and SOA RRsets
> are optional and you can't have the NS RRset without the SOA RRset).
> 
> bigmail1.lycosmail.lycos.com. 3600 IN   CNAME   mail-bigmail1.bo3.lycos.com.
> bo3.lycos.com.  2560IN  SOA invisible.lycos.com. 
> nic-tech.lycos-inc.com. 1250271200 16384 2048 1048
> 576 2560
> bo3.lycos.com.3600IN  NS  ns1.lycos.com.
> bo3.lycos.com.3600IN  NS  ns2.lycos.com.
> bo3.lycos.com.3600IN  NS  ns3.lycos.com.
> bo3.lycos.com.3600IN  NS  ns4.lycos.com.
> 
> If they weren't being served by the same servers then a referral
> to the bo3.lycos.com zone should have been returned RFC 1034.
> 
> > bigmail1.lycosmail.lycos.com  should resolve to 209.202.248.251 but we see
> > the following.
> > 
> > [...@ ~]$ host bigmail1.lycosmail.lycos.com
> > 
> > Host bigmail1.lycosmail.lycos.com not found: 2(SERVFAIL)
> > 
> > 
> > 
> > But then if we
> > 
> > 
> > 
> > [...@~]$ dig -t any bigmail1.lycosmail.lycos.com
> 
>   ANY queries don't follow CNAMEs.
>  
> > ; <<>> DiG 9.3.4-P1 <<>> -t any bigmail1.lycosmail.lycos.com
> > 
> > ;; global options:  printcmd
> > 
> > ;; Got answer:
> > 
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63245
> > 
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1
> > 
> > 
> > 
> > ;; QUESTION SECTION:
> > 
> > ;bigmail1.lycosmail.lycos.com.  IN  ANY
> > 
> > 
> > 
> > ;; ANSWER SECTION:
> > 
> > bigmail1.lycosmail.lycos.com. 3600 IN   CNAME   mail-bigmail1.bo3.lycos.com=
> > .
> > 
> > 
> > 
> > ;; AUTHORITY SECTION:
> > 
> > lycosmail.lycos.com.3600IN  NS  ns1.lycos.com.
> > 
> > lycosmail.lycos.com.3600IN  NS  ns2.lycos.com.
> > 
> > lycosmail.lycos.com.3600IN  NS  ns3.lycos.com.
> > 
> > lycosmail.lycos.com.3600IN  NS  ns4.lycos.com.
> > 
> > 
> > 
> > ;; ADDITIONAL SECTION:
> > 
> > ns4.lycos.com.  73682   IN  A   209.202.244.142
> > 
> > 
> > 
> > ;; Query time: 110 msec
> > 
> > ;; SERVER: 127.0.0.1#53(127.0.0.1)
> > 
> > ;; WHEN: Fri Aug 21 14:26:47 2009
> > 
> > ;; MSG SIZE  rcvd: 166
> > 
> > 
> > 
> > And then
> > 
> > 
> > 
> > [...@~]$ host bigmail1.lycosmail.lycos.com
> > 
> > bigmail1.lycosmail.lycos.com is an alias for mail-bigmail1.bo3.lycos.com.
> > 
> > mail-bigmail1.bo3.lycos.com has address 209.202.248.251
> 
>   Because names has cached the CNAME as the result of the ANY
>   query.
>  
> > errors we see in the bind log
> > 
> > 05-Aug-2009 12:53:36.118 resolver: debug 1: createfetch:
> > bigmail1.lycosmail.lycos.com A
> > 
> > 05-Aug-2009 12:53:36.202 lame-servers: info: FORMERR resolving
> > 'bigmail1.lycosmail.lycos.com/A/IN': 209.202.244.142#53
> > 
> > 05-Aug-2009 12:53:36.286 lame-servers: info: FORMERR resolving
> > 'bigmail1.lycosmail.lycos.com/A/IN': 209.202.248.142#53
> > 
> > 05-Aug-2009 12:53:36.369 lame-servers: info: FORMERR resolving
> > 'bigmail1.lycosmail.lycos.com/A/IN': 209.202.244.141#53
> > 
> > 05-Aug-2009 12:53:36.453 lame-servers: info: FORMERR resolving
> > 'bigmail1.lycosmail.lycos.com/A/IN': 209.202.248.141#53
> > 
> > 05-Aug-2009 12:53:36.453 resolver: debug 1: createfetch:
> > bigmail1.lycosmail.lycos.com A
> > 
> > 05-Aug-2009 12:53:36.537 lame-servers: info: FORMERR resolving
>