named shows different results

[Tim]

On Wed, 2011-06-29 at 19:26 +0200, fedora wrote:
> I changed some CNAME entries in the named for a specific domain this 
> morning.

How did you make the change, and where?  And how is the change supposed
to propagate to the other name servers?
> 
> when i now (from an internal workstation) do a
> dig @nameserver cname
> 
> i get a different answer, depending on whether @nameserver points to
> the local address 192.168.... or on the public ip address 212.90.....
> of the nameserver
>  
> in the first case, named returns the old (incorrect) address of cname.
> in the second case, named returns the new (correct) address of cname.
>  
> when i let @nameserver point to the secondary nameserver, the above 
> difference does not show up, it always returns the correct address.
>  
> from the outside world, the new (correct) value is always returned.

And, how have you set up your domain records?

If they have a long time to live, then anything that has queried that
record can cache the results for that length of time, before bothering a
master server to check for newer records.  Likewise with any client that
has queried any server.

Long expiry times reduce network traffic, but can cause stale data to be
served by slave servers for a longer time.

Master servers can be configured to notify their slaves to update their
records, when master records are changed, but that's an option, not a
mandatory behaviour.

Also, when you changed your record data, did you (or some software)
update the zone's serial number.  If the serial number doesn't
increment, then no slave (or client?) may consider checking for updates
to records.

There's several bits of data in a zone file that are related to the need
to check for updates to any records in it.

Serial number - must increment when any records are changed.  If the
serial hasn't changed, then the records are considered to be the same as
last time (and this will affect anything related to what I mention
below).  If it has changed, then slaves/clients should get new data,
now.  Of course, they may not bother to check, if they've cached
records, and when they did the caching, they were told to hang onto the
data for a long time.  They'll check the serial number, then update
records, after their caching periods.

Refresh period - slaves will check the master for any changes /this/
many seconds after the last query.

Retry period - wait /this/ many seconds before trying again, if the
master didn't respond.

Retire period - expire any cached records /this/ many seconds since they
were cached/updated, if unable to refresh them.  i.e. The slave can dole
out old information for this amount of time, then expunge it.

Time to live period - other servers should dole out and hold onto their
cached data for /this/ amount of time, even if they should have tried
updating in the meantime, but hadn't been able to.

-- 
[tim at localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686

Don't send private replies to my address, the mailbox is ignored.  I
read messages from the public lists.