On 5/24/19 12:21 PM, Andrija Panic wrote:
In other words - you are hitting an internal interface of a VR?
The VR has two NIC's. I presume that the Guest NIC as vs the Control NIC
is the "internal" NIC?
TypeShared
Traffic TypeGuest
Network NameShared
Netmask 255.255.0.0
In other words - you are hitting an internal interface of a VR?
I would replace (for a test) bind9 with just the default setup of DNSmasq,
while specifying it's uper/ROOT DNS servers to be the VR IP - i.e. client
--> DNSmasq (internal server) --> DNSmasq (VR).
See if that work - so you can draw
On 5/24/19 10:16 AM, Andrija Panic wrote:
Eric,
your BIND9 servers is on a "Public" network (trying to talk to the Public
IP of the VR during forwarding DNS requests) or a VM inside an Isolated
network behind VR)?
It's on *a* public network, but not *the* public network. I don't have
any
Eric,
your BIND9 servers is on a "Public" network (trying to talk to the Public
IP of the VR during forwarding DNS requests) or a VM inside an Isolated
network behind VR)?
Andrija
On Fri, 24 May 2019 at 02:15, Eric Lee Green
wrote:
> I had this working under 4.9. All I did was, on my main
I had this working under 4.9. All I did was, on my main BIND9 servers,
point a forward zone at 'cloud..com' to the virtual router
associated with all VM's that were publicly available. I could then
resolve all foo.cloud..com names on my global network.
Somehow, though, this quit working after
