Ive setup an incus cluster with 3 nodes and multiple projects. One of those projects holds a network for guacamole backend (guacd) . Ive been able to create network peers between tye guacd network and other various networks from different projects, and it works wonderfully !
The issue is that im using this infrastructure to manage a classroom setting , and sometimes i may need to rebuild a students container or i need a more easily way deploy to the guacamole database using ip’s.
I would love the ability to to be able to communicate between networks in different projects by dns names. So ive done my best to setup dns zones with a seperate bind9 server that sits outside of the incus cluster (but on the same lan subnet)
I have attached a photo below that details what im trying to do and how ive set it up currently with dns zones. But i still cant communicate via dns name resolution .
For the purposes of this example i have Project A and network A, which i then create a zone called proja.neta and then i do the same for project b network b (projb.netb)
Again pinging ip works, heck i can even ise dig from the bind9 server and call to the dns by <container_name>.proja.neta (or do the same for an instance that i know belongs to project B network b). But i cant call an instance in project B and network B if im doing it from Project A network A.
I know this is kinda confusing so i apologize for this. Ive been trying to do this on my own and i feel like im missing something obviously stupid haha
For me it does! Cross-Server, cross-project DNS, right?
It is interesting on both servers they share the same bind.
Are you sure you configured bind as resolver in /etc/resolv.conf as you say “heck i can even ise dig from the bind9 server” which means for me you can see them from wherever you dig them, right?
@jochumdev as long as i use dig from the dns server itself i can see them, but i cant do this from the containers … Also, this is NOT meant for teaching because im not sure if I even did this correctly , thats what im trying to find out.
let me run dig and ill post a pic. The weird part is that i get a return but i dont see the ip in the dig return (although it says success).
Aug 24 19:31:54 dell-1 named[1381455]: zone csc4212.bdebruhl.net/IN: refresh: unexpected rcode (NXDOMAIN) from primary 5.0.0.11#1053 (source 0.0.0.0#0)
Aug 24 19:31:54 dell-1 named[1381455]: zone csc4212.bdebruhl.net/IN: refresh: unexpected rcode (NXDOMAIN) from primary 5.0.0.12#1053 (source 0.0.0.0#0)
Aug 24 19:31:54 dell-1 named[1381455]: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
Aug 24 19:31:54 dell-1 named[1381455]: managed-keys-zone: Key 38696 for zone . is now trusted (acceptance timer complete)
Aug 24 19:32:41 dell-1 named[1381455]: zone csc4212.bdebruhl.net/IN: refresh: unexpected rcode (NXDOMAIN) from primary 5.0.0.10#1053 (source 0.0.0.0#0)
Aug 24 19:32:41 dell-1 named[1381455]: zone csc4212.bdebruhl.net/IN: refresh: unexpected rcode (NXDOMAIN) from primary 5.0.0.11#1053 (source 0.0.0.0#0)
Aug 24 19:32:41 dell-1 named[1381455]: zone csc4212.bdebruhl.net/IN: refresh: unexpected rcode (NXDOMAIN) from primary 5.0.0.12#1053 (source 0.0.0.0#0)
Aug 24 19:34:22 dell-1 named[1381455]: zone csc4212.bdebruhl.net/IN: refresh: unexpected rcode (NXDOMAIN) from primary 5.0.0.10#1053 (source 0.0.0.0#0)
Aug 24 19:34:22 dell-1 named[1381455]: zone csc4212.bdebruhl.net/IN: refresh: unexpected rcode (NXDOMAIN) from primary 5.0.0.11#1053 (source 0.0.0.0#0)
Aug 24 19:34:22 dell-1 named[1381455]: zone csc4212.bdebruhl.net/IN: refresh: unexpected rcode (NXDOMAIN) from primary 5.0.0.12#1053 (source 0.0.0.0#0)
so in theory i should be able to ping star-shiner.csc4212.bdebruhl.net from a network in a different project that has local peering with this network and also has the dns nameserver set as the bind9 node ip ? right?
I believe so, yes. I didn’t use network zones yet.
AXFR is for primary->secondary transport originaly, so incus is shadowed “master” server which needs to tell it’s “secondary” (bind in your case) how it’s records including the NS records.
I’m doing something similar, only I’m using Knot-DNS instead of Bind9 as my full-featured primary, and I’m doing that in an IPv6-only setup.
That said, your basic setup looks sane. Builtin DNS from Incus is acting as “hidden primary” on 5.0.0.100, and your Bind on 5.0.0.2 pulls both zones from whichever server currently has the Keepalived address.
One thing that looks a bit strange is that you point the `dns.nameservers` directly at Bind9. At least with Knot, the primary DNS server doesn’t really want to resolve anything outside its responsibility, would give a NXDOMAIN for e.g. `neta.` or `netb.` (unless you have zones configured in bind for `neta.` and `netb.`). This will break things when you e.g. use a recursive resolver in one of your instances. You may check which (if any) resolver is passed to your instances from Incus (on bridge networks, usually Dnsmasq, I’m not sure what Incus uses on OVN networks as I don’t have expeirence with those), and check further if that resolver is configured properly. And you might want to set up proper delegation from `neta` and `netb` so that client side recursive resolvers work as well.
Another problem is that the builtin DNS of Incus had a bug when querying the SOA record of the zone until recently (see Network zone DNS server returns duplicate SOA record in plain SOA query response, breaking secondary zone refresh · Issue #3665 · lxc/incus · GitHub ). Knot definitely does not like this behaviour and marks the Incus server as unavailable for automatic zone refresh - I’d guess that Bind9 does not like it either. Workaround is to force a fresh unconditional AXFR every couple of minutes on the Bind9 side, proper solution is of course to use a version of Incus where that bug is fixed.
One other thing: Did you add an NS record pointing at Bind9 in your Incus network zone setup? If not, that zone definition is incomplete, because at least one name server at the zone apex is mandatory.
