Re: [Non-DoD Source] BIND Masters and slaves

[bind-lists]

I have been teaching informal DNS classes at work for decades, and I used to be 
very careful to use “master” and “slave” and would include a section where I 
pointed out that using “primary” and “secondary” instead was not correct. Then 
about 10 years ago one person in class pointed out to me that for some people 
when they hear that terminology it really bothers them because of what slavery 
means. When she said that a few other people nodded and agreed. I hadn’t 
thought about that aspect of it, and so someone had to explain to me how 
jarring and distracting from the subject matter that could be for some people. 
I’ve used “primary” and “secondary” in all my classes and documentation since 
then. Not because of twitter and social media or because I have an image to 
uphold, but in order to be considerate of other people’s feelings and not 
dismiss them because they’re so different from mine.

I would like to see the terms replaced by something that doesn’t hearken back 
to tragedy and torture.

Maria

> On Jun 15, 2020, at 2:15 PM, Michael De Roover  wrote:
> 
> Of course I could, but I do not feel like the effort to change nomenclature 
> is either beneficial or worth taking for granted the requests of some people 
> on Twitter - as the slave to peer authority I am - given how much it affects 
> documentation, code, comments, general environment of the projects 
> themselves. I enjoy being surrounded by people much smarter than I am when it 
> comes to the mailing list here. Let's keep it that way and not derange 
> ourselves into meaningless blabber from social media.
> 
> What I did notice over time however that most of the projects affected are 
> also those who do have to maintain a good public image, usually corporations. 
> Meanwhile projects such as Opal  and 
> recently Rubocop  as well 
> were not. The latter one I'd like to draw attention to. The maintainer 
> clearly didn't ask for this and asked everyone who shamed him, why are you 
> doing this? None of the complainers were affiliated to the project at all. 
> Chances are that they weren't even using it and just searched for projects 
> with the name "cop" in it instead. These are not the people I want to support 
> in my effort to end racism, which I do support, and quite heavily so.
> 
> On 6/15/20 8:00 PM, DeCaro, James John (Jim) CIV DISA FE (USA) wrote:
>> Or you can call the slave servers 'secondary' servers.  
> -- 
> Met vriendelijke groet / Best regards,
> Michael De Roover

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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?

[bind-lists]

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?

[bind-lists]

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?

[bind-lists]

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  

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

[bind-lists]

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