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 <ma...@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-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
