Thank you for the video! I have a question regarding the ruleset link you created. According to Microsoft's documentation: "If you use the ruleset link option and there is a forwarding rule with the inbound endpoint as destination, do not link the forwarding ruleset to the Hub VNet. Linking this type of ruleset to the same VNet where the inbound endpoint is provisioned can result in a DNS resolution loop." Why did you direct your link to the Hub VNet instead of creating the link to the Spoke VNet, which might have been simpler?
I believe my thinking was that by linking it to the hub vNet instead of the spoke vNet, any additional spokes created would not need to have a link to them as well. At least as long as they point to the inbound endpoint for DNS. That way the setup scales better since you have less links. Even though that can lead to DNS resolution loops, that should be limited to queries originating from the onprem vNet and it can be avoided by having the DNS server there (10.0.0.5) always use itself as the primary DNS server. That being said, if in doubt you should follow the documentation. That way you will have an easier time if you ever need to create a support ticket for anything in the setup 😉
Curious if you've tried this with a VNet Gateway using P2S (OpenVPN using Entra for auth)? Does not work for me, I can see the query go out on a capture, but there's no response from the private resolver. If I set up a VM to forward requests to either Azure DNS or the private resolver, that works. Seems like Azure is blocking the response if it tries to go back out through the Gateway. I've had a ticket open for 125 days now and their support can't figure it out.
How are you handling DNS in your environments? Are you using private resolver? A vm in azure? Static records in DNS?
next question 🙂: do we need change on all vnets dns server to inbound address? include the inbound and outbound connected vnets?
Yes, all vnets would need to have DNS pointing to the inbound address. And a way of reaching it of course :)
@@PetterTech which dns server address should be on vnet for inbound?(private resolver)
Thank you for the video! I have a question regarding the ruleset link you created. According to Microsoft's documentation: "If you use the ruleset link option and there is a forwarding rule with the inbound endpoint as destination, do not link the forwarding ruleset to the Hub VNet. Linking this type of ruleset to the same VNet where the inbound endpoint is provisioned can result in a DNS resolution loop."
Why did you direct your link to the Hub VNet instead of creating the link to the Spoke VNet, which might have been simpler?
I believe my thinking was that by linking it to the hub vNet instead of the spoke vNet, any additional spokes created would not need to have a link to them as well. At least as long as they point to the inbound endpoint for DNS.
That way the setup scales better since you have less links. Even though that can lead to DNS resolution loops, that should be limited to queries originating from the onprem vNet and it can be avoided by having the DNS server there (10.0.0.5) always use itself as the primary DNS server.
That being said, if in doubt you should follow the documentation. That way you will have an easier time if you ever need to create a support ticket for anything in the setup 😉
Curious if you've tried this with a VNet Gateway using P2S (OpenVPN using Entra for auth)? Does not work for me, I can see the query go out on a capture, but there's no response from the private resolver. If I set up a VM to forward requests to either Azure DNS or the private resolver, that works. Seems like Azure is blocking the response if it tries to go back out through the Gateway. I've had a ticket open for 125 days now and their support can't figure it out.
I haven't tried it with P2S yet no. I'll have to add it to my list of things to try :)
You are a really good teacher. Dont stop!
Thank you 👍
Petter, this is really good content
Thank you! Really glad to hear that ❤️
thank, like your content! helps a lot
Glad to hear that!