caching problems with bind 9.4.3

[Gil Vidals]

Hello,

I have a master and slave running bind 9.4.3, and there is a problem with the outside world resolving new domains that I add to my name servers. Here is the sequence:

1) add new domain
2) dig shows matching SOA and correct zone info.
3) wait two days
4) check a random name server such as openDNS and results are wrong - only about half of their name servers have the correct info.
5) restart named on my master and slave
6) re-check openDNS and voila! everything is good.

Is this a caching issue that requires restarting named daily? What changes in the config files can I make to solve this issue?

Gil Vidals, VCP
gvi...@vmracks.com
vmracks.com - ESX Hosting
t. 760.480.4942 f. 760.480.8271

[Warren Kumari]

You haven't provided very much detail (e.g: example domains, your nameservers, config files, versions, dig +trace output, etc), but from first glance it sounds like your secondaries are not updating until you restart named.

When you query a random nameserver there is a 50/50 chance (ok, well 100/N - where N is the number of auth servers) that they will hit your secondary which, it sounds like, doesn't know about the domain yet...

Can you retest and dig against all of your auth servers, making sure that they all return correct data?

W

_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

-- 

I had no shoes and wept.  Then I met a man who had no feet.  So I said, "Hey man, got any shoes you're not using?" 

[Doug Barton]

Gil Vidals wrote:
> Hello,
>
> I have a master and slave running bind 9.4.3,

You should upgrade to version 9.4.3-P3 which has fixes for some
security issues.

> and there is a problem
> with the outside world resolving new domains that I add to my name
> servers. Here is the sequence:
>
> 1) add new domain
> 2) dig shows matching SOA and correct zone info.

Are you updating and testing all of your name servers? You mention
"master and slave" in 5 below, so I assume you have at least 2.

> 3) wait two days
> 4) check a random name server such as openDNS and results are wrong -
> only about half of their name servers have the correct info.

As another poster mentioned, without specific examples it's really
hard to guide you further.
http://dougbarton.us/DNS/bind-users-FAQ.html#RealNames

> 5) restart named on my master and slave
> 6) re-check openDNS and voila! everything is good.

This is actually quite odd, since in theory opendns would be caching
the wrong answers and restarting your servers would not immediately
cause that information to be updated. We definitely need more specific
information to help you further.

Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

[big bond]

Don't you forget to update zone's serial number when adding new domain?

2009/11/20 Gil Vidals <gvi...@vmracks.com>

Hello,

I have a master and slave running bind 9.4.3, and there is a problem with the outside world resolving new domains that I add to my name servers. Here is the sequence:

1) add new domain
2) dig shows matching SOA and correct zone info.

3) wait two days
4) check a random name server such as openDNS and results are wrong - only about half of their name servers have the correct info.

5) restart named on my master and slave
6) re-check openDNS and voila! everything is good.

[Matus UHLAR - fantomas]

On 20.11.09 08:57, Gil Vidals wrote:
> I have a master and slave running bind 9.4.3, and there is a problem with
> the outside world resolving new domains that I add to my name servers. Here
> is the sequence:
>
> 1) add new domain
> 2) dig shows matching SOA and correct zone info.
> 3) wait two days
> 4) check a random name server such as openDNS and results are wrong - only
> about half of their name servers have the correct info.
> 5) restart named on my master and slave
> 6) re-check openDNS and voila! everything is good.
>
> Is this a caching issue that requires restarting named daily? What changes
> in the config files can I make to solve this issue?

I don't think that's a caching problem. From my experience this is most
often caused by mismatch between NS records in your zones and NS delegations
from parent zones.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
There's a long-standing bug relating to the x86 architecture that
allows you to install Windows. -- Matthew D. Fuller