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 Isolated networks, though I have them enabled from VLAN 1000-2000. I
am using "Advanced Networking" but for my own purposes -- I have one
"Shared" guest network at VLAN 102, and then several isolated specialty
physical "Shared" networks like "Security Cameras" (VLAN 103) and
"Storage Network" (VLAN 200) that are attached to virtual machines that
need access to those things. The "Shared" guest network (VLAN 102) is
routed by my layer 3 switch with the rest of my network's public VLANs
so if I am on e.g. 10.31.1.2 (VLAN 31), which is similarly a routed
public VLAN (but not one that Cloudstack is allowed to directly talk to
or manage, it has to go thru the layer 3 switch) or 10.120.0.5 (VLAN
120), I can talk directly to 10.102.199.148 since all are routed into
the common fabric via the layer 3 switch. I only care about the VM's
that are VLAN 102, which are supposed to be publicly available to my
users, thus why my quicky script hack to generate a zone file out of the
database does
select v.name, n.ip4_address from vm_instance as v, nics as n where v.removed
is null and n.instance_id = v.id and n.ip4_address like '10.102.%' and type =
'User' order by n.ip4_address;
in order to select out the name and IP address of virtual machines with
NIC's on that VLAN. (Which, if it's a different list from the last list
that was queried, then gets massaged into a zone file for
name.cloud.mydomain.com by the script, which then scp's to my master
domain server and does a reload to reload the zone file from the new
version).
Both of my BIND9 servers can talk directly to 10.102.199.148 (the IP of
the virtual router for the 10.102.xxx.xxx network, VLAN 102) if I use
'host' to directly query 10.102.199.148 for an API address like, say,
'api-default1.cloud.mydomain.com' but when I try to put a forward domain
there, nope. This was working, but now is not. I suspect it's got to do
with the recent changes in DNS software, both bind9 and dnsmasq, to
deal with multiple attacks on the domain name system, but I'm having
trouble figuring out why, or what my solution should be.
Note that it's quite reasonable / feasible / viable to put a DNS server
actually inside the Cloudstack constellation if that's necessary and
then do a two-stage hop if necessary. I'm just trying to figure out the
"right" way to do this right now so I can retire my hack script.
On Fri, 24 May 2019 at 02:15, Eric Lee Green <eric.lee.gr...@gmail.com>
wrote:
I had this working under 4.9. All I did was, on my main BIND9 servers,
point a forward zone at 'cloud.<mydomain>.com' to the virtual router
associated with all VM's that were publicly available. I could then
resolve all foo.cloud.<mydomain>.com names on my global network.
Somehow, though, this quit working after I updated to 4.11. I'm not
quite sure why.
The 'Guest Network' is defined with domain 'cloud.mydomain.com'.
Okay, so my router for the 'Guest Network' advanced networking is
located at 10.102.199.148. In my master BIND9 DNS server at 10.31.1.2 I
have this:
zone "cloud.mydomain.com" IN {
type forward;
forward only;
forwarders {
10.102.199.148;
};
};
If I send a NAMED request directly to the virtual router while logged
into my main name server, it works:
[root@ypbind ~]# host eric-gui.cloud.mydomain.com 10.102.199.148
Using domain server:
Name: 10.102.199.148
Address: 10.102.199.148#53
Aliases:
eric-gui.cloud.mydomain.com has address 10.102.199.234
If I try to use the name server however, it doesn't work:
[root@ypbind logs]# host eric-gui.cloud.mydomain.com
Host eric-gui.cloud.viakoo.com not found: 3(NXDOMAIN)
I'm baffled, because this *was* working.
So I disabled any dnssec in the {options} on bind9 and gave all
permissions to see if that was the problem (note that this is internal
to my infrastructure, so DNS amplification isn't an issue):
dnssec-enable no;
dnssec-validation no;
dnssec-lookaside auto;
recursion yes;
allow-recursion { any; };
allow-query { any; };
allow-query-cache { any; };user
Still nope. Still baffled.
Anybody got any clues as to what I may be doing wrong? I'm thinking it
has to be on the BIND9 side, because I can resolve the host name if I
talk to the virtual router directly, but for some reason it's not
allowing me to get any records from the router.
Right now I've temporarily worked around this with a script that
directly queries the MySQL database every few minutes and generates a
revised zone file on my master DNS server when the list of virtual
machines queried out of the database changes, but that's clearly not the
right way to do it. The question is, what *is* the right way to do it?
-Eric
