Re: named shows different results

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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.



-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux