RE: DNSSEC and forward zone
Hi, thanks for the reply.
There really is not much I can tell you about my parent zone. For now, I made
an exclusion with “validate-except” and everything seems to be working fine
both internally and externally.
Not sure about your first suggestion, as the top domain is also served
internally by Active Directory. The clients “think” it is the main domain
server (except my networks which use my dns servers).
“A bit better solution would be adding DS record to parent pt zone also for
internal KSK key.” – I think this is the possibility they are studying.
Unfortunately I don’t know that much about the parent setup.
Anyway, thanks and regards!
David
From: bind-users On Behalf Of Petr Menšík
Sent: 21 April 2023 10:59
To: bind-users@lists.isc.org
Subject: Re: DNSSEC and forward zone
Would it make sense to create a subdomain for internal use, but have the main
zone signed with external records only? Is it possible to make changes to names?
Can you make for example in.ubi.pt just internal only, not accessible from
outside?
If you want to have your external zone signed with DNSSEC, then internal zone
has to be signed with DNSSEC too. You can workaround different KSK keys by
adding trust anchor to all your validating resolvers. A bit better solution
would be adding DS record to parent pt zone also for internal KSK key.
If you make internalsite2.ubi.pt unsigned zone, with own NS and SOA, then it
can be not signed, when the main ubi.pt zone is. But the indication from the
parent has to match. Both zones have to be signed or none. Internal zone would
work too with trust-anchor explicitly added to your resolvers. Unless you want
to ignore your own zone signatures, internal zone should be signed too.
On 4/19/23 11:49, David Carvalho via bind-users wrote:
Hi and thanks for the reply.
Does it make sense to not validate my parent domain entirely? Wouldn’t that
also stop exterior validation when I request it?
Thanks!
David
From: Darren Ankney <mailto:darren.ank...@gmail.com>
Sent: 19 April 2023 10:27
To: David Carvalho <mailto:da...@di.ubi.pt>
Cc: Bind Users Mailing List <mailto:bind-users@lists.isc.org>
Subject: Re: DNSSEC and forward zone
Hi David,
You can disable validation on one or more domains using "validate-except" -
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-validate-except
Thank you,
Darren Ankney
On Wed, Apr 19, 2023 at 5:05 AM David Carvalho via bind-users
mailto:bind-users@lists.isc.org> > wrote:
Hello guys
Asking for your help, again.
So after setting up DNSSEC I’ve found I couldn’t reach some internal sites on
my top domain, served by internal DNS servers
There’s no need in hiding domains as my e-mail is shown here.
Top domain
ubi.pt <http://ubi.pt> (external DNS Servers authoritative)
Internal DNS servers (windows, Active directory - Recursive)
Internalsite1.ubi.pt <http://Internalsite1.ubi.pt>
Internalsite2.ubi.pt <http://Internalsite2.ubi.pt>
…
di.ubi.pt <http://di.ubi.pt>
(both authoritative and recursive for my networks)
Previously I had the following to get internal sites resolved, but now it seems
it is completely discarded by dnssec.
zone "ubi.pt <http://ubi.pt> " IN {
type forward;
forwarders { 192.168.100.1; 192.168.100.2; };
}
Is there any configuration to allow me to be able to access internal sites
served by internal dns servers, I guess not using DNSSEC?
Can this only be accomplished by adding these entries to my parent domain?
Thanks!
Kind regards
David Carvalho
--
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 <mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--
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: DNSSEC and forward zone
Hello and thanks.
For now I disabled dnssec for the zone, as there were sites that need to be
accessible.
I found
dnssec: info: validating internalsite2.ubi.pt/CNAME: got insecure response;
parent indicates it should be secure
I've been told Internal dns (windows) are not set to use dnssec, and even if
they were, the key would be different than that on the outside servers, which
is the same domain.
Not optimistic
Regards
David
-Original Message-
From: bind-users On Behalf Of Petr Špacek
Sent: 19 April 2023 10:35
To: bind-users@lists.isc.org
Subject: Re: DNSSEC and forward zone
You can disable it, but that's just workaround.
It would be better to fix it :-)
I would recommend checking logs on resolver which is failing to resolve the
domain. I guess you will find out a DNSSEC validation error would tell us
what's misconfigured.
My bet is that the internal domains are missing delegation from the parent
domain, which was incorrect even before and worked just accidentally.
E.g the ubi.pt zone file needs NS records which point to subdomains
Internalsite1.ubi.pt and di.ubi.pt etc.
If you do not want these domains to resolve from outside, just configure ACL on
the authoritative servers to not respond to queries from outside of your
network.
I hope it helps.
Petr Špaček
On 19. 04. 23 11:27, Darren Ankney wrote:
> Hi David,
>
> You can disable validation on one or more domains using
> "validate-except" -
> https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statem
> ent-validate-except
> <https://bind9.readthedocs.io/en/latest/reference.html#namedconf-state
> ment-validate-except>
>
> Thank you,
>
> Darren Ankney
>
> On Wed, Apr 19, 2023 at 5:05 AM David Carvalho via bind-users
> mailto:bind-users@lists.isc.org>> wrote:
>
> Hello guys
>
> Asking for your help, again.
>
> __ __
>
> So after setting up DNSSEC I’ve found I couldn’t reach some internal
> sites on my top domain, served by internal DNS servers
>
> There’s no need in hiding domains as my e-mail is shown here.
>
> __ __
>
> Top domain
>
> __
>
>
>
> __
>
> __ __
>
>
> ubi.pt <http://ubi.pt> (external DNS Servers authoritative)
>
> __ __
>
>Internal DNS servers (windows, Active directory -
> Recursive)
>
> Internalsite1.ubi.pt <http://Internalsite1.ubi.pt>
>
> Internalsite2.ubi.pt <http://Internalsite2.ubi.pt>
>
> …
>
> __ __
>
> __ __
>
> di.ubi.pt <http://di.ubi.pt>
>
> (both authoritative and recursive for my networks)
>
> __ __
>
> Previously I had the following to get internal sites resolved, but
> now it seems it is completely discarded by dnssec.
>
> __ __
>
> zone "ubi.pt <http://ubi.pt>" IN {
>
> type forward;
>
> forwarders { 192.168.100.1; 192.168.100.2; };
>
> }
>
> __ __
>
> Is there any configuration to allow me to be able to access
> internal sites served by internal dns servers, I guess not using
> DNSSEC?
>
> Can this only be accomplished by adding these entries to my parent
> domain?
>
> Thanks!
--
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
--
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: DNSSEC and forward zone
Anyway, It is working using your suggestion. Apparently everything is also fine
from the outside.
But I’ll have to check Petr Špaček post and study more.
Thanks!
David
From: Darren Ankney
Sent: 19 April 2023 10:27
To: David Carvalho
Cc: Bind Users Mailing List
Subject: Re: DNSSEC and forward zone
Hi David,
You can disable validation on one or more domains using "validate-except" -
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-validate-except
Thank you,
Darren Ankney
On Wed, Apr 19, 2023 at 5:05 AM David Carvalho via bind-users
mailto:bind-users@lists.isc.org> > wrote:
Hello guys
Asking for your help, again.
So after setting up DNSSEC I’ve found I couldn’t reach some internal sites on
my top domain, served by internal DNS servers
There’s no need in hiding domains as my e-mail is shown here.
Top domain
ubi.pt <http://ubi.pt> (external DNS Servers authoritative)
Internal DNS servers (windows, Active directory - Recursive)
<http://Internalsite1.ubi.pt> Internalsite1.ubi.pt
<http://Internalsite2.ubi.pt> Internalsite2.ubi.pt
…
di.ubi.pt <http://di.ubi.pt>
(both authoritative and recursive for my networks)
Previously I had the following to get internal sites resolved, but now it seems
it is completely discarded by dnssec.
zone "ubi.pt <http://ubi.pt> " IN {
type forward;
forwarders { 192.168.100.1; 192.168.100.2; };
}
Is there any configuration to allow me to be able to access internal sites
served by internal dns servers, I guess not using DNSSEC?
Can this only be accomplished by adding these entries to my parent domain?
Thanks!
Kind regards
David Carvalho
--
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 <mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
--
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: DNSSEC and forward zone
Hi and thanks for the reply.
Does it make sense to not validate my parent domain entirely? Wouldn’t that
also stop exterior validation when I request it?
Thanks!
David
From: Darren Ankney
Sent: 19 April 2023 10:27
To: David Carvalho
Cc: Bind Users Mailing List
Subject: Re: DNSSEC and forward zone
Hi David,
You can disable validation on one or more domains using "validate-except" -
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-validate-except
Thank you,
Darren Ankney
On Wed, Apr 19, 2023 at 5:05 AM David Carvalho via bind-users
mailto:bind-users@lists.isc.org> > wrote:
Hello guys
Asking for your help, again.
So after setting up DNSSEC I’ve found I couldn’t reach some internal sites on
my top domain, served by internal DNS servers
There’s no need in hiding domains as my e-mail is shown here.
Top domain
ubi.pt <http://ubi.pt> (external DNS Servers authoritative)
Internal DNS servers (windows, Active directory - Recursive)
Internalsite1.ubi.pt <http://Internalsite1.ubi.pt>
Internalsite2.ubi.pt <http://Internalsite2.ubi.pt>
…
di.ubi.pt <http://di.ubi.pt>
(both authoritative and recursive for my networks)
Previously I had the following to get internal sites resolved, but now it seems
it is completely discarded by dnssec.
zone "ubi.pt <http://ubi.pt> " IN {
type forward;
forwarders { 192.168.100.1; 192.168.100.2; };
}
Is there any configuration to allow me to be able to access internal sites
served by internal dns servers, I guess not using DNSSEC?
Can this only be accomplished by adding these entries to my parent domain?
Thanks!
Kind regards
David Carvalho
--
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 <mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
--
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
DNSSEC and forward zone
Hello guys
Asking for your help, again.
So after setting up DNSSEC I've found I couldn't reach some internal sites
on my top domain, served by internal DNS servers
There's no need in hiding domains as my e-mail is shown here.
Top domain
ubi.pt (external DNS Servers authoritative)
Internal DNS servers (windows, Active directory - Recursive)
Internalsite1.ubi.pt
Internalsite2.ubi.pt
.
di.ubi.pt
(both authoritative and recursive for my networks)
Previously I had the following to get internal sites resolved, but now it
seems it is completely discarded by dnssec.
zone "ubi.pt" IN {
type forward;
forwarders { 192.168.100.1; 192.168.100.2; };
}
Is there any configuration to allow me to be able to access internal sites
served by internal dns servers, I guess not using DNSSEC?
Can this only be accomplished by adding these entries to my parent domain?
Thanks!
Kind regards
David Carvalho
--
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
FW: dnssec-validation? SOLVED
Hello. I just want to say everything seems to be working on my domain, and my primary dns server already performs validation Dnssec-validation is set to auto, like on the secondary dns, and it's working. When I perform Dig @dns www.dnssec-failed.org it already returns SERVFAIL and the rest seems fine. It turns out that "managed-keys.bind" and "managed-keys.bind.jnl" were copied into the working folder from my previous dnssec impletation try. Removed, as indicated at: https://kb.isc.org/docs/aa-01182 And everythings seems fine. The Kdi.ubi.pt*.files also are aok after restarting the service. Thank you all who took the time to clarify me about this. Kind regards David Carvalho -Original Message- From: Mark Andrews Sent: 14 April 2023 02:35 To: David Carvalho Cc: Evan Hunt ; bind-users@lists.isc.org Subject: Re: dnssec-validation? > On 13 Apr 2023, at 19:23, David Carvalho via bind-users > wrote: > > Hello and thank you for the reply. > My domain is "di.ubi.pt". The parent domain "ubi.pt" recently > configured DNSSEC (BIND 9.11) so it was time again for me to try to > set it up for my domain. > > A few months ago I updated both dns servers to Oracle Linux 8, running > BIND > 9.16.23 to prepare for this. > They seem to be working fine as previously, running as both recursive > and authoritative for di.ubi.pt. > > DNS2 has still "dnssec-validation auto;" on its /etc/named.conf. > I've found out that if I wanted my primary server to start answering > my internal requests for outside "di.ubi.pt" I had to change > dnssec-validation to "no". > I still don't understand why, to be honest. Look at your logs. If named is having problems it will be logging error messages. What does "rndc managed-keys status” report? % rndc managed-keys status view: secure next scheduled event: Fri, 14 Apr 2023 02:04:19 GMT name: . keyid: 20326 algorithm: RSASHA256 flags: SEP next refresh: Sat, 15 Apr 2023 00:53:04 GMT trusted since: Fri, 11 Aug 2017 01:07:03 GMT view: forward next scheduled event: Fri, 14 Apr 2023 02:04:19 GMT name: . keyid: 20326 algorithm: RSASHA256 flags: SEP next refresh: Sat, 15 Apr 2023 00:53:04 GMT trusted since: Tue, 10 May 2022 05:09:01 GMT view: external next scheduled event: Fri, 14 Apr 2023 03:04:19 GMT name: . keyid: 20326 algorithm: RSASHA256 flags: SEP next refresh: Fri, 14 Apr 2023 03:04:19 GMT trusted since: Thu, 10 Aug 2017 13:01:30 GMT % Are you using a forwarder? Does the forwarder support DNSSEC? Do you have an overly restrictive firewall? What does “dig +cd +dnssec +multi . DNSKEY” return? % dig +cd +dnssec +multi . DNSKEY ;; BADCOOKIE, retrying. ; <<>> DiG 9.19.11-dev <<>> +cd +dnssec +multi . DNSKEY ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10255 ;; flags: qr rd ra ad cd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 9c2f2034f253efff01006438ad22999ed76ba1835477 (good) ;; QUESTION SECTION: ;. IN DNSKEY ;; ANSWER SECTION: . 88321 IN DNSKEY 257 3 8 ( AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN 7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5 LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8 efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7 pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws 9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ) ; KSK; alg = RSASHA256 ; key id = 20326 . 88321 IN DNSKEY 256 3 8 ( AwEAAbF1LAxEQPtClEQno48k6u7JjCOfVfwdENOxQUrX 0JbpN5DnKGMAKIfdiWa5oDeKQ3OoQ58yCC8vjtaaGFDg pJxoLwqzhBYHPGFgins5HIERcCQPGAJKWu/ku4XLh+Fu 7UyBubDCelxKTbnj26EwbochltRqGIE8hbwSXEzRNo4g +NXkaRMq2FFbaBtEE82yTmZUgFRYAFUvfGTPWblyZGtk epVuHyNb0w/u24dpsz+uyCZZR04cHfRrWOKvqD3lDOwC 4+sqd6f7F841R0N2tqSh/WDUZzWdvPBaBOz0FWFLb9po rIeZ3Jm08tAMHa+3SGRXfK4RAmxVCmIQQypGabE= ) ; ZSK; alg = RSASHA256 ; key id = 60955 . 88321 IN RRSIG DNSKEY 8 0 172800 ( 2023050200 2023041100 20326 . ID/zjsZ8MPaJMm4Ilw9PESU92a/MvPFKlKkE8d2qAbDV fMGYQikmls8z0fIorVfoGECgiEey42+Y4Bk99qTEFxPr Cml12/xyJcmzQICQcr28djuMMA+yY7w57GuRLkE+LTnl 5IdlucNf52gS/eKSBIjKH3hNYElH6BwIbTHKV5Jh1ZJg FTo+FRtrniR4HlhhHaydDVLc2A8FG3Whl1kyATDlqcLr F6yqbjAhNR0+Ak26gd5BkY9kwOYCMZ2KQ1RBKRmG3Dbk tohYVHbH2j6B6kfIjooRwY5hWyNQnBZP6LOHQLyfYrUT R3EK438G9VW0tXvNqL3ssDhuxhbFy7x3hw== ) ;; Query time: 0 msec ;; SERVER: ::1#53(::1) (UDP) ;; WHEN: Fri Apr 14 11:32:18 AEST 2023 ;; MSG SIZE rcvd: 892 % > Yesterday I set dnssec-validation to auto on my primary server, but as > I wrote before, although outside tools showed everything was fine, my > server kept answering "SERVFAIL" to my client queries. I don't think I > tested dnssec-validation to no when dnssec was enabled, nor if this > mak
RE: dnssec-validation?
Hi and thanks for the reply. "Do you have an overly restrictive firewall?" - yes. Tried to reach the network guy but he won't be here this week. But it is unlikely, because dns2 is working fine and, from what I've been told, they are in the same ACL group. - This is my output: rndc managed-keys status view: _default next scheduled event: Thu, 13 Apr 2023 10:18:05 GMT name: . keyid: 0 algorithm: 0 flags: (none) next refresh: Thu, 26 Jan 2023 16:05:04 GMT no trust --- dig +cd +dnssec +multi . DNSKEY ; <<>> DiG 9.11.36-RedHat-9.11.36-5.el8_7.2 <<>> +cd +dnssec +multi . DNSKEY ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39638 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 01c1387577eb12360100643910a2f6b0163c1001c9b2 (good) ;; QUESTION SECTION: ;. IN DNSKEY ;; ANSWER SECTION: . 92475 IN DNSKEY 257 3 8 ( AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN 7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5 LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8 efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7 pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws 9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ) ; KSK; alg = RSASHA256 ; key id = 20326 . 92475 IN DNSKEY 256 3 8 ( AwEAAbF1LAxEQPtClEQno48k6u7JjCOfVfwdENOxQUrX 0JbpN5DnKGMAKIfdiWa5oDeKQ3OoQ58yCC8vjtaaGFDg pJxoLwqzhBYHPGFgins5HIERcCQPGAJKWu/ku4XLh+Fu 7UyBubDCelxKTbnj26EwbochltRqGIE8hbwSXEzRNo4g +NXkaRMq2FFbaBtEE82yTmZUgFRYAFUvfGTPWblyZGtk epVuHyNb0w/u24dpsz+uyCZZR04cHfRrWOKvqD3lDOwC 4+sqd6f7F841R0N2tqSh/WDUZzWdvPBaBOz0FWFLb9po rIeZ3Jm08tAMHa+3SGRXfK4RAmxVCmIQQypGabE= ) ; ZSK; alg = RSASHA256 ; key id = 60955 . 92475 IN RRSIG DNSKEY 8 0 172800 ( 2023050200 2023041100 20326 . ID/zjsZ8MPaJMm4Ilw9PESU92a/MvPFKlKkE8d2qAbDV fMGYQikmls8z0fIorVfoGECgiEey42+Y4Bk99qTEFxPr Cml12/xyJcmzQICQcr28djuMMA+yY7w57GuRLkE+LTnl 5IdlucNf52gS/eKSBIjKH3hNYElH6BwIbTHKV5Jh1ZJg FTo+FRtrniR4HlhhHaydDVLc2A8FG3Whl1kyATDlqcLr F6yqbjAhNR0+Ak26gd5BkY9kwOYCMZ2KQ1RBKRmG3Dbk tohYVHbH2j6B6kfIjooRwY5hWyNQnBZP6LOHQLyfYrUT R3EK438G9VW0tXvNqL3ssDhuxhbFy7x3hw== ) ;; Query time: 0 msec ;; SERVER: 193.136.66.1#53(193.136.66.1) ;; WHEN: Fri Apr 14 09:36:50 WEST 2023 ;; MSG SIZE rcvd: 893 Outside tests also seem to be ok. Didn't find anything yet in the logs. I will compare (again) my named.conf on the primary and secondary server to find why dnssec-validation needs to be off on the primary. Thanks! David -Original Message- From: Mark Andrews Sent: 14 April 2023 02:35 To: David Carvalho Cc: Evan Hunt ; bind-users@lists.isc.org Subject: Re: dnssec-validation? > On 13 Apr 2023, at 19:23, David Carvalho via bind-users > wrote: > > Hello and thank you for the reply. > My domain is "di.ubi.pt". The parent domain "ubi.pt" recently > configured DNSSEC (BIND 9.11) so it was time again for me to try to > set it up for my domain. > > A few months ago I updated both dns servers to Oracle Linux 8, running > BIND > 9.16.23 to prepare for this. > They seem to be working fine as previously, running as both recursive > and authoritative for di.ubi.pt. > > DNS2 has still "dnssec-validation auto;" on its /etc/named.conf. > I've found out that if I wanted my primary server to start answering > my internal requests for outside "di.ubi.pt" I had to change > dnssec-validation to "no". > I still don't understand why, to be honest. Look at your logs. If named is having problems it will be logging error messages. What does "rndc managed-keys status” report? % rndc managed-keys status view: secure next scheduled event: Fri, 14 Apr 2023 02
RE: dnssec-validation?
Hello and thank you for the reply. Problem 1 - I'll have to investigate further. As for problem 2 ... it's weird. I was working on another thing and now I was checking permissions by your suggestion, when I noticed the files have new timestamp from a while ago. I compared the contents of the updated files with a previous backup and they seem the same. Tests such as https://dnssec-analyzer.verisignlabs.com/di.ubi.pt also seem to be still fine. So, my conclusion is: Named changes the Kdi.ubi.pt** timestamps according to some criteria. If I do a systemctl restart named-chroot or rdnc reload, the contents also change (and according to a response I got earlier this is a bug solved in version 9.16.30) I've been told to upgrade to version 9.18 and I'm setting a test server to do this. In the meantime, if there is a way to avoid the keys to be rewritten every time I reconfigure and reload, I would stick with this version. Regards David -Original Message- From: Evan Hunt Sent: 13 April 2023 18:08 To: David Carvalho Cc: bind-users@lists.isc.org Subject: Re: dnssec-validation? On Thu, Apr 13, 2023 at 11:38:15AM +0100, David Carvalho wrote: > Problem number 1: Dnssec seems to be running on "di.ubi.pt", but > dnssec-validation still needs to be set to no; Will this cause troubles? > Dns2 is set to auto and runs fine. >From here, di.ubt.pt appears to be properly signed and everything's >working from here. Turning off validation won't have any affect on that. Your only problem is with local recursive service. > Problem number 2: How can I avoid the key regeneration (using version > 9.16.23) every named restart? I'm not certain what you mean by key regeneration. Taking a stab in the dark: Check that the working directory for named is writable. If named can't write files, then it can't save trust anchor status across restarts and it has to reinitialize each time. If that doesn't turn out to be the problem, then can show me the relevant lines from your log file so I can see what you're referring to by "key regeneration"? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- 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: Fully automated DNSSEC with BIND 9.16
Hello and thank you for the reply. I can confirm my current dns servers have already EPEL repo enabled and jemalloc package is available. I'll setup my test machine accordingly to be able to install BIND 9.18. Will it also provide named-chroot (is it really necessary?) Thanks! David -Original Message- From: Anand Buddhdev Sent: 13 April 2023 16:48 To: David Carvalho Cc: 'Bind Users Mailing List' Subject: Re: Fully automated DNSSEC with BIND 9.16 On 13/04/2023 17:17, David Carvalho via bind-users wrote: Hi David, > Hello and thanks for the reply. > I enabled this repo in Oracle Linux 8 with: dnf copr enable isc/bind > > Then I tried to install (dnf install isc-bind) but I got: > Error: > Problem: package isc-bind-1:2-3.el8.x86_64 requires isc-bind-bind, but none > of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libbind9-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libdns-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libisc-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libisccc-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libisccfg-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libns-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires isc-bind-bind-libs > = 9.18.13, but none of the providers can be installed >- conflicting requests >- nothing provides libjemalloc.so.2()(64bit) needed by > isc-bind-bind-libs-9.18.13-1.1.el8.x86_64 > (try to add '--skip-broken' to skip uninstallable packages or > '--nobest' to use not only best candidate packages) BIND 9.18 and newer require jemalloc, but this package isn't part of Redhat base. You also need to enable the EPEL repository for this. With Oracle Linux, there are 2 different EPELs available. Oracle's own rebuild of EPEL packages, and the Fedora EPEL. My personal preference is the Fedora EPEL repo, which you can install with: dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm Then you should be able to install the ISC BIND packages. Regards, Anand -- 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: Fully automated DNSSEC with BIND 9.16
Hello and thanks for the reply. I enabled this repo in Oracle Linux 8 with: dnf copr enable isc/bind Then I tried to install (dnf install isc-bind) but I got: Error: Problem: package isc-bind-1:2-3.el8.x86_64 requires isc-bind-bind, but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libbind9-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libdns-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisc-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisccc-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisccfg-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libns-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires isc-bind-bind-libs = 9.18.13, but none of the providers can be installed - conflicting requests - nothing provides libjemalloc.so.2()(64bit) needed by isc-bind-bind-libs-9.18.13-1.1.el8.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) This is the main reason I usually stick with provided packages. Kind regards David -Original Message- From: Ondřej Surý Sent: 13 April 2023 14:40 To: David Carvalho Cc: Bind Users Mailing List Subject: Re: Fully automated DNSSEC with BIND 9.16 > On 13. 4. 2023, at 15:25, David Carvalho via bind-users > wrote: > > I'm using 9.16.23 Just don't. ISC provides packages for major linux distributions (https://www.isc.org/download/), so there's really no reason to shoot yourself into foot to use a random BIND 9 snapshot provided by your distro. And while you are at it - upgrade straight to latest 9.18, your experience will be much smoother. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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: Fully automated DNSSEC with BIND 9.16
Hello. Both content and timestamps. I've been told previously here that there is a bug prior to version 9.16.30. I'm using 9.16.23, no update available yet. No, not removing Regards David -Original Message- From: bind-users On Behalf Of Jan-Piet Mens Sent: 13 April 2023 11:12 To: bind-users@lists.isc.org Subject: Re: Fully automated DNSSEC with BIND 9.16 >1. Everytime I restart the service, it seems all these files are recreated. How did you observe this? Just by file timestamps or actual content? And just to be sure to ask the obvious: you are not manually removing these files are you? :) -JP -- 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 -- 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: dnssec-validation?
Hello again. Problem number 1: Dnssec seems to be running on "di.ubi.pt", but dnssec-validation still needs to be set to no; Will this cause troubles? Dns2 is set to auto and runs fine. Problem number 2: How can I avoid the key regeneration (using version 9.16.23) every named restart? Kind regards, David Carvalho -Original Message- From: Evan Hunt Sent: 12 April 2023 18:08 To: David Carvalho Cc: bind-users@lists.isc.org Subject: Re: dnssec-validation? On Wed, Apr 12, 2023 at 05:41:33PM +0100, David Carvalho via bind-users wrote: > After reverting my primary dns configuration, and asking my provider > to remove the DNSKEY, I had to include dnssec-validation no; otherwise > it would keep answering with SERVFAIL > > I noticed the server was constantly trying to reach top domain dns servers. > > Is this dnssec-validation mandatory? Any help appreciated. dnssec-validation can be set three ways: - "no" (validation is never performed) - "yes" (validation *may* be performed, but only if you have also configured a trust anchor in named.conf) - "auto" (validation will be performed using the standard root zone trust anchor, which is built in to BIND and doesn't need to be configured by hand). The default is "auto". When it's set to that, your server will query the root name servers in order to confirm that the automatically-configured trust anchor is correct. You said it was "trying to" reach the root, which suggests it wasn't succeeding? If so, that would explain why everything that wasn't locally authoritative would return SERVFAIL. Note that this is related to *recursive* queries, that is, queries for zones that are not served by your secondary server. It should have nothing to do with whether your own domain is signed, or whether there's a DS record for it in the parent zone. My guess is, you had the authoritative configuration working fine (otherwise presumably dnssec-analyzer would've complained), but recursive isn't working. Unfortunately, since you haven't provided any configuration info or even the name of the domain you were trying to set up, I can't make any more educated guesses than that. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- 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: dnssec-validation?
Hello and thank you for the reply. My domain is "di.ubi.pt". The parent domain "ubi.pt" recently configured DNSSEC (BIND 9.11) so it was time again for me to try to set it up for my domain. A few months ago I updated both dns servers to Oracle Linux 8, running BIND 9.16.23 to prepare for this. They seem to be working fine as previously, running as both recursive and authoritative for di.ubi.pt. DNS2 has still "dnssec-validation auto;" on its /etc/named.conf. I've found out that if I wanted my primary server to start answering my internal requests for outside "di.ubi.pt" I had to change dnssec-validation to "no". I still don't understand why, to be honest. Yesterday I set dnssec-validation to auto on my primary server, but as I wrote before, although outside tools showed everything was fine, my server kept answering "SERVFAIL" to my client queries. I don't think I tested dnssec-validation to no when dnssec was enabled, nor if this makes much sense, but I can try. Kind regards David On Wed, Apr 12, 2023 at 05:41:33PM +0100, David Carvalho via bind-users wrote: > After reverting my primary dns configuration, and asking my provider > to remove the DNSKEY, I had to include dnssec-validation no; otherwise > it would keep answering with SERVFAIL > > I noticed the server was constantly trying to reach top domain dns servers. > > Is this dnssec-validation mandatory? Any help appreciated. dnssec-validation can be set three ways: - "no" (validation is never performed) - "yes" (validation *may* be performed, but only if you have also configured a trust anchor in named.conf) - "auto" (validation will be performed using the standard root zone trust anchor, which is built in to BIND and doesn't need to be configured by hand). The default is "auto". When it's set to that, your server will query the root name servers in order to confirm that the automatically-configured trust anchor is correct. You said it was "trying to" reach the root, which suggests it wasn't succeeding? If so, that would explain why everything that wasn't locally authoritative would return SERVFAIL. Note that this is related to *recursive* queries, that is, queries for zones that are not served by your secondary server. It should have nothing to do with whether your own domain is signed, or whether there's a DS record for it in the parent zone. My guess is, you had the authoritative configuration working fine (otherwise presumably dnssec-analyzer would've complained), but recursive isn't working. Unfortunately, since you haven't provided any configuration info or even the name of the domain you were trying to set up, I can't make any more educated guesses than that. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- 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
dnssec-validation?
Hello, again. Guys, sorry once again, but my dnssec implementation didn't work out. Using 9.16.23 (I have that problem of keys being regenerated every restart, but I'll learn to sign the zone later using the original key- Bug solved in version 9.16.30). After providing my DNSKEY record to parent domain, the test performed by dnssec-analyzer showed everything ok, nevertheless, all queries except those about my.domain were Rejected with SERVFAIL. dig @my.server or dig @localhost My secondary dns server hold everything while testing, and I noticed I had dnssec-validation auto; on it. After reverting my primary dns configuration, and asking my provider to remove the DNSKEY, I had to include dnssec-validation no; otherwise it would keep answering with SERVFAIL I noticed the server was constantly trying to reach top domain dns servers. Is this dnssec-validation mandatory? Any help appreciated. Regards David -- 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: Fully automated DNSSEC with BIND 9.16
Thank you so much! Regards David -Original Message- From: bind-users On Behalf Of Matthijs Mekking Sent: 11 April 2023 13:03 To: bind-users@lists.isc.org Subject: Re: Fully automated DNSSEC with BIND 9.16 On 4/11/23 13:14, David Carvalho wrote: > Hello and thank you so much for your help. Regarding question 1, My > version is 9.16-9.1623-0.9.el8...so I got the bug. No update available > from Oracle Linux yet, so I'll create a folder and maintain a copy of > those files there. > > In which situation should I be required to resend my key to the top > domain? I'll have to read more about ZSK, KSK and CSK rollovers. All > of this is new to me so far. I think it would be useful to read this knowledge base article if all is new to you: https://kb.isc.org/v1/docs/en/dnssec-key-and-signing-policy Basically in the following two scenarios you need to publish the public key to the parent domain: 1. Enabling DNSSEC 2. KSK rollover With the default policy, KSK rollover is not scheduled, so only after you manually roll the key you need to publish (and withdraw) the DS records from the parent. When exactly? You can check with 'rndc dnssec -status '. If the DS state is rumoured it is safe to submit the DS to the parent. Best regards, Matthijs > > Thanks! David Carvalho > > > > -Original Message- From: bind-users > On Behalf Of Matthijs Mekking > Sent: 11 April 2023 11:16 To: bind-users@lists.isc.org Subject: Re: > Fully automated DNSSEC with BIND 9.16 > > Hello David, > > On 4/11/23 12:02, David Carvalho via bind-users wrote: >> Hello, hope everyone is fine. >> >> So it seems that going to Bind version 9.16 was the right call as it >> simplifies DNSSEC a lot. >> >> Nevertheless, I would like to clarify some things because our >> organization has a parent domain and I host my own e-mail servers. >> I know they had problems while implementing DNSSEC on the top domain, >> and some configurations had to be made to let subdomain e-mail >> servers to still work after DNSSEC. >> >> Following RedHat tutorial, all I had to do was add “*dnssec-policy >> default;”* into one of my zones for testing purposes. I’m not testing >> Reverse zones yet. >> >> After this, 3 files “Kmy.domain***” were created: >> >> “.key” >> >> “.private” >> >> “.state”. >> >> Three files regarding my zone were also created: >> >> My.domain.signed >> >> And the following 2, which I’m not sure what their purpose is >> >> *My.domain*.*jbk* and*my.domain.signed.jnl* > > The .jnl files are journal files and are created when a zone uses > dynamic update to store changes that are made to zone files. > > The .jbk files are truly temporary files and should be removed again > when writing the contents of the zone to file. > >> There are also “managed-keys.bind” and “managed-keys.bind.jnl” > > These are trust anchor files, and store the state of those keys. > These will be updated on a restart. > >> >> My questions: >> >> 1. Everytime I restart the service, it seems all these files are >> recreated. Does this mean that every time I make a change in the >> host zone, I need resend the public key to my top domain? > > No, the key files (.key, .private, .state) should also not be > recreated upon restart (a bug that would recreate key files every > keymgr run was fixed in 9.16.30). > > >> 2. Do Parental Agents help with this? > > Not in this case, because there is no need to send the public key to > the parent domain. Parental agents only help to automatically detect > if the corresponding DS has been published. > > Without parental agents configured you need to use 'rndc dnssec > -checkds' to tell BIND that a certain DS has been published/withdrawn > in order to continue key rollover. > > >> 3. Which format should I use when providing the key to the top level >> domain? >> >> * dnssec-dsfromkey >> /var/named/K/example.com.+013+61141/.key* >> >> or >> >> * grep DNSKEY /var/named/K*/*example.com.+013+61141.key*/ > > I assume you are submitting the public key to your registrar and it > depends on what format your registrar accepts. > > > Best regards, > > Matthijs > -- 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 -- 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: Fully automated DNSSEC with BIND 9.16
Hello and thank you so much for your help. Regarding question 1, My version is 9.16-9.1623-0.9.el8...so I got the bug. No update available from Oracle Linux yet, so I'll create a folder and maintain a copy of those files there. In which situation should I be required to resend my key to the top domain? I'll have to read more about ZSK, KSK and CSK rollovers. All of this is new to me so far. Thanks! David Carvalho -Original Message- From: bind-users On Behalf Of Matthijs Mekking Sent: 11 April 2023 11:16 To: bind-users@lists.isc.org Subject: Re: Fully automated DNSSEC with BIND 9.16 Hello David, On 4/11/23 12:02, David Carvalho via bind-users wrote: > Hello, hope everyone is fine. > > So it seems that going to Bind version 9.16 was the right call as it > simplifies DNSSEC a lot. > > Nevertheless, I would like to clarify some things because our > organization has a parent domain and I host my own e-mail servers. I > know they had problems while implementing DNSSEC on the top domain, > and some configurations had to be made to let subdomain e-mail servers > to still work after DNSSEC. > > Following RedHat tutorial, all I had to do was add “*dnssec-policy > default;”* into one of my zones for testing purposes. I’m not testing > Reverse zones yet. > > After this, 3 files “Kmy.domain***” were created: > > “.key” > > “.private” > > “.state”. > > Three files regarding my zone were also created: > > My.domain.signed > > And the following 2, which I’m not sure what their purpose is > > *My.domain*.*jbk* and*my.domain.signed.jnl* The .jnl files are journal files and are created when a zone uses dynamic update to store changes that are made to zone files. The .jbk files are truly temporary files and should be removed again when writing the contents of the zone to file. > There are also “managed-keys.bind” and “managed-keys.bind.jnl” These are trust anchor files, and store the state of those keys. These will be updated on a restart. > > My questions: > > 1. Everytime I restart the service, it seems all these files are > recreated. Does this mean that every time I make a change in the > host zone, I need resend the public key to my top domain? No, the key files (.key, .private, .state) should also not be recreated upon restart (a bug that would recreate key files every keymgr run was fixed in 9.16.30). > 2. Do Parental Agents help with this? Not in this case, because there is no need to send the public key to the parent domain. Parental agents only help to automatically detect if the corresponding DS has been published. Without parental agents configured you need to use 'rndc dnssec -checkds' to tell BIND that a certain DS has been published/withdrawn in order to continue key rollover. > 3. Which format should I use when providing the key to the top level > domain? > > * dnssec-dsfromkey /var/named/K/example.com.+013+61141/.key* > > or > > * grep DNSKEY /var/named/K*/*example.com.+013+61141.key*/ I assume you are submitting the public key to your registrar and it depends on what format your registrar accepts. Best regards, Matthijs -- 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 -- 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
Fully automated DNSSEC with BIND 9.16
Hello, hope everyone is fine. So it seems that going to Bind version 9.16 was the right call as it simplifies DNSSEC a lot. Nevertheless, I would like to clarify some things because our organization has a parent domain and I host my own e-mail servers. I know they had problems while implementing DNSSEC on the top domain, and some configurations had to be made to let subdomain e-mail servers to still work after DNSSEC. Following RedHat tutorial, all I had to do was add "dnssec-policy default;" into one of my zones for testing purposes. I'm not testing Reverse zones yet. After this, 3 files "Kmy.domain***" were created: ".key" ".private" ".state". Three files regarding my zone were also created: My.domain.signed And the following 2, which I'm not sure what their purpose is My.domain.jbk and my.domain.signed.jnl There are also "managed-keys.bind" and "managed-keys.bind.jnl" My questions: 1. Everytime I restart the service, it seems all these files are recreated. Does this mean that every time I make a change in the host zone, I need resend the public key to my top domain? 2. Do Parental Agents help with this? 3. Which format should I use when providing the key to the top level domain? dnssec-dsfromkey /var/named/Kexample.com.+013+61141.key or grep DNSKEY /var/named/Kexample.com.+013+61141.key Kind regards David Carvalho -- 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: dnssec-keygen not available in Bind9.16-utils package?
Hi. Thanks for the reply. Very useful information! Kind regards David Carvalho From: Jiaming Zhang Sent: 24 March 2023 12:33 To: David Carvalho ; 'Petr Menšík' ; bind-users@lists.isc.org Subject: Re: dnssec-keygen not available in Bind9.16-utils package? Hello David, I have Oracle Linux 8 instance running bind 9.11.x as well bind 9.16.x and confirm that there’s no dnssec-* utilities in the bind9.16-utils. Although the 9.11 and 9.16 version cannot coexist, you can insead installing the bind9.16-utils install bind-utils. It works still perfect on the instance I ran bind9.16. Currently on this instance I have both version of bind-libs and version 9.11.x of bind-utils working together with bind9.16. Regards, Jiaming Zhang Yixi Meta Email: j.zh...@yiximeta.com <mailto:j.zh...@yiximeta.com> Website: yiximeta.com _ Van: bind-users mailto:bind-users-boun...@lists.isc.org> > namens David Carvalho via bind-users mailto:bind-users@lists.isc.org> > Verzonden: Friday, March 24, 2023 10:22:45 AM Aan: 'Petr Menšík' mailto:pemen...@redhat.com> >; bind-users@lists.isc.org <mailto:bind-users@lists.isc.org> mailto:bind-users@lists.isc.org> > Onderwerp: RE: dnssec-keygen not available in Bind9.16-utils package? Thank you so much for your help. Unfortunately it seems bind-utils 9.11 and 9.16 can not co-exist (at least in Oracle Linux 8). I had problems with dependencies and didn’t force anything until having more information. Thanks once again! Regards David Carvalho From: bind-users mailto:bind-users-boun...@lists.isc.org> > On Behalf Of Petr Menšík Sent: 24 March 2023 01:09 To: bind-users@lists.isc.org <mailto:bind-users@lists.isc.org> Subject: Re: dnssec-keygen not available in Bind9.16-utils package? Oh, correction. Those were published, but in wrong repository. If you enable CodeReady Builder (CRB) repository, you should be able to install it even with current version. Not sure what is official name on Oracle Linux, use "dnf repolist --all" command to find the name. They are called powertools on CentOS Stream 8. On RHEL 8 enable it by command: subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms On 3/24/23 01:43, Petr Menšík wrote: dnssec utilities are in bind9.16-dnssec-utils, which by mistake stayed internal only package. We have built them, but not published them. It would be moved into public repository once RHEL 8.8.0 is released, tracked under bug #2115322 [1]. It should be already available in CentOS Stream 8. I am sorry for the inconvenience, this issue were missed during our testing. It should be possible to install bind-utils from bind 9.11 together with bind9.16 server until that is fixed. Unless you depend on more recent features in bind9.16-utils, it might help in the mean time. Regards, Petr 1. https://bugzilla.redhat.com/show_bug.cgi?id=2115322 On 3/20/23 13:31, David Carvalho via bind-users wrote: Hello, good morning. I’m trying to setup DNNSEC and I’ve been using Bind9.16 packages available in Oracle Linux 8. Somehow there are also “Bind” packages, which default to 9.11 version. Being a new installation I went for 9.16. The problem now is that dnssec-keygen seems to be only available in version 9.11, and if I try to install I get problems with dependencies . Does anyone have some experience with this? Kind regards David -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- 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: dnssec-keygen not available in Bind9.16-utils package?
Brilliant! Thank you so much! Regards David From: Petr Menšík Sent: 24 March 2023 11:05 To: David Carvalho ; bind-users@lists.isc.org Subject: Re: dnssec-keygen not available in Bind9.16-utils package? I have tried it on fresh RHEL 8.7.0, which should be similar to what you get on Oracle Linux 8. Just already released RHEL. $ dnf install bind9.16 -y # installs also recommended bind9.16-utils. $ dnf swap bind9.16-utils bind-utils Replaces successfully only utilities with older version $ rpm -q bind9.16 bind-utils bind9.16-9.16.23-0.9.el8.1.x86_64 bind-utils-9.11.36-5.el8_7.2.x86_64 Result is the new named.service with older utilities. It should not conflict this way, but have to use dnf swap. I have made sure both bind-libs and bind9.16-libs can be installed at the same time. This is a result of that. But installing new bind9.16-dnssec-utils from CRB repository is still a preferred method. I am quite confident Oracle does not modify my work done on bind, they just rebuild SRPM. On 3/24/23 10:22, David Carvalho wrote: Thank you so much for your help. Unfortunately it seems bind-utils 9.11 and 9.16 can not co-exist (at least in Oracle Linux 8). I had problems with dependencies and didn’t force anything until having more information. Thanks once again! Regards David Carvalho From: bind-users <mailto:bind-users-boun...@lists.isc.org> On Behalf Of Petr Menšík Sent: 24 March 2023 01:09 To: bind-users@lists.isc.org <mailto:bind-users@lists.isc.org> Subject: Re: dnssec-keygen not available in Bind9.16-utils package? Oh, correction. Those were published, but in wrong repository. If you enable CodeReady Builder (CRB) repository, you should be able to install it even with current version. Not sure what is official name on Oracle Linux, use "dnf repolist --all" command to find the name. They are called powertools on CentOS Stream 8. On RHEL 8 enable it by command: subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms On 3/24/23 01:43, Petr Menšík wrote: dnssec utilities are in bind9.16-dnssec-utils, which by mistake stayed internal only package. We have built them, but not published them. It would be moved into public repository once RHEL 8.8.0 is released, tracked under bug #2115322 [1]. It should be already available in CentOS Stream 8. I am sorry for the inconvenience, this issue were missed during our testing. It should be possible to install bind-utils from bind 9.11 together with bind9.16 server until that is fixed. Unless you depend on more recent features in bind9.16-utils, it might help in the mean time. Regards, Petr 1. https://bugzilla.redhat.com/show_bug.cgi?id=2115322 On 3/20/23 13:31, David Carvalho via bind-users wrote: Hello, good morning. I’m trying to setup DNNSEC and I’ve been using Bind9.16 packages available in Oracle Linux 8. Somehow there are also “Bind” packages, which default to 9.11 version. Being a new installation I went for 9.16. The problem now is that dnssec-keygen seems to be only available in version 9.11, and if I try to install I get problems with dependencies . Does anyone have some experience with this? Kind regards David -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- 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: dnssec-keygen not available in Bind9.16-utils package?
Thank you so much for your help. Unfortunately it seems bind-utils 9.11 and 9.16 can not co-exist (at least in Oracle Linux 8). I had problems with dependencies and didn’t force anything until having more information. Thanks once again! Regards David Carvalho From: bind-users On Behalf Of Petr Menšík Sent: 24 March 2023 01:09 To: bind-users@lists.isc.org Subject: Re: dnssec-keygen not available in Bind9.16-utils package? Oh, correction. Those were published, but in wrong repository. If you enable CodeReady Builder (CRB) repository, you should be able to install it even with current version. Not sure what is official name on Oracle Linux, use "dnf repolist --all" command to find the name. They are called powertools on CentOS Stream 8. On RHEL 8 enable it by command: subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms On 3/24/23 01:43, Petr Menšík wrote: dnssec utilities are in bind9.16-dnssec-utils, which by mistake stayed internal only package. We have built them, but not published them. It would be moved into public repository once RHEL 8.8.0 is released, tracked under bug #2115322 [1]. It should be already available in CentOS Stream 8. I am sorry for the inconvenience, this issue were missed during our testing. It should be possible to install bind-utils from bind 9.11 together with bind9.16 server until that is fixed. Unless you depend on more recent features in bind9.16-utils, it might help in the mean time. Regards, Petr 1. https://bugzilla.redhat.com/show_bug.cgi?id=2115322 On 3/20/23 13:31, David Carvalho via bind-users wrote: Hello, good morning. I’m trying to setup DNNSEC and I’ve been using Bind9.16 packages available in Oracle Linux 8. Somehow there are also “Bind” packages, which default to 9.11 version. Being a new installation I went for 9.16. The problem now is that dnssec-keygen seems to be only available in version 9.11, and if I try to install I get problems with dependencies . Does anyone have some experience with this? Kind regards David -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- 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
FW: dnssec-keygen not available in Bind9.16-utils package?
Thanks gor the reply. I am able to find bind9.16-dnssec-utils in CentOS repository, but have not installed it yet. I'm trying to find out more information about why this package is not available, unlike the other for version 9.11. Had you any dependencies problems or it was straight forward? Thanks. Os melhores cumprimentos David Alexandre M. de Carvalho ═══ Especialista de Informática Departamento de Informática Universidade da Beira Interior -Original Message- From: bind-users On Behalf Of Jan-Piet Mens Sent: 20 March 2023 18:12 To: bind-users@lists.isc.org Subject: Re: dnssec-keygen not available in Bind9.16-utils package? Have you checked whether there is a bind.*dnssec-utils package? I stumbled across this with a RHEL-type Linux recently... -JP -- 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 -- 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
dnssec-keygen not available in Bind9.16-utils package?
Hello, good morning. I'm trying to setup DNNSEC and I've been using Bind9.16 packages available in Oracle Linux 8. Somehow there are also "Bind" packages, which default to 9.11 version. Being a new installation I went for 9.16. The problem now is that dnssec-keygen seems to be only available in version 9.11, and if I try to install I get problems with dependencies . Does anyone have some experience with this? Kind regards David -- 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: recursion yes/no?
It helps a lot!! I think I understand now. Have a great day! Regards David From: Greg Choules Sent: 25 January 2023 10:34 To: David Carvalho Cc: bind-users@lists.isc.org Subject: Re: recursion yes/no? Hi David. With "minimal-responses", usually I would set it to "no" for a purely authoritative server because resolvers need all the help they can get. But for a purely recursive server I would set it to "yes" because end users don't need (any wouldn't do anything with it anyway) Authority or Additional data. So a hybrid server is a bit stuck between those two settings. However, from 9.16 BIND now has extra choices (as Evan pointed out). To answer your follow up question I would stick with "no-auth-recursive" as this is exactly the scenario it is designed for. "dig" (by default, like all stub clients) will make recursive queries; i.e. RD=1. If your server has "minimal-responses no-auth-recursive;" set (or nothing at all since that's the default) then a vanilla query from dig will *not* receive anything it doesn't need to, just like real users. If you *want* to see all the Authority and Additional data then add "+norecurse" to your dig command, which causes it to set RD=0. Your server is then not being asked to do recursion, so it will just reply with everything (if anything) it has. Hope that helps. Greg On Wed, 25 Jan 2023 at 10:16, David Carvalho mailto:da...@di.ubi.pt> > wrote: Good morning and thank you so much! Now I understand. My servers are not pure authoritative, so I’ll have to keep the recursion enabled. As for the answers in Authority and Additional sections, after setting minimal-responses to no, now I get the usual output when querying. For what I understand, there is no downside in maintaining this setting, right? Thank you! Kind regards. David From: Greg Choules mailto:gregchoules%2bbindus...@googlemail.com> > Sent: 24 January 2023 18:12 To: David Carvalho mailto:da...@di.ubi.pt> > Cc: bind-users@lists.isc.org <mailto:bind-users@lists.isc.org> Subject: Re: recursion yes/no? Hi David. "recursion yes;" tells named that it can (if it has to) make queries to other places if it needs more information in order to answer a client query. Pure authoritative servers shouldn't need it and should have "recursion no;". So the first question is, do your servers make queries out to other places? If so, recursion must be enabled. Secondly, do you have "minimal-responses" configured on either/both servers? If so, what is it set to? There were changes in 9.16 so maybe these explain your observations. Cheers, Greg On Tue, 24 Jan 2023 at 16:49, David Carvalho via bind-users mailto:bind-users@lists.isc.org> > wrote: Hello. I hope someone could help to understand the following. I have “my.domain.pt <http://my.domain.pt> ” and a master and slave server for the “my” part. I have been using “recursion yes” in both named.conf, as I want them to be both authoritative and cache for my clients. Last week I migrated my slave DNS server to version 9.16 and only today, after having issues with the primary server migration, I realized that for most queries, my slave DNS does not answer the “ADDITIONAL SECTION” unless I specify “+norec” with the dig command. My named.conf files only differ in IPs and “master/slave” setting. My questions: Should I use recursion on both? (Bear in mind that I also want them to provide chache to clients) Why do I need “dig +norec” to get the exact output on my slave server? Kind regards David -- 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 <mailto:bind-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/bind-users -- 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: recursion yes/no?
Hello and thank you so much. " no-auth-recursive is meant for use in mixed-mode servers that handle both authoritative and recursive queries" - So I guess the default setting is intended for my purpose. Will there be any inconvenient setting minimal-responses to no? Having that default behaviour when using "dig" can be useful. Thank you! Kind regards. David Os melhores cumprimentos David Alexandre M. de Carvalho ═══ Especialista de Informática Departamento de Informática Universidade da Beira Interior -Original Message- From: Evan Hunt Sent: 24 January 2023 20:12 To: David Carvalho Cc: bind-users@lists.isc.org Subject: Re: recursion yes/no? On Tue, Jan 24, 2023 at 04:48:34PM -0000, David Carvalho via bind-users wrote: > Hello. > > I hope someone could help to understand the following. > > I have "my.domain.pt" and a master and slave server for the "my" part. > I have been using "recursion yes" in both named.conf, as I want them > to be both authoritative and cache for my clients. > > Last week I migrated my slave DNS server to version 9.16 and only > today, after having issues with the primary server migration, I > realized that for most queries, my slave DNS does not answer the > "ADDITIONAL SECTION" unless I specify "+norec" with the dig command. You didn't mention what version you were upgrading from, but I guess 9.11, because the default setting of "minimal-responses" was changed in 9.12. It used to default to "no", but it now defaults to "no-auth-recursive". From the ARM: minimal-responses takes one of four values: - no: the server is as complete as possible when generating responses. - yes: the server only adds records to the authority and additional sections when such records are required by the DNS protocol (for example, when returning delegations or negative responses). This provides the best server performance but may result in more client queries. - no-auth: the server omits records from the authority section except when they are required, but it may still add records to the additional section. - no-auth-recursive: the same as no-auth when recursion is requested in the query (RD=1), or the same as no if recursion is not requested. no-auth and no-auth-recursive are useful when answering stub clients, which usually ignore the authority section. no-auth-recursive is meant for use in mixed-mode servers that handle both authoritative and recursive queries. So when recursion is requested in the query, the server omits the NS records from the authority section, and if there's no NS records then there won't need to be corresponding A or records in the additional section. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- 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: recursion yes/no?
Good morning and thank you so much! Now I understand. My servers are not pure authoritative, so I’ll have to keep the recursion enabled. As for the answers in Authority and Additional sections, after setting minimal-responses to no, now I get the usual output when querying. For what I understand, there is no downside in maintaining this setting, right? Thank you! Kind regards. David From: Greg Choules Sent: 24 January 2023 18:12 To: David Carvalho Cc: bind-users@lists.isc.org Subject: Re: recursion yes/no? Hi David. "recursion yes;" tells named that it can (if it has to) make queries to other places if it needs more information in order to answer a client query. Pure authoritative servers shouldn't need it and should have "recursion no;". So the first question is, do your servers make queries out to other places? If so, recursion must be enabled. Secondly, do you have "minimal-responses" configured on either/both servers? If so, what is it set to? There were changes in 9.16 so maybe these explain your observations. Cheers, Greg On Tue, 24 Jan 2023 at 16:49, David Carvalho via bind-users mailto:bind-users@lists.isc.org> > wrote: Hello. I hope someone could help to understand the following. I have “my.domain.pt <http://my.domain.pt> ” and a master and slave server for the “my” part. I have been using “recursion yes” in both named.conf, as I want them to be both authoritative and cache for my clients. Last week I migrated my slave DNS server to version 9.16 and only today, after having issues with the primary server migration, I realized that for most queries, my slave DNS does not answer the “ADDITIONAL SECTION” unless I specify “+norec” with the dig command. My named.conf files only differ in IPs and “master/slave” setting. My questions: Should I use recursion on both? (Bear in mind that I also want them to provide chache to clients) Why do I need “dig +norec” to get the exact output on my slave server? Kind regards David -- 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 <mailto:bind-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/bind-users -- 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
recursion yes/no?
Hello. I hope someone could help to understand the following. I have "my.domain.pt" and a master and slave server for the "my" part. I have been using "recursion yes" in both named.conf, as I want them to be both authoritative and cache for my clients. Last week I migrated my slave DNS server to version 9.16 and only today, after having issues with the primary server migration, I realized that for most queries, my slave DNS does not answer the "ADDITIONAL SECTION" unless I specify "+norec" with the dig command. My named.conf files only differ in IPs and "master/slave" setting. My questions: Should I use recursion on both? (Bear in mind that I also want them to provide chache to clients) Why do I need "dig +norec" to get the exact output on my slave server? Kind regards David -- 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 not query localhost
Hi. It was not oracle linux 9.16 but Bind 9.16. The problem seemed to be about broken dnssec validation, that's why commenting those entries solved. For now I'm not using dnssec, I will have to read about key rotation. If that is still a very manual process, I'll have to be quite confident before I mess with my servers. Thanks. David -Original Message- From: Mark Andrews Sent: 13 January 2023 22:48 To: David Carvalho Cc: bind-users@lists.isc.org Subject: Re: Can not query localhost Now you went from Oracle Linux 6 to Oracle linux 9.16 (b.t.w. no one keeps track of which BIND version ships which which random Linux distro, it is much better to report the BIND versions as well). In that time there has been a lot of change. Did you copy over just the local configuration changes or did you copy over everything? By local configuration changes I mean just the zone you added and any acls. Distros expect you to put local changes in isolated files so they can update defaults configurations without overwriting local config. Copying everything means that you are missing all those changes. > On 14 Jan 2023, at 03:48, David Carvalho via bind-users > wrote: > > > Ok, so apparently everything seems to be running fine. > > > I am not using dnsssec (dnssec-validation is auto ?!) and > "dnssec-enable yes" was considered obsolete by named-checkconfg, so it is > also commented. > I had to comment > > bindkeys-file "/etc/named.iscdlv.key"; Well what was in "/etc/named.iscdlv.key” ? I suspect it was grossly out of date. Anything that mentions DLV is out of date as that has been shutdown for years and is just returning a response that says there is no content here anymore. Also the Root’s DNSSEC keys rolled in 2017 and if it hasn’t been updated since before then the key is out of date. There should be nothing in there but public keys which are safe to publish. Commenting it out meant that you are now using the built in trust anchors. Defaults for DNSSEC have changed over time (validation is on by default) and using out of date trust anchors with newer versions of BIND will cause DNSSEC validation failures. > managed-keys-directory "/var/named/dynamic"; > > and everything worked. Still don't understand exactly why, I will > continue to investigate, but any feedback is welcome. Named logs why thing fail. Examine the logs. > Thanks > Regards > David > > > > -Original Message- > From: bind-users On Behalf Of David > Carvalho via bind-users > Sent: 13 January 2023 14:11 > To: 'Marco' ; bind-users@lists.isc.org > Subject: RE: Can not query localhost > > Thanks for the reply. > Yes > > ACL active. Exact same configuration as in old server named.conf, with > a different listening IP, of course, which belongs to my LAN ACL. > > Performing "dig @localhost any my.domain" works perfectly. If querying > just "dig @localhost" or "dig @my.ip", tcpdump shows it trying to > connect to top level IPs And I keep getting SERVFAIL. > > > Regards. > David > > > -----Original Message- > From: Marco > Sent: 13 January 2023 11:33 > To: bind-users@lists.isc.org > Cc: David Carvalho > Subject: Re: Can not query localhost > > Am 13.01.2023 schrieb David Carvalho via bind-users > : > >> I get SERVFAIL when querying outside my domain. > > Have you enabled an ACL that allows any IP address to query your > public zones? > > You can only restrict recursive requests to your own IP addresses. > > -- > 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 > > -- > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- 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 not query localhost
Ok, so apparently everything seems to be running fine. I am not using dnsssec (dnssec-validation is auto ?!) and "dnssec-enable yes" was considered obsolete by named-checkconfg, so it is also commented. I had to comment bindkeys-file "/etc/named.iscdlv.key"; managed-keys-directory "/var/named/dynamic"; and everything worked. Still don't understand exactly why, I will continue to investigate, but any feedback is welcome. Thanks Regards David -Original Message- From: bind-users On Behalf Of David Carvalho via bind-users Sent: 13 January 2023 14:11 To: 'Marco' ; bind-users@lists.isc.org Subject: RE: Can not query localhost Thanks for the reply. Yes ACL active. Exact same configuration as in old server named.conf, with a different listening IP, of course, which belongs to my LAN ACL. Performing "dig @localhost any my.domain" works perfectly. If querying just "dig @localhost" or "dig @my.ip", tcpdump shows it trying to connect to top level IPs And I keep getting SERVFAIL. Regards. David -Original Message- From: Marco Sent: 13 January 2023 11:33 To: bind-users@lists.isc.org Cc: David Carvalho Subject: Re: Can not query localhost Am 13.01.2023 schrieb David Carvalho via bind-users : > I get SERVFAIL when querying outside my domain. Have you enabled an ACL that allows any IP address to query your public zones? You can only restrict recursive requests to your own IP addresses. -- 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 -- 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 not query localhost
Thanks for the reply. Yes ACL active. Exact same configuration as in old server named.conf, with a different listening IP, of course, which belongs to my LAN ACL. Performing "dig @localhost any my.domain" works perfectly. If querying just "dig @localhost" or "dig @my.ip", tcpdump shows it trying to connect to top level IPs And I keep getting SERVFAIL. Regards. David -Original Message- From: Marco Sent: 13 January 2023 11:33 To: bind-users@lists.isc.org Cc: David Carvalho Subject: Re: Can not query localhost Am 13.01.2023 schrieb David Carvalho via bind-users : > I get SERVFAIL when querying outside my domain. Have you enabled an ACL that allows any IP address to query your public zones? You can only restrict recursive requests to your own IP addresses. -- 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
Can not query localhost
Hi.
I’m migrating an old bind from Oracle Linux 6 to Oracle linux 9.16.
The first thing I noticed was that there were 2 bind versions available in this
new distro. I went for the newest.
It is “named-chroot” and a “slave” configuration for my domain. The files are
already being transferred automatically daily, and I can successfully query my
domain.
The problems are:
I get SERVFAIL when querying outside my domain.
I get SERVFAIL when performing any reverse query.
I can use “nc -v 53 top.domain.server” to test my outgoing connection, and it
works.
My named.conf is as follows
listen-on port 53 { 127.0.0.1; my.ip.; };
listen-on-v6 port 53 { ::1; };
The configuration is as in the previous server, so I have no idea what I am
missing.
Any ideas?
regards
David
--
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: Reverse lookups not working when Internet connection failed.
Hello again. Finally had the opportunity to get back to this. Having internet connection restored, everything seems to be working as supposed to. One simple query from my client and one response from my server. Output from wireshark: 1 0.0010.0.0.199 193.136.66.1DNS 85 Standard query 0x000b PTR 8.66.136.193.in-addr.arpa 2 0.016660193.136.66.110.0.0.199 DNS 204 Standard query response 0x000b PTR 8.66.136.193.in-addr.arpa CNAME 8.0-28.66.136.193.in-addr.arpa PTR meteo.di.ubi.pt NS dns.di.ubi.pt NS dns2.di.ubi.pt A 193.136.66.1 A 193.136.66.2 Just 2 packets. But on the command line I get the following, and I'm confused why the "non-authoritive answer": Nslookup Set stype=ptr > 193.136.66.8 Server: dns.di.ubi.pt Address: 193.136.66.1 Aliases: 1.66.136.193.in-addr.arpa Non-authoritative answer: ---here!??? 8.66.136.193.in-addr.arpa canonical name = 8.0-28.66.136.193.in-addr.arpa 8.0-28.66.136.193.in-addr.arpa name = meteo.di.ubi.pt 0-28.66.136.193.in-addr.arpanameserver = dns.di.ubi.pt 0-28.66.136.193.in-addr.arpanameserver = dns2.di.ubi.pt dns.di.ubi.pt internet address = 193.136.66.1 dns2.di.ubi.pt internet address = 193.136.66.2 I believe my records are properly created, so I need to understand this before considering the steps bellow. Thanks and best regards David My reverse file again: $TTL 86400 @ IN SOA di.ubi.pt. postmaster.di.ubi.pt ( 2020040401 ; serial 28800 ; refresh 3h 7200; retry 1h 604800 ; expire 1w 86400 ) ; ttl 1d ; Servidores de nomes IN NS dns.di.ubi.pt. IN NS dns2.di.ubi.pt. 0.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.0 1.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.1 ... 14.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.14 ; reverse mapping 1 IN PTR dns.di.ubi.pt. 2 IN PTR dns2.di.ubi.pt. ... 14 IN PTR gw.di.ubi.pt. -Original Message- From: bind-users On Behalf Of Matus UHLAR - fantomas Sent: 06 November 2022 13:39 To: bind-users@lists.isc.org Subject: Re: Reverse lookups not working when Internet connection failed. On 05.11.22 09:58, David Alexandre M. de Carvalho via bind-users wrote: >Thank you all for the replies. >For what I understand after reading your replies (I might be wrong :) >), reverse lookups fail when I have no outgoing connection because some >caching or or transfer is needed from 66.136.193.in-addr.arpa. , wich I don't >control. This is divided in several networks, 2 of them under my control. correct. Admin of that zone is supposed to: 1. create proper CNAME records: 0.66.136.193.in-addr.arpa. CNAME 0.0-28.66.136.193.in-addr.arpa. ... 15.66.136.193.in-addr.arpa. CNAME 15.0-28.66.136.193.in-addr.arpa. 2. delegate 0-28.66.136.193.in-addr.arpa. to your servers, make their servers secondary for this zone (optional) 3. allow your servers to to fetch 66.136.193.in-addr.arpa. step 1. creates proper aliases step 2. creates working delegation step 3. allows you to see reverse records when your connection is down. alternatively they can choose to 0/28.66.136.193.in-addr.arpa. or 0-15.66.136.193.in-addr.arpa. instead of 0-28.66.136.193.in-addr.arpa. >I'll have to read more carefully your suggestions to see if I find an >alternative way to achieve this only by modifying my zone files, >without messing up my current setup. I'll let you know how it goes. >> On 11/4/22 2:07 PM, Mark Andrews wrote: >>> Any ISP that offers these delegations should be allowing their >>> customers to transfer the zone that contains the CNAMEs for the >>> customer address space by default. >> >> I've had enough trouble getting ISPs to support 2317 delegation period. >> I think that asking them to allow me to do a zone transfer would have >> been a hard no. >> >> I certainly don't think this would be allowed /by/ /default/. >> >> I just checked and § 5.1 of RFC 2317 mentioned having the parent do a >> secondary zone transfer of the child zone. But I don't see any >> mention of the child doing a secondary zone transfer of the parent zone. >> >> I think that would be a good idea. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Emacs is a complicated operating system without good text editor. -- 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
RE: Reverse lookups not working when Internet connection failed.
Thanks again.
>So when your system(s) try to do a reverse DNS (PTR) lookup for 193.136.66.1,
>it will actually do a PTR lookup for 1.66.136.193.in-addr.arpa. and fail
>because you don't have a copy of the >66.136.193.in-addr.arpa. zone file
>locally.
Probably. Am I supposed to, I have just 2 segments in this network (and 2
others on another work) ?
>At least my understanding is that you have a copy of your forward zone, and
>your 0-28.66.136.193.in-addr.arpa. zone. But you don't have a copy of, nor
>access to, the intermediate >66.136.193.in-addr.arpa. zone that references the
>0-28.66.136.193.in-addr.arpa. zone.
Yes! But I never heard of intermediate zone before. As far as I know, my top
domain forwards all "di.ubi.pt" requests to me and that works.
Regards
David
-Original Message-
From: bind-users On Behalf Of Grant Taylor
via bind-users
Sent: 04 November 2022 17:07
To: bind-users@lists.isc.org
Subject: Re: Reverse lookups not working when Internet connection failed.
On 11/4/22 10:54 AM, David Carvalho via bind-users wrote:
> Thanks for the replies.
You're welcome.
> My reverse zone in named.conf. My secondary dns gets it automatically
> daily, along with the "di.ubi.pt.".
ACK
> zone "0-28.66.136.193.in-addr.arpa." IN {
> allow-query { any; };
> type master;
> file "rev0.hosts";
> };
That confirms that the origin is in fact "0-28.66.136.193.in-addr.arpa."
(Save for any typo that I may have introduced.)
> I'll have to study more about some things you guys wrote. This is
> getting complicated
So when your system(s) try to do a reverse DNS (PTR) lookup for 193.136.66.1,
it will actually do a PTR lookup for 1.66.136.193.in-addr.arpa. and fail
because you don't have a copy of the 66.136.193.in-addr.arpa. zone file locally.
At least my understanding is that you have a copy of your forward zone, and
your 0-28.66.136.193.in-addr.arpa. zone. But you don't have a copy of, nor
access to, the intermediate 66.136.193.in-addr.arpa. zone that references the
0-28.66.136.193.in-addr.arpa. zone.
Does that help?
Please feel free to ask additional questions.
--
Grant. . . .
unix || die
--
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: Reverse lookups not working when Internet connection failed.
Thanks for the replies.
My reverse zone in named.conf. My secondary dns gets it automatically daily,
along with the "di.ubi.pt.".
zone "0-28.66.136.193.in-addr.arpa." IN {
allow-query { any; };
type master;
file "rev0.hosts";
};
I'll have to study more about some things you guys wrote. This is getting
complicated
Regards
David
-Original Message-
From: bind-users On Behalf Of Grant Taylor
via bind-users
Sent: 04 November 2022 16:36
To: bind-users@lists.isc.org
Subject: Re: Reverse lookups not working when Internet connection failed.
On 11/4/22 10:07 AM, David Carvalho via bind-users wrote:
> My reverse zone file
What is the origin of your zone file? 0-28.66.136.193.in-addr.arpa.?
> 1.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.1
You seem to be using RFC 2317 Classless IN-ADDR.ARPA delegation.
As such, your reverse DNS is /dependent/ upon the parent zone;
66.136.193.in-addr.arpa., where the Classless IN-ADDR.ARPA delegation CNAME
records exist. E.g.
1.66.136.193.in-addr.arpa. IN CNAME
1.0-28.66.136.193.in-addr.arpa.
It is likely this -- almost certainly -- external dependency was missing while
your Internet connections was down that prevented your systems from being able
to resolve reverse DNS.
Two options come to mind:
1) Create a bogus 66.136.193.in-addr.arpa. zone locally to host the
2317 CNAMEs. -- This will likely have some side effects that need to be
mitigated.
2) Leverage Response Policy Zone(s) to try to influence the lookup as others
suggested. E.g. cause 1.66.136.193.in-addr.arpa. to become
1.0-28.66.136.193.in-addr.arpa. locally. -- I'd have to read about how to do
this.
Aside: I see no need for 1.0-28.66.136.193.in-addr.arpa. to have an A record.
But I don't see any problem with having it either.
> 1.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.1
>
> ; Reverse mapping
>
> 1 IN PTR dns.di.ubi.pt.
> ...
These are the types of PTR records that I would expect to see in a reverse DNS
context.
--
Grant. . . .
unix || die
--
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: Reverse lookups not working when Internet connection failed.
Thanks for the replies. My reverse zone file $TTL 86400 @ IN SOA di.ubi.pt. postmaster.di.ubi.pt ( 2020040401 ; serial 28800 ; refresh 3h 7200; retry 1h 604800 ; expire 1w 86400 ) ; ttl 1d ; Servidores de nomes IN NS dns.di.ubi.pt. IN NS dns2.di.ubi.pt. 0.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.0 1.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.1 2.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.2 3.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.3 4.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.4 5.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.5 6.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.6 7.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.7 8.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.8 9.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.9 10.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.10 11.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.11 12.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.12 13.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.13 14.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.14 ; Reverse mapping 1 IN PTR dns.di.ubi.pt. 2 IN PTR dns2.di.ubi.pt. 3 IN PTR geodac.di.ubi.pt. ... -Original Message- From: bind-users On Behalf Of Matus UHLAR - fantomas Sent: 04 November 2022 16:02 To: bind-users@lists.isc.org Subject: Re: Reverse lookups not working when Internet connection failed. On 04.11.22 15:41, David Carvalho via bind-users wrote: >We've had an internet failure for a few days last week and as services >got online I found the following: > >Dns queries about my.domain from my.domain worked as expected. Since >there was no internet connection, I obviously couldn't query the outside world. > >Reverse (PTR) Dns queries about my.domain from my.domain didn't work. >Now that the internet connection is restored, everything is ok. > > > >The reverse entries are in the format "z.y.x.in-addr.arpa."for IP x.y.z > >Aren't they supposed to work locally when no outside connection is >available? if they are properly configured, yes. > What could I be missing? can you provide an example of an IP and configured reverse zone, and the zone file? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Support bacteria - they're the only culture some people have. -- 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 -- 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
Reverse lookups not working when Internet connection failed.
Hello, good afternoon. We've had an internet failure for a few days last week and as services got online I found the following: Dns queries about my.domain from my.domain worked as expected. Since there was no internet connection, I obviously couldn't query the outside world. Reverse (PTR) Dns queries about my.domain from my.domain didn't work. Now that the internet connection is restored, everything is ok. The reverse entries are in the format "z.y.x.in-addr.arpa."for IP x.y.z Aren't they supposed to work locally when no outside connection is available? What could I be missing? Thanks and regards. David -- 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
