From owner-freebsd-questions Mon Nov 11 13: 4:37 2002 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D35FA37B401 for ; Mon, 11 Nov 2002 13:04:30 -0800 (PST) Received: from pebbles.dgsi.com (pebbles.dgsi.com [192.80.15.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D06F43E7B for ; Mon, 11 Nov 2002 13:04:30 -0800 (PST) (envelope-from pds@pebbles.dgsi.com) Received: from pebbles.dgsi.com (localhost [127.0.0.1]) by pebbles.dgsi.com (8.12.6/8.12.6) with ESMTP id gABL4SME011583 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 11 Nov 2002 13:04:28 -0800 (PST) (envelope-from pds@pebbles.dgsi.com) Received: (from pds@localhost) by pebbles.dgsi.com (8.12.6/8.12.6/Submit) id gABL4SH9011582 for freebsd-questions@FreeBSD.ORG; Mon, 11 Nov 2002 13:04:28 -0800 (PST) (envelope-from pds) Date: Mon, 11 Nov 2002 13:04:28 -0800 From: Peter Schoenmaker To: freebsd-questions@FreeBSD.ORG Subject: Re: dns resolution problems Message-ID: <20021111210428.GA11558@dgsi.com> References: <20021111203813.GE11081@dgsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.21 (www . roaringpenguin . com / mimedefang) Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Nov 11, 2002 at 02:54:57PM -0600, Charles Pelletier wrote: > are you absolutely sure your DNS info is correct? need current information: > what is your service provider? verio > what are the DNS numbers you are currently using? i have used 192.80.15.4 (my own server) bind config attached. I have also had the same problem with 129.250.35.250, and 129.250.35.251 > are there any other errors that you receive? doesn't seem to be any errors. > > from the information you have given, everything points towards bad DNS info, > but, as you are positive it is NOT bad DNS info, please post your > /etc/resolv.conf as you currently have it. $ more /etc/resolv.conf search lugs.com nameserver 192.80.15.4 $ // $FreeBSD: src/etc/namedb/named.conf,v 1.6.2.5 2002/02/04 18:24:21 ume Exp $ // // Refer to the named.conf(5) and named(8) man pages for details. If // you are ever going to setup a primary server, make sure you've // understood the hairy details of how DNS is working. Even with // simple mistakes, you can break connectivity for affected parties, // or cause huge amount of useless Internet traffic. options { directory "/etc/namedb"; recursion yes; // In addition to the "forwarders" clause, you can force your name // server to never initiate queries of its own, but always ask its // forwarders only, by enabling the following line: // // forward only; // If you've got a DNS server around at your upstream provider, enter // its IP address here, and enable the line below. This will make you // benefit from its cache, thus reduce overall DNS traffic in the Internet. /* forwarders { 127.0.0.1; }; */ /* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ query-source address * port 53; /* * If running in a sandbox, you may have to specify a different * location for the dumpfile. */ // dump-file "s/named_dump.db"; }; /* logging { channel debug_for_pds { file "/var/log/named-debug.log" versions 10 size 20m; print-time yes; print-category yes; }; category default { debug_for_pds; }; category config { default_syslog; default_stderr; debug_for_pds; }; category parser { default_syslog; default_stderr; debug_for_pds; }; category queries { default_syslog; default_stderr; debug_for_pds; }; category lame-servers { default_syslog; default_stderr; debug_for_pds; }; category statistics { default_syslog; default_stderr; debug_for_pds; }; category panic { default_syslog; default_stderr; debug_for_pds; }; category update { default_syslog; default_stderr; debug_for_pds; }; category ncache { default_syslog; default_stderr; debug_for_pds; }; category xfer-in { default_syslog; default_stderr; debug_for_pds; }; category xfer-out { default_syslog; default_stderr; debug_for_pds; }; category db { default_syslog; default_stderr; debug_for_pds; }; category eventlib { debug_for_pds; }; category packet { debug_for_pds; }; category notify { debug_for_pds; }; category cname { debug_for_pds; }; category security { debug_for_pds; }; category os { debug_for_pds; }; category insist { debug_for_pds; }; category maintenance { debug_for_pds; }; category load { debug_for_pds; }; category response-checks { debug_for_pds; }; }; */ // Note: the following will be supported in a future release. /* host { any; } { topology { 127.0.0.0/8; }; }; */ // Setting up secondaries is way easier and the rough picture for this // is explained below. // // If you enable a local name server, don't forget to enter 127.0.0.1 // into your /etc/resolv.conf so this server will be queried first. // Also, make sure to enable it in /etc/rc.conf. zone "." { type hint; file "named.root"; }; zone "0.0.127.IN-ADDR.ARPA" { type master; file "localhost.rev"; }; zone "1.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-v6.rev"; }; // NB: Do not use the IP addresses below, they are faked, and only // serve demonstration/documentation purposes! // // Example secondary config entries. It can be convenient to become // a secondary at least for the zone where your own domain is in. Ask // your network administrator for the IP address of the responsible // primary. // // Never forget to include the reverse lookup (IN-ADDR.ARPA) zone! // (This is the first bytes of the respective IP address, in reverse // order, with ".IN-ADDR.ARPA" appended.) // // Before starting to setup a primary zone, better make sure you fully // understand how DNS and BIND works, however. There are sometimes // unobvious pitfalls. Setting up a secondary is comparably simpler. // // NB: Don't blindly enable the examples below. :-) Use actual names // and addresses instead. // // NOTE!!! FreeBSD can run bind in a sandbox (see named_flags in rc.conf). // The directory containing the secondary zones must be write accessible // to bind. The following sequence is suggested: // // mkdir /etc/namedb/s // chown bind:bind /etc/namedb/s // chmod 750 /etc/namedb/s zone "lugs.com" in { type master; notify no; file "master/lugs.com"; }; /* zone "domain.com" { type slave; file "s/domain.com.bak"; masters { 192.168.1.1; }; }; zone "0.168.192.in-addr.arpa" { type slave; file "s/0.168.192.in-addr.arpa.bak"; masters { 192.168.1.1; }; }; */ > > > Charles Pelletier > Tech. Coordinator > St Luke's School > Irving, TX > > -----Original Message----- > From: owner-freebsd-questions@FreeBSD.ORG > [mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of Peter > Schoenmaker > Sent: Monday, November 11, 2002 2:38 PM > To: Miroslav Pendev > Cc: freebsd-questions > Subject: Re: dns resolution problems > > > On Mon, Nov 11, 2002 at 02:28:41PM -0500, Miroslav Pendev wrote: > > Hi Peter > > > > > I am having problems resolving hosts with freebsd. > > > > It looks to me as the DNS servers in your /etc/resolv.conf > > are not working well... > > I have used multiple different name servers and have used the same > name server on windows, solaris, and freebsd. > > > > > > Specificly i have > > > problems resolving hosts @ united airlines. These include www.ual.com, > > > www.united.com, www.ua2go.com, www.itn.net. Some of them use different > > > dns servers but they still have the problem. I have tried to look into > > > the problem but can't find it. The problem doesn't occur on solaris > > > 2.8/2.9, or windows. > > > > Probably because the other boxes use diferent DNS servers. Try to use > > the same DNS servers on the FreeBSD box. > > configured with the same nameservers. > > peter > > > > > > I am running FreeBSD 4.7 RELEASE, and the box > > > is not behind a firewall. I have tried having the box resolve again > > > multiple DNS servers with the same result. Does anyone have any ideas, > > > or are experiencing the same problem? > > > > > > peter > > > > I have FreeBSD 4.7 RELEASE and I can resolve all of these without > > a problem. > > > > Sometimes if there is a DNS problem (or change) win box can still resolv > > old IP, because of the DNS cash... until you reboot the system. > > > > To think that FreeBSD itself have something to do with this problem > > is ridiculous :-) > > > > Miro > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message