Can we provide recursion for forward zones in response to iterative queries?

[bind-lists at iano.org]

Thanks. I have opened a ticket with AWS support asking them to allow us to pull slave copies of our VPC-internal zones. If they don’t do that, then making the zones slaves will not fix our problem, because the AWS endpoints refuse to answer iterative queries.

Thanks,
Maria

> On Apr 7, 2020, at 4:09 PM, Mark Andrews <marka at isc.org> wrote:
> 
> Add delegations if they are missing. This is how DNS is designed to be managed.
> 
> This should have been done as  part of allocating the address  space  initially.
> -- 
> Mark Andrews
> 
>> On 8 Apr 2020, at 02:43, bind-lists at iano.org wrote:
>> 
>> Currently our linux caching resolvers have a forwarding rule for 10.in-addr.arpa back to a small subset of our approximately 200 AD domain controllers. We made it a stub zone at one point in the past, but ran into intermittent resolution problems, although I don’t recall the details. We’ve never tried making it a slave zone as you recommend. If it would be better to change that to a slave zone then we want to do that, but there is a concern. Not all subdomains are delegated under 10.in-addr.arpa over on the AD side, and it is used as a catch-all for those that aren’t. Hundreds of thousands of desktops, laptops, devices and servers are constantly renewing and updating their IP addresses, and that domain is constantly changing. This would lead to our caching resolvers constantly pulling zone transfers from the AD servers. What would you recommend we do on the linux side to mitigate that, and is it still best to make it a slave zone in that case? We can make recommendations for changes on the AD side, but changes there take longer and are more complex to put in place. It’s easier if we can work around it on the linux side.
>> 
>> Thanks!
>> Maria
>> 
>>> On Apr 6, 2020, at 8:30 PM, Mark Andrews <marka at isc.org> wrote:
>>> 
>>> As 10.in-addr.arpa is private namespace *all* of you recursive servers should be configured to serve it.  This is similar to how all of your recursive nameservers know where the root servers are except you are using a slave zone instead of a hint zone.
>>> 
>>> i.e.
>>> 
>>> 10.in-addr.arpa {
>>>   type slave;
>>>   masters { <address of AD server>; };
>>>   file “slave/10.in-addr.arpa”;// adjust to match your local conventions.
>>>   request-ixfr no;         // only use AXFR for 10.in-addr.arpa as it is coming from AD as IXFR does not work well.
>>>   forwarders { /* empty */ };  // use iterative resolution for the children of 10.in-addr.arpa.
>>> };
>>> 
>>> Forwarding should NEVER be needed if servers are reachable at the IP level.  If the solution says “configure a forward zone” it is almost always wrong.
>>> 
>>> Do the similar for the top of all other private namespaces you are using.
>>> 
>>> Mark
>>> 
>>>>> On 4 Apr 2020, at 03:06, bind-lists at iano.org wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> In summary, my question is whether there is a way to configure a bind caching server to provide recursion in response to iterative queries for records in a forward type zone.
>>>> 
>>>> The background is that we have:
>>>> 
>>>> - AD domain controllers that are authoritative for all of 10.in-addr.arpa. in our data centers - most clients point to these for DNS resolution.
>>>> - Linux bind caching resolvers in our data centers - domain controllers forward to these for anything they don’t own.
>>>> - Some AWS VPCs which have been allocated subdomains of 10.in-addr.arpa. and are routable from our data centers. These have Route53 inbound endpoints which answer queries for those subdomains.
>>>> - The bind caching resolvers have forwarding rules for those subdomains to the AWS inbound endpoints.
>>>> 
>>>> The subdomains in our AWS VPCs have NS records, but the servers those point to refuse queries for records in the subdomains. The zone resolution is taken care of by the Route53 resolver service. The Route53 inbound endpoints successfully resolve queries from our data centers for those subdomains as long as the recursion desired flag is set to 1 in the query. If recursion desired is set to 0 they do not send any reply at all.
>>>> 
>>>> We want to be able to resolve PTR records in the subdomains in the AWS VPCs from our data centers where, as I said above, the clients point to the domain controllers for DNS resolution.
>>>> 
>>>> Because the AD domain controllers already own 10.in-addr.arpa, they refuse to allow us to configure conditional forwarding for its subdomains. So we delegated the subdomains to the inbound endpoints. Because they are delegations, the domain controllers set the recursion desired flag to 0 on the queries they send to the endpoints, and we are not getting replies from the endpoints.
>>>> 
>>>> As a workaround we tried delegating to our linux bind caching resolvers but we ran into the same issue, that the domain controllers set recursion desired to 0. As a result, when our linux caching servers have the result in cache, the lookup is successful, but when it would require a fresh lookup it gets a reply with no answers. Hence my question, is there a way to tell our bind caching resolvers to ignore the recursion desired flag and provide recursion anyway?
>>>> 
>>>> Thanks,
>>>> Maria
>>>> _______________________________________________
>>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>>> 
>>>> bind-users mailing list
>>>> bind-users at lists.isc.org
>>>> https://lists.isc.org/mailman/listinfo/bind-users
>>> 
>>> -- 
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742              INTERNET: marka at isc.org
>>> 
>> 
>