Up to now, I've thought of 2 possible solutions: Of course Dom0 or a NetManagementVM (thanks to the new Admin API) has to store the DNS settings for the VMs with Networking and the easy way is to store only the infos about VMs that don't use the standars DNS (10.139.1.1 and 10.139.1.2). So, adjustments have to be made to let the user specify a dnsVM in 'VM Settings', when Networking in not '(none)' and a default 'DNS Backend' field (new field in the GUI Qubes Global Settings) where the default value '(none)' or 'sys-net' corresponds to '10.139.1.1' and '10.139.1.2'.
Method a) 1) Every time a vif+ interface goes up in the FirewallVM (or the NetVM backend), this would have to run `qubes-setup-dnat-to-ns` like VMs that provide network do, but this time the script will retrieve the DNS through a rpc service instead of '/etc/resolv.conf'. 2) The rpc service will ask Dom0 (or the NetManagementVM) to update the net configurations, so Dom0 will retrive the list of current running VMs attached to the FirewallVM (or the NetVM backend) and provide it a list of VMs that don't use the default configurations and their the custom DNS backend IPs. 3) The FirewallVM (or the NetVM backend) will than update the iptables with secific DNAT of packets destinated to port 53 to specific IPs thanks to the infos received from Dom0 and maintain the general rule that DNAT all packets destinated to port 53 of '10.139.1.1' and '10.139.1.2' to the DNS specified in '/etc/resolv.conf'. Method b) Every time a qube is started from Dom0, Dom0 launch a rpc-service in its NetVM and passes to it any custom DNS configuration, if present, and the rpc service again, is the one responsible for executing a modified `qubes-setup-dnat-to-ns` to update the iptables. So, the current 'sys-firewall' NAT table looks like this: -N PR-QBS -N PR-QBS-SERVICES -A PREROUTING -j PR-QBS -A PREROUTING -j PR-QBS-SERVICES -A POSTROUTING -o vif+ -j ACCEPT -A POSTROUTING -o lo -j ACCEPT -A POSTROUTING -j MASQUERADE -A PR-QBS -d 10.139.1.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination 10.139.1.1 -A PR-QBS -d 10.139.1.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 10.139.1.1 -A PR-QBS -d 10.139.1.2/32 -p udp -m udp --dport 53 -j DNAT --to-destination 10.139.1.2 -A PR-QBS -d 10.139.1.2/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 10.139.1.2 And, the new 'sys-firewall' NAT table will look like this (with both methods): -N PR-QBS -N PR-QBS-SERVICES -A PREROUTING -j PR-QBS -A PREROUTING -j PR-QBS-SERVICES -A POSTROUTING -o vif+ -j ACCEPT -A POSTROUTING -o lo -j ACCEPT -A POSTROUTING -j MASQUERADE -A PR-QBS -i vifX -d 10.139.1.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination <dnsVM-X-IP> -A PR-QBS -i vifX -d 10.139.1.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination <dnsVM-X-IP> -A PR-QBS -i vifX -d 10.139.1.2/32 -p udp -m udp --dport 53 -j DNAT --to-destination <dnsVM-X-IP> -A PR-QBS -i vifX -d 10.139.1.2/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination <dnsVM-X-IP> -A PR-QBS -i vifY -d 10.139.1.1/32 -p udp -m udp --dport 5353 -j DNAT --to-destination <dnsVM-Y-IP> -A PR-QBS -i vifY -d 10.139.1.1/32 -p tcp -m tcp --dport 5353 -j DNAT --to-destination <dnsVM-Y-IP> -A PR-QBS -i vifY -d 10.139.1.2/32 -p udp -m udp --dport 5354 -j DNAT --to-destination <dnsVM-Y-IP> -A PR-QBS -i vifY -d 10.139.1.2/32 -p tcp -m tcp --dport 5354 -j DNAT --to-destination <dnsVM-Y-IP> ... # Defaults -A PR-QBS -d 10.139.1.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination 10.139.1.1 -A PR-QBS -d 10.139.1.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 10.139.1.1 -A PR-QBS -d 10.139.1.2/32 -p udp -m udp --dport 53 -j DNAT --to-destination 10.139.1.2 -A PR-QBS -d 10.139.1.2/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 10.139.1.2 It seems to me that the first solution is more elegant and flexible, since it allows the FirewallVM to query other machines than Dom0 for networking configurations. That is the case described also in the Docs where, thanks to the new Admin API, a new ManagmmentVM can install a custom Template and manage all the AppVMs that use that Template and their settings. ISSUES: 1) I haven't discovered yet, how retrive the vif backend interface name of a specific VM from Dom0 (querying the Xen DB I think), in order to pass to the FirewallVM (or the NetVM backend) the infos in this format: <vif_name> <DNS1> [<DNS2> ... <DNSX>]. Now, for testing purposed one could use the format: <VM_IP> <DNS1> [<DNS2> ... <DNSX>] and the iptables rules: `sudo iptables -t nat -A PR-QBS -s <VMX_IP> -d 10.139.1.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination <dnsVM-X-IP>` 2) I don't know if I can use udev rules to or Fedora/Debian cutoms system launch a script that interact with Dom0 and launch `qubes-setup-dnat-to-ns`. I've found the file '/etc/udev/rules.d/99-qubes-network.rules' wich cointains the following line: SUBSYSTEMS=="xen", KERNEL=="eth*", ACTION=="add", ENV{ID_NET_DRIVER}=="vif", RUN+="/usr/lib/qubes/setup-ip" , but it doesn't seem to do anything (I've tried to remove it, restart udev and start a VMs, but the connection works fine). I really need some help, maybe from the developers, to understand better these mechanisms, to be able to implement a solution as more general as possible, that users can adopt without efforts. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fab68ebf-f08c-42d9-a497-b80dc904666d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.