Date: Mon, 11 Nov 2002 13:04:28 -0800 From: Peter Schoenmaker <pds@dgsi.com> To: freebsd-questions@FreeBSD.ORG Subject: Re: dns resolution problems Message-ID: <20021111210428.GA11558@dgsi.com> In-Reply-To: <ODEGKNHJNPDPKJOOAOKOIEIFCCAA.fozekizer@attbi.com> References: <20021111203813.GE11081@dgsi.com> <ODEGKNHJNPDPKJOOAOKOIEIFCCAA.fozekizer@attbi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021111210428.GA11558>