From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 22:08:31 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABED937B401 for ; Fri, 18 Apr 2003 22:08:31 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id D692543FBF for ; Fri, 18 Apr 2003 22:08:30 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D365915210; Sat, 19 Apr 2003 14:09:43 +0900 (JST) Date: Sat, 19 Apr 2003 14:08:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jeremy Chadwick In-Reply-To: <20030418234119.GA85777@parodius.com> References: <20030418201645.GA77986@parodius.com> <1050703016.604363.667.nullmailer@cicuta.babolo.ru> <20030418234119.GA85777@parodius.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 26 cc: freebsd-net@freebsd.org Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 05:08:32 -0000 >>>>> On Fri, 18 Apr 2003 16:41:19 -0700, >>>>> Jeremy Chadwick said: > Under what circumstances would the primary request data from > the secondary on it's _public_ IP? My query-source directive > is set to the public IP, and this IP should (according to BIND > documentation) be used by both TCP and UDP queries (port #, > however, cannot be guaranteed). You seemed to misunderstand the comment. It said "the problematic situation can happen when ***the secondary sends a query from its public address to the primary's private address***": query secondary:----------------->primary 64.71.184.190 10.0.0.1 (rejected)<---- response So I guess you should look at the configuration in secondary, not primary. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp