Are you interested in our Early Access Program (EAP)? This program allows you to preview code, test in your lab and provide feedback prior to General Availability (GA) release of all Infoblox products. If so, please click the link here.

NIOS DNS DHCP IPAM

Reply

DNS security from Palo Alto

Techie
Posts: 6
922     2

Dears.

please answer please do not route me to infoblox PS support or partner support, 

 

i have two questions related to DNS security perspective 

 

  1. In my organization i have palo alto DNS security sunscription why i need to have infolox devices (Pls do not answer with  IPAM and DHCP features i totally agree they are making much difference pls focus of DNS part only).
  2. I have my DNS entries controlled by domain registrar why i need to take headache of managing and controlling security on my premises. 
  3. If i m buying DNS firewall license from infoblox what are the best that i can configure to use the device efficiently , Please route me to documentation.

Thannks

 

Re: DNS security from Palo Alto

Techie
Posts: 3
922     2

Let me respond to the last question first about how to deploy our DNS Firewall to maximum effect. Our deployment guides are on our public website here for you to reference: https://www.infoblox.com/resources/?resource_types=deployment-guide. We also have documentation for various Infoblox products, such as this one around the on-prem DNS Firewall solution, although some may be restricted to registered customers: https://docs.infoblox.com/display/BloxOneThreatDefense/On-Prem+DNS+Firewall+Service. Customers also have access to guidance from our system architects, support teams, and customer success teams to help optimize their deployment and use of Infoblox solutions.

 

Now, as to why someone might choose Infoblox over Palo Alto, it helps to first realize that there are several kinds of DNS security.  The first tier of DNS security are solutions that literally protect DNS systems from being attacked or compromised, which PAN does not offer.

 

The next tier of DNS Security use DNS information to block malicious connections.  SWG, Web Filters, and NGFW solutions started adding DNS data to their URL block lists around 10 years ago, so this is nothing new.  Palo Alto had done this for years, but broke this out into a separate feature for marketing purposes in 2019.

 

The top tier of DNS Security solutions add ML/AI capabilities to identify zero-day and other anomalous activity on the DNS level, but this requires years of experience to perfect.  For example, Infoblox ML/AI capabilities are built on 20+ years of DNS experience to dynamically detect data infiltration or exfiltration over DNS.  But PAN still depends on lists of known malicious sites for much of its data infiltration and exfiltration capabilities.  This is a limitation is imposed by the incomplete visibility PAN has of the DNS transaction, compared to Infoblox solutions which operate directly at the DNS layer.  Consider that even identifying the IP address of the requester requires PAN to use a sinkhole to trick the endpoint into bypassing the DNS server.  This is one reason that Palo Alto network and Infoblox actually have an integration between our solutions as complimentary.  Infoblox cannot inspect files in transit for malware, but PAN cannot do a lot of what Infoblox can do at the DNS layer.

 

I hope this helps.

Re: DNS security from Palo Alto

Authority
Posts: 29
923     2

I'm assuming by your questions that you are asking about outgoing DNS requests, since your public DNS inbound queries are handled by a third party. My response reflects that assumption.

 

We have BloxOne Threat Defense (cloud-based DNS firewall) and Palo firewalls and are evaluating leveraging Palo's DNS protection through Prisma. Our internal infrastructure sits behind Palo f/ws with DNS protection. Why? Neither one catches everything we want to block.

 

Your organization will have to determine whether the cost is worth it. Just realize that you're never fully protected with a single solution and we're only one zero day exploit away from a layered approach being penetrated.

Re: DNS security from Palo Alto

Techie
Posts: 6
923     2

Thanks for the reply

Sorry for late reply, 

Very good explanation, what abt query no 2 , y i shld bring purchase ADNS and bring DNS from Domain registrar to my on premises infoblox devices, what is the benefit of doing that rather a tech guy will say lets the headache be to the domain provider.

 

Please answer.

thanks.

Re: DNS security from Palo Alto

Techie
Posts: 6
923     2

Dears

 

Awaiting for the answer for question no 2

 

thanks

Re: DNS security from Palo Alto

Techie
Posts: 3
923     2

If I am understanding question #2 correctly, you do not need to have your own DNS resolver to do much of the type of DNS security discussed on this thread. To take advantage of BloxOne Threat Defense to block threat activity at the DNS level, you can simply direct DNS requests through the service and set up your policies in the cloud. You do not need to install anything on-premises.

 

With that said, there is a great deal of flexibility to how you can deploy and use Infoblox DNS security including options that do involve on-premises VMs or hardware. There are organizations and industries that prefer the level of direct control they get from having on-prem components. Or they may already be using other on-premise capabilities from Infoblox like IPAM or DHCP, which offer certain security benefits in addition to their core network functions. (Note that BloxOne DDI is offering increasingly more of these capabilities in the cloud as well.) But none of this is required as the DNS security solution is 100% cloud-native.

 

I hope this helps. But, if I am misunderstanding your question, please feel free to expand. Or you may be to a point where it may be more useful to have a live discussion with someone who can help you understand the options available for your specific situation.

Re: DNS security from Palo Alto

Authority
Posts: 29
923     2

You have two different scenarios:

1. Users inside your network wanting to resolve Internet names

2. Clients outside your network wanting to resolve your authoritative names

 

For traffic heading out of your network, you want to prevent users from getting to malicious sites and you want to prevent DNS based data exfiltration. (I mean, security-wise. You also want fast resolution, from an experience point of view.)

 

For traffic coming to you, as in the case of registered domains, you want to protect your network and devices from attack and provide 100% uptime with fast resolution globally (if you have a global 'audience').

 

To be honest, unless you have multiple data centers globally or are only in a regional market, it generally doesn't make sense to host your own public facing DNS. I think Infoblox is missing out on the opportunity to provide public DNS like registrars do, but I'm not privy to their internal discussions.

 

As an enterprise, we do have multiple data centers and it still makes sense for us to leverage another provider as secondary for our public domains. There are several reasons for that, one of which is having faster resolution in regions where we do not have a data center. AsiaPac is notorious for high latency and we have customers pretty much everywhere, so it helps improve their experience. It also gives us greater resiliency, as they have far more equipment deployed than we ever have planned.

 

If we did not already have/need the infrastructure to support the load we see with our public DNS (~800 domains), I would not have recommended that we provide public facing DNS using on-prem Infoblox. 

 

So, what do we gain by having DNS on-prem? Primarily control. We have a single interface for our operations teams, which is huge when you have a large organization with enough turnover to make complex designs burdensome to train. 

 

Some of the specific things we gain by not using our registrar or other 3rd party provider (individual items might be available, but not in totality):

  • Ability to control authorization mechanisms
  • Integration with existing role based authentication solutions
  • Single sign-on (SSO) 
  • Management limited to internal network (0% chance of someone outside the organization socially engineering access)
  • Granular access control to zones and records
  • anycast addressing
  • Shared records (creating a single record that's applied to multiple zones)
  • DNS association with public IPs (host records)
  • Dynamic update ability
  • DNSSEC
  • Record scavenging
  • Extensible Attributes (metadata)
Showing results for 
Search instead for 
Did you mean: 

Recommended for You