Wow.
1) You're using BIND as a caching nameserver.
So you say. Does the nameserver do its own upstream (authoritative)
lookups? If yes, then the term of art is "recursive / caching"; otherwise
the term is "forwarding".
Looks like you're configuring your ISP's nameservers as forwarders.
Therefore the proper term is "forwarding".
2) Your ISP's nameservers fail to resolve $FQDN.
These are other people's caching nameservers.
3) Google's nameservers resolve $FQDN.
These are other people's caching nameservers.
4) Looks like the nameservers for healthservice.ie belong to
topsectechnology.net.
5) Looks like those nameservers resolve $FQDN.
At least that's what dig +trace tells me.
Can't you do the auth lookups directly? Have you tried?
So your logic in coming here is that:
a) $A's caching nameservers don't resolve $FQDN.
b) $B's caching nameservers do resolve $FQDN.
c) You use BIND to connect to one of those entities' caching nameservers
instead of running your own.
d) Therefore, the BIND mailing list is were I should direct my ire.
Did I miss anything?
Any response you get here is going to involve changing your BIND server's
configuration and behavior, probably to convert it from forwarding to
caching... although grizzled veterans may tell you horror stories about
hotels and other public wifi.
--
Fred Morris
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
