- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Printer Friendly Page
DNS Forwarding RFC[ Edited ]
03-10-2021 03:13 AM - edited 03-11-2021 02:36 AM
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 ]
03-11-2021 03:48 AM - edited 03-11-2021 03:49 AM
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?
PCN (UK) Ltd
All opinions expressed are my own and not representative of PCN Inc./PCN (UK) Ltd. E&OE
Re: DNS Forwarding RFC
03-11-2021 04:18 AM
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? https://tools.ietf.org/html/rfc8499#section-7
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)?