SureBackup custom routing rules?

I would not modify the SureBackup proxy appliance to add custom routing/NAT for this.

The virtual lab is intentionally isolated. For this scenario, I would provide DNS inside the virtual lab instead (isolated). 

Older but worth a visit. 

https://forums.veeam.com/viewtopic.php?f=2&t=8782&start=0

&

https://helpcenter.veeam.com/docs/vbr/userguide/surebackup_ip_mapping.html?ver=13

I agree with Eric here having your DNS inside the lab is the ideal solution.  Exposing something that is supposed to be isolated is not a best practice.  Best of luck with testing.

There isn't really a supported way to have the SureBackup proxy appliance forward DNS requests back into production, and to be honest I wouldn't recommend it even as a workaround.

What I've typically seen done is restoring a copy of the DNS server into the lab itself. If it's a physical server, Veeam supports protecting it with Veeam Agent, so that's usually the cleanest option.

The proxy appliance is really designed as a one-way gateway. Its purpose is to allow systems in production to communicate with VMs running inside the virtual lab. Features such as masquerade IPs and static IP mapping follow that same model. The only outbound capability available is the "Allow proxy appliance to act as an internet proxy" option, which is limited to HTTP and HTTPS traffic. DNS, ICMP and other protocols aren't forwarded outside the lab. There are also no supported options for adding custom routing or NAT rules.

You could technically SSH into the appliance and add iptables rules, but that would be unsupported and would likely need to be recreated whenever the lab is modified or redeployed.

From a DNS perspective, the lookups themselves aren't really the concern. The bigger issue is what happens in the opposite direction. Restored Windows servers will normally attempt to register A and PTR records, DHCP servers may perform DNS registrations, and a restored domain controller will re-register its SRV records. If those updates reach your production DNS environment, you can end up with stale or unexpected records being created or overwritten.

The risk increases if the DNS server is also a domain controller, which is common in Active Directory environments. At that point you start opening a path for Kerberos, secure-channel and replication traffic between the isolated lab and production. That defeats the isolation SureBackup is designed to provide and can lead to some very strange behaviour.

If someone did want to go down that path, I'd strongly recommend restricting communication to TCP/UDP 53 on the DNS server only, but even then dynamic DNS updates still use port 53 so I'd be cautious.

My preferred approach would be to back up the physical DNS server using Veeam Agent and include it in the SureBackup application group. SureBackup supports recovery verification of Windows and Linux Agent backups, allowing the machine to be started inside the isolated lab as a VM.

If the server only provides DNS, assign it the DNS Server role in the application group so it starts before the other machines. If it's also a domain controller, use the Domain Controller role instead. That way the rest of the lab environment can resolve names locally without needing any dependency on production services.

A few things to keep in mind:

• Agent-based machines are connected to the first isolated network configured in the virtual lab, so make sure that network aligns with the DNS server's production subnet.
• The backup must be an entire machine or volume-level backup. File-level backups aren't supported for SureBackup verification.
• Windows system and boot partitions need to reside on the same disk.
• Failover clusters aren't supported.
• On vSphere, there are some limitations around 4K-sector disks, Storage Spaces and systems with a very large number of drives.
• Backup Copy Jobs, Cloud Connect repositories and archive tier backups can't be used as the source for Agent verification.

If installing Veeam Agent isn't an option, the next best approach is usually to deploy a small VM that hosts a secondary copy of the required DNS zones. Back that VM up, add it to the application group and assign it the same IP address as the production DNS server within the isolated lab. That allows everything to work normally without requiring any network access back into production.

Either option keeps the SureBackup environment fully isolated and avoids unsupported modifications to the proxy appliance. As a bonus, the Agent approach also validates that your DNS server backup can actually be restored successfully.