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: dnssec-signzone
David Alexandre M. de Carvalho wrote: > So I'm still fighting with dnssec in BIND 9.8.2 (oracle linux 6). > Unfortunately no automatic sigining before Bind 9.9, from what I read. BIND 9.8 has automatic signing, but not inline signing. However nsdiff is almost as good as inline signing, and I wrote it 9 years ago (!) around the time of 9.8.0 to make it easier to update signed zones. It's easier than dnssec-signzone. https://fanf.livejournal.com/112476.html http://dotat.at/prog/nsdiff/ Tony. -- f.anthony.n.finchhttp://dotat.at/ work to the benefit of all ___ 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
[Fwd: dnssec-signzone]
Hi again. So finally i was able to sign my zone thanks to a different (older) tutorial. I specified dnssec-signzone with flags -o and -S and it worked! If anyone could please answer these questions, I would appreciate it 1) do I need to generate those 2 .key and .private files if I intend to sign my several reverse zones? - I think so. 2) What happens if I need to change a record in my zone.signed file? Do I need to sign it again? Please remember my bind version is 9.8.2 so I have to automatic mechanisms. Thank you very much! - Mensagem Original -- Assunto: dnssec-signzone De: "David Alexandre M. de Carvalho" Data:Seg, Abril 6, 2020 4:05 pm Para:bind-users@lists.isc.org -- Hi all. So I'm still fighting with dnssec in BIND 9.8.2 (oracle linux 6). Unfortunately no automatic sigining before Bind 9.9, from what I read. I can't sign my zone, I keep getting "dnssec-signzone: fatal: No signing keys specified or found." By now I've tried to move the files generated with dnssec-keygen but no success. I'm using bind-chroot and created a temp folder /var/named/my_keys. Here, I've created the 2 .key and .private files. Since dnssec-signzone couldn't find the keys (even specifying -k or -K), I've copied them to /etc/pki/dnssec-keys and run the command with the same result. Now, I've copied all the key and private files to /var/named/chroot/var/named where my zone file exists (di.hosts) running from there, I also get "dnssec-signzone: fatal: No signing keys specified or found." I changed the owner and group to "named", and they are both readable. Could anyone please tell me what am I doing wrong? also, do I need to generate those 2 .key and .private files if I intend to sign my several reverse zones? Thank you very much! Regards Os melhores cumprimentos David Alexandre M. de Carvalho --- Especialista de Informática Departamento de Informática Universidade da Beira Interior ___ 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
dnssec-signzone
Hi all. So I'm still fighting with dnssec in BIND 9.8.2 (oracle linux 6). Unfortunately no automatic sigining before Bind 9.9, from what I read. I can't sign my zone, I keep getting "dnssec-signzone: fatal: No signing keys specified or found." By now I've tried to move the files generated with dnssec-keygen but no success. I'm using bind-chroot and created a temp folder /var/named/my_keys. Here, I've created the 2 .key and .private files. Since dnssec-signzone couldn't find the keys (even specifying -k or -K), I've copied them to /etc/pki/dnssec-keys and run the command with the same result. Now, I've copied all the key and private files to /var/named/chroot/var/named where my zone file exists (di.hosts) running from there, I also get "dnssec-signzone: fatal: No signing keys specified or found." I changed the owner and group to "named", and they are both readable. Could anyone please tell me what am I doing wrong? also, do I need to generate those 2 .key and .private files if I intend to sign my several reverse zones? Thank you very much! Regards Os melhores cumprimentos David Alexandre M. de Carvalho --- Especialista de Informática Departamento de Informática Universidade da Beira Interior ___ 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
Re: Non-disruptive migration to dnssec-policy possible?
To follow-up, Migration from existing keys to dnssec-policy was indeed not working properly, because the internal key states were not initialized properly. Key states were always initialized as "HIDDEN" and that is why the keymgr thought it could delete those keys immediately. The fix is to look more closely at key timing metadata and set the internal key state appropriately. This is fixed in the upcoming 9.16.2 release. Best regards, Matthijs On 3/26/20 8:34 PM, Håkan Lindqvist wrote: > I reported a bug with the requested details: > https://gitlab.isc.org/isc-projects/bind9/issues/1706 > > > A related thing that I've noticed in my tests is that "dnssec-policy x" > seems to also imply "inline-signing yes"? > Is this intended as a strict requirement, it seems a little awkward? > > On that note, combining "dnssec-policy x" with "inline-signing no" does > not seem to be handled gracefully. > This makes me suspect that it's not an intended scenario, is that correct? > > > /Håkan > > On 2020-03-25 16:57, Håkan Lindqvist via bind-users wrote: >> On 2020-03-25 14:03, Matthijs Mekking wrote: >>> Existing keys do not have a .state file, and so named will try to match >>> those keys with the policy by looking at the data in the .key and >>> .private files. However, perhaps some metadata is different? If so the >>> keys don't match the policy and named will try to replace them (I >>> suspect the DNSKEY TTL is different). >> >> Looking at the .key files, I can confirm that the old files (created >> by dnssec-keygen) omit the TTL field, while the new .key files have a >> 3600 TTL specified. >> >> I suppose that the dnssec-keygen output depends on whether the -L >> option was used or not (based on this, I would guess that it's quite >> common to have .key files with no TTL in the wild). >> >> >>> You can use the dnssec-settime tool to write the state file, but it is >>> more intended to be a method for debugging and testing. >> >> Ok. No, I don't particularly want the .state files, it was just a >> question of whether they were expected/needed ahead of time. >> >> >>> It is odd that it immediately deletes the existing keys. I would like to >>> follow-up on this. Would you be able to rerun the experiment with the >>> dnssec log category set to debug? That way we can see what the internal >>> keymgr decided about those keys. >>> >>> If so, could you create an issue for it on our GitLab repository? >>> >>> https://gitlab.isc.org/isc-projects/bind9/ >> >> Ok, I will try this and report back. (Also whether adding a TTL to the >> .key file avoids the problem) >> >> >> /Håkan >> >> >> ___ >> 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 signature.asc Description: OpenPGP digital signature ___ 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
