0

---EDITED TO REFLECT THE FACT I'M RUNNING MULTIPE COPIES OF THE APLCIATION ON THE ONE DOMAIN----

Having an issue that I can't quite work out, wondered if some fine person here had any experience!

I'm running multiple web based .NET applications on a Azure VM (Windows Server 2019) on various sub-domains of a single domain. lets say app.clientdomain.com, app-test.clientdomain.com, app-dev.clientdomain.com. I don't control the public DNS for this domain as the client owns the domain (they have a CNAME record in place that points app.clientdomain.com at the FQDN of the Azure Application gateway that sits in front of the VM).

The application requires a local DNS loopback for certain things to work correctly, and I've used an Azure Private DNS zone with clientdomain.com as the main domain, and an A records for app.clientdomain.com, app-test.clientdomain.com and app-dev.clientdomain.com all pointed to the Private IP address of the VM. This works quite nicely for the local DNS loopback.

I now also need to be able to access an FTP server on the same domain, say ftp.clientdomain.com. The particular sFTP server in question is external to my Azure subscription and not controlled by me.

However the issue I have is that the DNS resolves fine for ftp.clientdomain.com in the outside world, but wont resolve from within the VNet (NSLookup reports 'Non-existent domain').

I ideally don't want to put an A record for ftp.clientdomain.com in my private zone, as the IP address may be changed by the client without notice, which would break my applications ability to reach the sFTP server.

Am I unreasonable to expect that if a matching DNS record is not found in the private zone that it should reach outside to public DNS? Am I doing something wrong, or is something broken?

Thanks in advance for any input!

Chris Butler
  • 146
  • 6

2 Answers2

1

You have created a private zone that matches a public zone. If a name does not resolve in the private zone, NXDOMAIN is returned. The DNS client or resolver will not try the public zone.

Solution: choose a different zone name for the private zone so that both private and public names can be resolved.

John Hanley
  • 4,287
  • 1
  • 9
  • 20
  • Thanks @John, Thanks, confirms for me that I've not misconfigured or done something fundamentally wrong. The problem I would have with this approach (and sorry I didn't detail this in my original question, I'll edit and update) is that I'm actually running more than one app on the VM. i.e. app.clientdomain.com, app-test.clientdomain.com, app-dev.clientdomain.com. With your solution I would have to have multiple Private DNS zones. While I'm not totally against this if that's what it comes down to it seems a bit painful! – Chris Butler Jun 03 '21 at 21:29
1

So what you could do is just create the Azure Private DNS Zone specifically for app.clientdomain.com. We had the exact same requirement - a public zone that also has records that exist internally. We overcame it with this setup.

The Private DNS Zone would be authoritative to that subdomain only and everything else will resolve outside. Just point the root record (of the subdomain, i.e. @ to the IP address as required). See example below, where I've set up in my environment. I just noticed the typo!

enter image description here

Ked Mardemootoo
  • 191
  • 7
  • Hi Ked, Thanks for your input, highly appreciated! As with @John's answer it confirms what I'm asking is not reasonable and I'm going to need to look at a different approach. While your answer is absolutely valid, there is some info I left out of my original question (edited and added just now) that complicates this somewhat; the fact that I'm running multiple copies of the App in the VM i.e. app, app-test, app-dev etc.... With your approach I would need a Private DNS zone for each copy of the app. Not sure if I like this solution any more/less than adding an A record for the FTP server. – Chris Butler Jun 03 '21 at 21:39
  • 1
    No worries, totally understand. Yes if that's the case, you would need multiple Private Zones and it wouldn't scale well. So I get your concern on not being keen to put the A record cause it might change but what about creating a new DNS zone for internal purposes with a CNAME pointing to the ftp of the client, there could be other considerations but might be a viable option. – Ked Mardemootoo Jun 04 '21 at 02:02
  • 1
    Two other options I thought I'd share. If you can standardise the app FQDNs to something like *.app.clientdomain.com it will make things much easier to manage. You would only need to create one Private DNS Zone - that's a setup that we have also. Another option, (just sharing but do not recommend) is to create a records with private IPs that need to be resolved internally. This will work 100% but your internal addressing scheme is exposed. I will update my answer with those two options in the event it helps others/for the sake of sharing. – Ked Mardemootoo Jun 05 '21 at 14:44