In practical senses, I rarely see this being handled by the company infrastructure and instead what happens is the company signs up for WAN to a provider which will make access between sites transparent and absolutely guarantee that the companies traffic is not co-mingled in any way that other customers of that provider can hack into the traffic.
If you don't have that service and need to roll your own, or perhaps you don't fully trust the service, a site-to-site VPN encrypted with AES256 would be generally considered a good practice. The network router might have the ability to do this, and would be considered a good practice -- especially if those features are built into the network gear of a good name brand.
Another option would be firewalls on each site which establish the site-to-site vpn. Whether that is "better" than using IPSec features in the routers is a big "it depends".
From a cost perspective, less boxes costs less, sucks less power, throws off less heat, and takes up less rack space. From a security operations perspective more boxes means more things to worry about being mis-configured and introducing security holes, or less boxes to make sure are patched regularly, less boxes means smaller attack surface.
Not sure why you would opt to put the server on the public Internet in a DMZ if the only access comes from within the company from site A or B. Putting it in a DMZ on the public Internet would make it susceptible to security bugs in your DMZ firewall, configuration errors (which either are there from day one or get introduced through changes), etc.
DMZ's are meant to be places where you put servers that absolutely have to be exposed to the public Internet and there is no alternative. If there is an alternative, the alternative is always going to be the better route. There is nothing in the question that justifies taking this risk.