Re: Can we provide recursion for forward zones in response to iterative queries?
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 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 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 { ; };
>>> 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
Re: Can we provide recursion for forward zones in response to iterative queries?
I had been told they tried that twice and in both cases the domain controller would not let them add the conditional forwarder. On the strength of your having said it worked in your situation, they tried again and now it is working. Thank you! Maria > On Apr 6, 2020, at 11:37 AM, Chris Buxton wrote: > > On Apr 3, 2020, at 9:06 AM, bind-li...@iano.org wrote: >> 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? > > I've solved this before. You've tried two solutions, and neither worked > alone. You need to do both. > > - Delegate the subzones in question to the forwarders (or anywhere, really). > - Add conditional forwarding for the subzones also, pointing to the > forwarders. > > Without the delegation, the conditional forwarding won't work -- the MS DNS > servers will respond authoritatively. But without the conditional forwarding, > the MS DNS servers will send iterative queries, not recursive queries. > > Regards, > Chris Buxton ___ 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
Re: Can we provide recursion for forward zones in response to iterative queries?
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 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 { ; };
>>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
>>> ___
Re: Can we provide recursion for forward zones in response to iterative queries?
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 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 { ; };
> 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
Re: Can we provide recursion for forward zones in response to iterative queries?
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 { ; };
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
Re: Can we provide recursion for forward zones in response to iterative queries?
On Apr 3, 2020, at 9:06 AM, bind-li...@iano.org wrote: > 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? I've solved this before. You've tried two solutions, and neither worked alone. You need to do both. - Delegate the subzones in question to the forwarders (or anywhere, really). - Add conditional forwarding for the subzones also, pointing to the forwarders. Without the delegation, the conditional forwarding won't work -- the MS DNS servers will respond authoritatively. But without the conditional forwarding, the MS DNS servers will send iterative queries, not recursive queries. Regards, Chris Buxton ___ 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
Re: Can we provide recursion for forward zones in response to iterative queries?
> 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. Yuck, what a horrible problem. I don't know of any easy solutions, but I can think of two difficult ones: * Reconfigure everything to use BIND for recursive DNS instead of AD. * Try using dnsdist - except that as far as I can tell from its documentation it can force RD=0 but not RD=1, so you'll need to patch it to get the functionality you need. Tony. -- f.anthony.n.finchhttp://dotat.at/ Tyne, Dogger: South 5 or 6, veering west or southwest 3 or 4. Moderate occasionally rough at first, becoming slight. Rain at first. Good, occasionally poor at first. ___ 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
Can we provide recursion for forward zones in response to iterative queries?
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
