Infoblox’s global team of threat hunters uncovers a DNS operation with the ability to bypass traditional security measures and control the Great Firewall of China. Read about “Muddling Meerkat” and the many other threat actors discovered by Infoblox Threat Intel here.



DNS Forwarding RFC

[ Edited ]
New Member
Posts: 5
3146     0

We have several implementation of DDI and DNS Forwarding. Mostly the top Zones are on Infoblox DDI and some of the sub-zones are forwarded (as you cant delegate) to other DNS systems such as MS or AWS, Azure etc.

One of the vendors mentioned that this is not in RFC and breaking the RFC rules. I am just wondering if this is the case i.e. Forwarding a sub-zone to another resolver.?

Can you please let me know which RFC and why does Infoblox allows it if its breaking RFC.

Any help with this will be appreciated.


Re: DNS Forwarding RFC

[ Edited ]
Posts: 188
3147     0

That's bullsh1t. You can forward sub-zones instead of delegate them, I have done it, and in fact when you are hosting sub-zones in Azure you have to forward because delegating to Azure does not reliably work. I do not know why but I have seen Azure DNS intermittently reply with "REFUSED" response codes when a sub-zone has been delegated, this was causing outages for us and I changed it to a forwarder instead of delegation and it has been working fine ever since.


This does not break any RFCs I am aware of, but there have been RFCs published that discuss "best practices" - maybe it's one of those?

Paul Roberts
PCN (UK) Ltd

All opinions expressed are my own and not representative of PCN Inc./PCN (UK) Ltd. E&OE

Re: DNS Forwarding RFC

Posts: 14
3147     0

If you do forwarding and plan to use DNSSEC signing and validation, things may break in this case..  I think there are some changes in newer NIOS versions that will work around this by adding the delegation anyway if it is authoritative for the parent, but I have not tested it.


As for RFCs go, in most cases (with the exception of the above note) it works but there are not usually the NS records that go along with sub-zone/delegation in the apex/parent so perhaps that's the RFC violation when forwarding? 


By works, what I mean is that since it has a separate zone definition in the named.conf we get to skip that part of the recursion process and just ask that remote NS and expect it to handle any additional recursion that may be needed on behalf of the client NS -- well in the normal case....  In forward first, if the forwarding NS is not reachable then you fall back to recursion which depending on the configuration and layout of zones it may or may not work the way you expect.


I am curious as to the initial question’s comment around “(as your can’t delegate)”.  Can you elaborate on this?  There should be no issue delegating zones to non-infoblox DNS servers so I don’t understand the comment here…  Is it that you must forward because you want the remote end to have sub-delegations of your delegation and expect the remote end to do the recursion instead (b/c firewall rules)?


Showing results for 
Search instead for 
Did you mean: 

Recommended for You

Demo: Infoblox IPAM plug-in integration with OpenStack Newton