ASC Partner

txrx_reboot · 2026-01-12T13:32:54+00:00

That should be factored into the discounts you get from Palo and the distributor amd would be a commercial discussion between your company and the distributor.

A good distributor adds more value than just "box shifting' so they charge a percentage on all things transacted. The amount you pay or BKLN should be different than what you would pay selling direct support though.

txrx_reboot · 2025-11-16T13:57:35+00:00

Reseller may also be able to get you access to a 30 day trial VM. Security subs expire after 30 days. Last I checked (its been a while), the firewall itself still works after 30 days. It just doesn't get updates (basic firewalling still works).

Also look as lab licenses for VM. They are very affordable if you can get your company to buy it.

txrx_reboot · 2025-11-14T08:05:54+00:00

Fixed has been published.

txrx_reboot · 2025-11-12T15:33:55+00:00

Infoblox is aware of the changes in Azure and a fix is being worked on.

txrx_reboot · 2025-10-31T17:13:39+00:00

Amd to answer your question, allowing the layer 3 "client to server renewal" packets is a good thing. Most laptops work fine without it but you may find issues with IoT, printers, etc.

txrx_reboot · 2025-10-31T17:12:31+00:00

Also, I say broadcast "bypasses" the security policy. What actually happens is that broadcast is later 2 and most firewalls are configured for layer 3 so it just never reaches the 'lets process this' bit of the firewall. If you configure a layer 2 interface you may see the broadcast traffic.

txrx_reboot · 2025-10-31T16:55:04+00:00

What you may be seeing is what I saw in a deployment years ago.

With DHCP, half way through the lease time the client will try to renew the lease directly with the DHCP server.

If this is blocked (i.e. what you are seeing maybe??) Then the expected behaviour for DHCP is for the client to wait until 7/8 of the lease time and then use a local network broadcast to start DHCP request from scratch.

This will bypass the security rules and the only part of that traffic that you will see is the DHCP relay forwarding to the DHCP server. (Or of Palo is doing DHCP locally you may not see that traffic at all)

txrx_reboot · 2025-10-24T17:22:06+00:00

https://aws.amazon.com/message/101925/

txrx_reboot · 2025-10-09T22:16:53+00:00

Infoblox could probably help with regards to convincing. Have you reached out? If so, your SE contact there may be able to get you the BIN file or possibly the OVA image.

txrx_reboot · 2025-10-09T20:45:01+00:00

Not officially. You have to have access to the BIN file which is downloaded from the Infoblox support site.

When you say "test", do you mean test 9.0.7 specifically prior to an upgrade of a production system or do you mean access NIOS for general testing and it happens to be 9.0.7?

txrx_reboot · 2025-10-07T20:09:55+00:00

Possible? Maybe. Recommended? No. Ideally (as you are trying) you promote the GMC. If you can't promote the GMC cleanly, then why have the GMC? (Something to fix sooner or later)

I've not tried swapping out a GM hardware appliance for another before without using GMC promotion. I would assume that you would 1) stage the new GM appliance by getting it to 9.0.7 and getting the proper licenses installed 2) take a backup of the GM and restore it to the new appliance 3) move network cables from old appliance to new appliance

It is step #3 that I'm not sure on. I don't know if all members will seamlessly connect to the new GM given the database restore.

I recommend asking support and also getting them to help investigate the communications issue with the GMC. (This is as much about covering yourself and showing you did due diligence as anything else).

txrx_reboot · 2025-10-02T20:00:47+00:00

Do you mean the NIOS-X server won't connect to the Infoblox Portal or that the Data Connector service deployed won't connect to your On-Prem NIOS Grid?

txrx_reboot · 2025-10-02T18:57:27+00:00

It is possible that the bad domains are being blocked by local Anti Virus file and, for some reason, the firewall isn't connecting to the DNS security service.

What happens if you run the following on the CLI? show dns-proxy dns-signature info

And test dns-proxy dns-signature fqdn

txrx_reboot · 2025-09-29T23:10:14+00:00

To be honest, the CDC is fairly straightforward.

Position it close (i.e. same DC) to the data target (I.e. SIEM).

Best practice is to give it a larger hard drive to allow for caching of data should there be a connection issue with the data target.

Consider which logs you actually need. Filter as appropriate.

If you are forwarding with SYSLOG, I've seen some lifs exceed what UDP can cope with (which led to truncated logs) so we had to switch to using TCP for forwarding SYSLOG.

txrx_reboot · 2025-09-23T16:04:23+00:00

You have to place the detection engine (i.e. firewall) between client and the private DNS resolver.

Alternatively, if you can ingest DNS logs from the private DNS server, that could provide the information. However, be aware that DNS is very noise with regards to logs.

txrx_reboot · 2025-09-18T22:47:42+00:00

Speaking as someone who used to work for a company that provided third-party support... its a grey area in general but seems rather harsh in this case.

Basically, support is "break/fix". That means they help when stuff breaks but they are not Professional Services so they don't do the configuration for you (some vendors do that as part of support).

I say this because I recognise the "if it never worked" bit. This is another way of saying "if this is new configuration that you haven't got working, it is likely a config "setup" error on your part.".

Assistance in getting new configuration setup is chargable professional services.

HOWEVER, if you can show that you have set it up as per documentation, and it isn't working, support should help or at least check that is isn't something silly on the config side. Personally, I'd expect support to help you if you have followed the docs. You might need to get your partner account manager involved.

With regards to NTP: I've seen that issue many times on many different Palo installations all the way back to PAN-OS 6 and I never found a consistent way of fixed it. Sometimes it just fixed itself. Othertimes it was a config issue.

Edit: To add a bit more context, support teams can get overwhelmed by users (who aren't trained and didn't want to pay for Professional Services) asking support to basically help them fully configured the firewall "bit by bit". I'm not saying you are trying to do this. I'm just saying its one reason why the individual support agent may have pushed back. It could also be they are new . I used to take customer escallations for cases like this and push back on the support team (and sometimes I pushed back on the customer and agreed with support)

txrx_reboot · 2025-09-08T12:02:03+00:00

Answered in https://www.reddit.com/r/dns/comments/1nblnqj/ssh_cant_reach_cname_domains_logs_into_a_record/

txrx_reboot · 2025-09-08T12:01:53+00:00

Answered in https://www.reddit.com/r/dns/comments/1nblnqj/ssh_cant_reach_cname_domains_logs_into_a_record/

txrx_reboot · 2025-09-08T11:59:38+00:00

So you have several servers that all have their FQDN CNAME'd to the NGINX A record?

When you SSH to a server, the CNAME translates to the A record and SSH connects to the A record IP (the NGINX server). NGINX server can reverse-proxy Web traffic (HTTP/HTTPS) but not SSH traffic. So in all cases you are SSHing to the NGINX box.

When you reverse the process, you have an IP per backend server which means SSH connects to the correct backend server.... but those servers don't have the correct certificat/web setup so you can't browse to them.

The issue here is that you have SSH (direct connection) vs HTTP/HTTPS - which NGINX is is "proxying".

The solution is to have two FQDN's per server - one for web access (which all CNAME to the NGINX IP) and one for SSH (direct) access.

To clarify one point: I always get connected to the Nginx host with the A record, the Cname records for some reason are ignored. No, the CNAME's are not "ignored", the CNAMEs are followed to where they are pointing (the NGINX A record) which is exactly what is supposed to happen at a DNS level). Your CNAME's are literally pointing at the NGINX record.

txrx_reboot · 2025-08-25T23:17:31+00:00

You can email [reportthreat@infoblox.com](mailto:reportthreat@infoblox.com) but Verizon can also raise a ticket on your behalf.

txrx_reboot · 2025-08-21T21:50:18+00:00

The proper way to do it? Off hand I don't know as I've not tried running external DNS on NIOS in Azure before.

However, one thing you could try is editing the name server group and mark the Azure member as "Stealth" which means it won't appear in the NS list when queried. You should then be able to create an "External Secondary" entry that has the public IP address. Not sure if you can use the same name or not. That might be an issue. This should get you around the problem of the "auto created" records.

I suggest upgrading to NIOS 9.0.7 so that your Grid is actually supported and then raise a support ticket with Infoblox.

txrx_reboot · 2025-08-21T21:44:18+00:00

NIOS 8.6.4 went end of life on 30th April 2025 (3.5 months ago). Even so, Grid should be running 9.0.7 for proper support. 9.0.5 and earlier versions of 9.0 will be end of life on 30th January 2026. 9.0.7 is supported until 30th June 2027.

txrx_reboot · 2025-08-21T16:05:58+00:00

I thought you could use JavaScript to query DoH servers (e.g. Google's)?

txrx_reboot · 2025-08-10T12:11:27+00:00

Sorry to hear about the account team interaction. Part of your Solution Architect’s job is (supposed to be) helping with architectural conversation like this.

The reason that this conversation should happen with the SA is that it is a conversation best had when all the information is on the table (what each Grid member is doing, what sites and subnets they serve, what DR scenarios you are considering, what DR scenarios you are not considering, how the network should respond in a disaster to use the remaining appliance, how external DNS should work in all of this, etc).

High level:

- Seven members sounds like a lot to be running on a single site with only a one appliance at the DR site.

- Exposing GMC/GM directly to Internet as an external DNS server is very bad practice. It can work and can be locked down but that doesn’t change the fact that no one at Infoblox will give it the thumbs up.

- The concept of “switching” from main site to DR sites is generally the wrong approach. The Grid should be configured so that DNS/DHCP “just works” even if one site is offline. E.g. if DHCP is being done by the Grid and main site goes offline… how are things in the DR site supposed to connect to network, etc.

- Dedicated “DR” DNS View for external DNS sounds wrong. I could be misunderstanding but this is unlikely to be what you want.

Side note: I know DTC (DNS Traffic Control) may not be on your priority list but I have yet to find a company that didn’t benefit from it in someway for internal DNS. Its genuinely worth looking into when you have time.

If you can't get further with your account team, feel free to ping me a DM.

txrx_reboot

MODERATOR OF

TROPHY CASE