Thank you for prompt support really appreciate.
my /etc/named.conf, see recursion are enabled. still I can resolve the
yahoo.com or any outside domains.
=
> set debug
> yahoo.com
Server: 212.119.64.228
Address:212.119.64.228#53
Ah so this is to do with recursion.
Check the settings on the 212.119.64.228 server to ensure that
recursion is turned on and allowed for the clients that need to be
able to resolve domains that the server is not authoritative for.
You'll also have to make sure that 212.119.64.228 has unrestricted
Thanks you for you answer. as requested see the difference
I am successfully resolving the local domains without any problem. below is
output for your info...
=
Except queries from 96.31.0.5 and 199.120.69.24 reliably return the
while queries from 96.31.0.20 do not. And we're all the same ISP, and in
the one case, from the same /24. I don't think Google is that granular. And
we do have good IPv6 connectivity.
Regards,
Frank Bulk
-Original Mes
On 2014/12/23 21:33, Frank Bulk wrote:
> So the question seems to come down to: "why does Google's name server not
> return the when I query it from some IPs?"
Didn't google have some kind of ISP whitelisting for handing out s?
Ah yes... https://developers.google.com/speed/public-dns/faq
On 24 December 2014 at 13:42, Mohammed Ejaz wrote:
> Any clue would be highly appreciated. thanks in advance.
What's the name of the zone so we can test from here?
Did you update the parent zone to tell it the nameserver IP for your
zone has changed?
If you explicitely try to query to the new
hello,
I cannot resolve the external domain when I change my name server IP.I
am sure for the new IP (which I am replacing with existing IP) the port 53
udp and TCP is enabled for publically.
also modifying in the named.conf in the listening section such as "
listen-on port 53
7 matches
Mail list logo
