- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
08-11-2024 02:56 PM
I haven't seen this anywhere in other posts or documents, so I wanted to share this as it's something I ran into recently.
TL;DR: When setting up internal domains for Prisma DNS to resolve with your internal DNS servers, you have to also add the domain for the reverse lookup zone for any servers that may be using Kerberos authentication. Alternatively you can disable the reverse lookup component of Kerberos authentication but adding the reverse lookup zone is likely to be easier to implement. I don't know enough to say whether disabling the reverse lookup component is not advised from a security perspective.
We were previously sending all DNS queries through the service connections to our internal DNS servers, though doing that user connectivity would be completely impacted in the event that service connections go down/during failover between tunnels. Most of the time this has not been an issue, but there have been a few times during planned maintenance where we had impacted our data center's internet connections and by extension the service connection tunnels. During the failover period we weren't even able to communicate via Teams, and with much of our typical business workflow operating out of Teams and Outlook (also hosted in 365) we decided that we wanted to transition to only resolving internal domains via the service connections and let Prisma DNS resolve the external domains. This way if we had a failover of the service connection tunnels, at least the only thing impacted would be access to our data centers as opposed to everything due to DNS not resolving.
I made the change on a Saturday evening and added any forward lookup zones in our internal DNS to the internal domains list for Prisma and set it to Prisma's DNS for anything external. I spot checked a few domains and everything seemed to be working well so I called it good. Come Monday though, we were running into some weird Kerberos errors with one of our applications that is accessed over a vendor's VPN they bring into our data center. Apparently Kerberos does some DNS things when authenticating and one of those things is a reverse lookup. I wasn't sure it would work but I added the reverse lookup zone for the network the server we were having issues with was in and it resolved the Kerberos authentication issues.
I think there should be a caveat of some sort added to the DNS for Prisma Access document, is there a formal process for requesting that? I know feature requests usually go through your SE, should I send this to them as well? Or is this post sufficient?
08-12-2024 08:01 PM
@cmorris8990 wrote:
I haven't seen this anywhere in other posts or documents, so I wanted to share this as it's something I ran into recently.
TL;DR: When setting up internal domains for Prisma DNS to resolve with your internal DNS servers, you have to also add the domain for the reverse lookup zone for any servers that may be using Kerberos authentication. Alternatively you can disable the reverse lookup component of Kerberos authentication but adding the reverse lookup zone is likely to be easier to implement. I don't know enough to say whether disabling the reverse lookup component is not advised from a security perspective.
We were previously sending all DNS queries through the service connections to our internal DNS servers, though doing that user connectivity would be completely impacted in the event that service connections go down/during failover between tunnels. Most of the time this has not been an issue, but there have been a few times during planned maintenance where we had impacted our data center's internet connections and by extension the service connection tunnels. During the failover period we weren't even able to communicate via Teams, and with much of our typical business workflow operating out of Teams and Outlook (also hosted in 365) we decided that we wanted to transition to only resolving internal domains via the service connections and let Prisma DNS resolve the external domains. This way if we had a failover of the service connection tunnels, at least the only thing impacted would be access to our data centers as opposed to everything due to DNS not resolving.
I made the change on a Saturday evening and added any forward lookup zones in our internal DNS to the internal domains list for Prisma and set it to Prisma's DNS for anything external. I spot checked a few domains and everything seemed to be working well so I called it good. Come Monday though, we were running into some weird Kerberos errors with one of our applications that is accessed over a vendor's VPN they bring into our data center. Apparently Kerberos does some DNS things when authenticating and one of those things is a reverse lookup. I wasn't sure it would work but I added the reverse lookup zone for the network the server we were having issues with was in and it resolved the Kerberos authentication issues.
I think there should be a caveat of some sort added to the DNS for Prisma Access document, is there a formal process for requesting that? I know feature requests usually go through your SE, should I send this to them as well? Or is this post sufficient?
@cmorris8990 , thank you very much for sharing this with us. This is very informative. Yeah, I would recommend to bring this up with your SE so it can catch the product team attention once he share this with them and you can easily track this with the SE.
08-12-2024 08:01 PM
@cmorris8990 wrote:
I haven't seen this anywhere in other posts or documents, so I wanted to share this as it's something I ran into recently.
TL;DR: When setting up internal domains for Prisma DNS to resolve with your internal DNS servers, you have to also add the domain for the reverse lookup zone for any servers that may be using Kerberos authentication. Alternatively you can disable the reverse lookup component of Kerberos authentication but adding the reverse lookup zone is likely to be easier to implement. I don't know enough to say whether disabling the reverse lookup component is not advised from a security perspective.
We were previously sending all DNS queries through the service connections to our internal DNS servers, though doing that user connectivity would be completely impacted in the event that service connections go down/during failover between tunnels. Most of the time this has not been an issue, but there have been a few times during planned maintenance where we had impacted our data center's internet connections and by extension the service connection tunnels. During the failover period we weren't even able to communicate via Teams, and with much of our typical business workflow operating out of Teams and Outlook (also hosted in 365) we decided that we wanted to transition to only resolving internal domains via the service connections and let Prisma DNS resolve the external domains. This way if we had a failover of the service connection tunnels, at least the only thing impacted would be access to our data centers as opposed to everything due to DNS not resolving.
I made the change on a Saturday evening and added any forward lookup zones in our internal DNS to the internal domains list for Prisma and set it to Prisma's DNS for anything external. I spot checked a few domains and everything seemed to be working well so I called it good. Come Monday though, we were running into some weird Kerberos errors with one of our applications that is accessed over a vendor's VPN they bring into our data center. Apparently Kerberos does some DNS things when authenticating and one of those things is a reverse lookup. I wasn't sure it would work but I added the reverse lookup zone for the network the server we were having issues with was in and it resolved the Kerberos authentication issues.
I think there should be a caveat of some sort added to the DNS for Prisma Access document, is there a formal process for requesting that? I know feature requests usually go through your SE, should I send this to them as well? Or is this post sufficient?
@cmorris8990 , thank you very much for sharing this with us. This is very informative. Yeah, I would recommend to bring this up with your SE so it can catch the product team attention once he share this with them and you can easily track this with the SE.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!