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-li...@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 <ma...@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-li...@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@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: ma...@isc.org
>>
>
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
