From owner-freebsd-questions Mon Aug 17 22:08:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA00520 for freebsd-questions-outgoing; Mon, 17 Aug 1998 22:08:26 -0700 (PDT) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from buddy.palomine.net (buddy.palomine.net [205.198.88.50]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA00513 for ; Mon, 17 Aug 1998 22:08:24 -0700 (PDT) (envelope-from cjohnson@palomine.net) Received: (qmail 12893 invoked by uid 500); 18 Aug 1998 05:07:50 -0000 Message-ID: <19980818010750.A12861@palomine.net> Date: Tue, 18 Aug 1998 01:07:50 -0400 From: Chris Johnson To: questions@FreeBSD.ORG, romank@graphnet.com Subject: Re: DNS References: <199808172038.NAA14599@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <199808172038.NAA14599@hub.freebsd.org>; from questions-digest on Mon, Aug 17, 1998 at 01:38:33PM -0700 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Friday, I changed some DNS info on our server. Today, some servers > know about this and others don't. That it, nslookup yields the old > result on some. Is this normal, or should I change something to make it > propagate faster? You'll just have to wait. Name servers cache what they learn in the course of their queries, and answer requests out of cache when they can. They'll keep answering out of cache until the TTL, which you supply in your SOA or in particular RRs, expires, and then they'll requery authoritative servers for fresh information. Also, slave servers (as they're known in BIND 8.1.x -- the were formerly known as secondaries) will refresh their own information according to the refresh you supply in your SOA (BIND 8.1.x supports NOTIFY, so if both master and slave are running 8.1.x and are listed as name servers in the zone file, the change on the slave will be instant). Both the TTL and the refresh contribute to the delays you're seeing. At worst, a name server out there on the Internet should not have data older than the TTL added to the refresh time. In the future, if you're going to change an address or an MX record or whatever and you want the change to happen more quickly, you can start lowering the TTL as the time for the change approaches. When you're very close to the time to make the change, lower it to something like 60 seconds, or even 0 seconds. After you've made the address change, reload the secondaries (if you have access to them) and restore the TTL to a normal value. This will minimize or eliminate the time that stale data remains cached on name servers around the world. I hope this isn't more than you wanted to know! Chris Johnson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message