named shows different results

fedora fedora at ayni.com
Thu Jun 30 19:23:11 UTC 2011


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


More information about the users mailing list