Hi Tim i think the problem comes from the different views a DNS provides. in my config i should be more specific about which zone belongs to which view. On an internal view (which by default i catch when accessing the DNS on the internal network) it may be of no importance when an external address changes. because i am not so familiar with views-configuring in named, as a workaround, i told the DHCPD to give me the external address for all DNS, so that i can get a hold of the external view of the DNS. And in the external view, the addresses are correct. suomi On 2011-06-30 08:38, Tim wrote: > 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. > -- 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
