Need help planning DNS resolution

[McKITGuys]

Hi all,

Taking over a Veeam setup and would like to rebuild their setup as the VBR servers are domain joined; as well, have had on and off licensing issues not resolvable to date (even with support help - i.e. everything works fine for a while and then licensing goes wonky and I have to assign the available sockets to the right hosts).

I need help getting mind around how DNS resolution would work since I will rebuild the VBR servers to be non-domain joined.

Setup:
- 2 VBR servers, 2 sites
- vmware servers in 2 sites (3 hosts)
- both VBR servers also act as repositories with direct storage and also act as WAN accelerators and proxies for their site
- backups all driven by one site (main office) to storage in each site and then copy jobs to copy data the the "other" site

- if I remove the current VBR servers from the domain, they can no longer find other VBR components (or the other VBR server in the other site etc.)
- had a situation where I thought I was going to have to first restore a domain controller so having DNS resolution being tied to a AD integrated DNS not great
- others have suggested a host file (but maybe only in an emergency as hard to maintain)

1) how to others do DNS resolution for non-domain VBR servers and components? do people have another dns setup that they have running on another server?
2) or can you name the component pieces with a workgroup name such that it gets resolved via some other resolution process?
e.g. VBR1.VeeamWorkgroup
if using "VeeamWorkgroup" as my workgroup name

I won't ask anything more - maybe there is a quick answer to all this from those who have gone before.

[EugeneK]

Greetings!

It really comes down to two options, both are described at Veeam Best Practices:
1) Having a reliable DNS service
2) Manipulating the entries of the hosts file

The domain controller, while backup infrastructure being not joined to AD, is one of the methods to establish availability of the DNS services - the key factor here is to have N+1 configuration, where there're at least two domain controllers deployed, improving the availability of auth/DNS etc services for the entire fleet of workloads using it. It also helps to place these domain controllers in different sites, which may help with the recovery strategy down the road.

If you choose to proceed with the hosts file approach, it's rather a manual or scripted process to maintain its accuracy. However, some use it intentionally to alter the data transfer path between the components if the non-default network retrieved based on the DNS records needs or preferred to be used to communicate between the components for the optimal network utilization.

[mweissen13]

What has been working really well for us is running DNS directly on the Veeam Server. And adding a conditional Forwarder to the local domain controller. Of course it depends on your setup if that makes sense or works as expected.

[McKITGuys]

Well, that is a good idea. Had not thought of adding DNS to the Veeam server. Any reco on a lightweight 3rd party dns service (Windows based) that seems rock solid. And for the one(s) you have used, do they replicate dns entries between other Veeam servers at other sites?

[McKITGuys]

And adding a conditional Forwarder to the local domain controller.

Continuing on with this, if another DNS service was running on the VBR server, what needs to be in it for records - just the other VBR server and proxy? Do the hostnames for any of the VM servers that are within our VM hosts need to be loaded into it? Or does Veeam find those through the fact that it is linked to the VMware hosts?

[vmtech123]

I like using a Hosts file on my Veeam server, proxies, repos etc.
Also include the file servers, VMware hosts, vcenters etc.

When your domain goes down, and your DC's go down, if they are hosting the DNS you are in a rough spot (Had this happen)

You need the Veeam server to talk to each other, the hosts, and everything else to restore the DNS>

[RubinCompServ]

In addition to using the Hosts file, I do almost as much as I can with IP addresses rather than FQDN, specifically to avoid any type of DNS issues.

[McKITGuys]

Ok. All good comments. The setup has a mix of IP addresses now and host names (from previous techie who set up). I can see the rationale for both. If I went with host names, does anyone know if I put the VBR servers into a workgroup (e.g. "MyVeeamWkGrp"), do I need to full qualify each of the Veeam "components" as I create them in the console. e.g. a proxy would be named "Site1Repo.MyVeeamWkGrp" or if my NIC is pointing to my workgroup dns, will it append the workgroup name? Or if not actually needed, is it best practice to always append it manually? Or conversely, maybe it is best practice to NOT manually append the workgroup (for whatever reason).

Thanks again all.

[mweissen13]

Continuing on with this, if another DNS service was running on the VBR server, what needs to be in it for records - just the other VBR server and proxy? Do the hostnames for any of the VM servers that are within our VM hosts need to be loaded into it? Or does Veeam find those through the fact that it is linked to the VMware hosts?

Basically, you should include anything that is relevant/essential to the Backup Process, depending on your setup:
- Repository Server(s)
- vCenter Server(s)
- ESX Server(s)
- Hyper-V Server(s)

This applies both to a local hosts file or to a locally installed DNS server.

[mweissen13]

In addition to using the Hosts file, I do almost as much as I can with IP addresses rather than FQDN, specifically to avoid any type of DNS issues.

This can work well, but it will bite you in the ass if you ever need to renumber IP addresses or (change local subnets).

[YouGotServered]

When I disjoin my Veeam components, I add the DNS suffix domain into the NIC properties of the Veeam components and point DNS to the domain controllers. This way, everything works as planned. You may need to statically add some DNS records to your DC for your Veeam components, but that's easy.

**Note that if you have an infrastructure failure, DCs included, you will need to have editing the host files of your Veeam components so that they can talk to each other as part of your DR plan (or potentially having a secondary pre-loaded DNS server on a firewall / switch / etc).