dig: couldn't get address for root servers
Greetings, Hope you're all doing great. Actually, I am using bind 9.11.28-S1, and I am facing some problems : whenever I use the command dig +trace, I came across this error : dig: couldn't get address for 'F.ROOT-SERVERS.NET': failure. Does anyone have an idea why I see this error ? It is really causing DNS failures. Best regards. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Resolver failures after stale-answer enabled
Hello, few days ago I updated our recursive resolvers at AS50242 from Debian 10 to 11 to be able to enable stale-answer afer Facebook incident. However, today I got bug reports from customers. Their browser often fail at page loading with DNS_PROBE_FINISHED_NXDOMAIN. After few seconds (and after browser DNS re-query) page will load correctly. In Bind9 log I see many of messages like: Oct 27 11:34:13 srv-snv-production named[576109]: configuration.ls.apple.com resolver failure, stale answer unavailable Oct 27 11:34:13 srv-snv-production named[576109]: client @0x7fc71806cd58 10.202.42.196#58876 (configuration.ls.apple.com): view clients: query failed (SERVFAIL) for configuration.ls.apple.com/IN/TYPE65 at query.c:5832 Oct 27 11:34:13 srv-snv-production named[576109]: configuration.ls.apple.com resolver failure, stale answer unavailable Oct 27 11:34:13 srv-snv-production named[576109]: client @0x7fc7180715a8 10.202.42.196#49219 (configuration.ls.apple.com): view clients: query failed (SERVFAIL) for configuration.ls.apple.com/IN/A at query.c:5832 After I turned off stale-answer, problem looks to be resolved. I'm attaching huge debug log of above failures - hope somebody will find problem from this. The problematic query starts at 27-Oct-2021 11:34:13.858 https://drive.google.com/file/d/1qiyLa8CfNN54PUktth6R4kT8PpohNsde/view?usp=sharing Linux srv-le-production 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux bind9/stable,now 1:9.16.15-1 amd64 Regards, Blažej Krajňák ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC questions
Hi all,
I recently installed version 9.16, and have a number of doubts. During the
upgrade, named didn't want to load signed zones because of CDS/CDNSKEY
inconsistency. There were CDS records in the zone files, which I removed.
I also switched to dnssec-policy. Somewhere I read that I should have defined
a policy with keys matching the existing keys. I also defined a "combined"
key. Now I have two DS, two CDS, and two CDNSKEY RRs. I attach a picture of a
zone and paste the policy below.
The questions:
1. Now, how do I get rid of the extra ksk and zsk? Is it enough to remove them
from the policy?
2. I have double CDS/CDNSKEY records, but they're not in the zone files. Do I
have to run rndc dnssec -checkds to remove them?
3. The server produces new .signed and .signed.jnl files every day, which is
inconvenient as the zone files directory is checked by tripwire. Is that
timing determined by the dnskey-ttl? Would it be okay to set it to one month?
4. Is rndc managed-keys status supposed to display anything meaningful, given
my setup? It talks about a non-existing key id. The sync option produces no
output at all. How do I know the overall dnssec status?
Here's my policy setting:
dnssec-policy "explicit" {
// Keys
keys {
ksk key-directory lifetime unlimited algorithm rsasha256 2048;
zsk key-directory lifetime unlimited algorithm rsasha256 2048;
csk key-directory lifetime unlimited algorithm rsasha256 2048;
};
nsec3param iterations 1 optout false salt-length 16;
// Key timings
dnskey-ttl 86400;
publish-safety P3W;
retire-safety P3W;
purge-keys P1Y;
// Signature timings
signatures-refresh P2M;
signatures-validity P6M;
signatures-validity-dnskey P6M;
// Zone parameters
max-zone-ttl 86400;
zone-propagation-delay PT1H;
// Parent parameters
parent-ds-ttl 86400;
parent-propagation-delay PT1H;
};
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Resolver failures after stale-answer enabled
https://gitlab.isc.org/isc-projects/bind9/-/issues/2982 st 27. 10. 2021 o 11:53 Blažej Krajňák napísal(a): > > Hello, > > few days ago I updated our recursive resolvers at AS50242 from Debian > 10 to 11 to be able to enable stale-answer afer Facebook incident. > However, today I got bug reports from customers. Their browser often > fail at page loading with DNS_PROBE_FINISHED_NXDOMAIN. After few > seconds (and after browser DNS re-query) page will load correctly. In > Bind9 log I see many of messages like: > > Oct 27 11:34:13 srv-snv-production named[576109]: > configuration.ls.apple.com resolver failure, stale answer unavailable > Oct 27 11:34:13 srv-snv-production named[576109]: client > @0x7fc71806cd58 10.202.42.196#58876 (configuration.ls.apple.com): view > clients: query failed (SERVFAIL) for > configuration.ls.apple.com/IN/TYPE65 at query.c:5832 > Oct 27 11:34:13 srv-snv-production named[576109]: > configuration.ls.apple.com resolver failure, stale answer unavailable > Oct 27 11:34:13 srv-snv-production named[576109]: client > @0x7fc7180715a8 10.202.42.196#49219 (configuration.ls.apple.com): view > clients: query failed (SERVFAIL) for configuration.ls.apple.com/IN/A > at query.c:5832 > > After I turned off stale-answer, problem looks to be resolved. I'm > attaching huge debug log of above failures - hope somebody will find > problem from this. The problematic query starts at 27-Oct-2021 > 11:34:13.858 > > https://drive.google.com/file/d/1qiyLa8CfNN54PUktth6R4kT8PpohNsde/view?usp=sharing > > Linux srv-le-production 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 > (2021-09-30) x86_64 GNU/Linux > bind9/stable,now 1:9.16.15-1 amd64 > > > Regards, > Blažej Krajňák ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ECS-IP in the RPZ-Log?
Hi Using BIND-9.16.21. I'm wondering, if it's possible to have the ECS client IP address in the RPZ log. In front of our BIND, which has an RPZ configuration, is a dnsdist, which inject the ECS-IP. BIND could log the ECS-IP with the builtin "querylog" (rndc querylog on). In the following example, the effective client-IP is 172.16.16.33/32, which is logged fine here: 27-Oct-2021 15:41:27.940 queries: info: client @0x7f3db81aa0f8 127.0.0.1#44353 (example.ch): query: example.ch IN A +E(0)K (127.0.0.1) [ECS 172.16.16.33/32/0] But in the RPZ log, I can correctly see only the dnsdist IP and not the one from the effective source (172.16.16.33): 27-Oct-2021 15:41:27.940 rpz: info: client @0x7f3db81aa0f8 127.0.0.1#44353 (example.ch): rpz QNAME NXDOMAIN rewrite example.ch/A/IN via example.ch.blacklist-rpz.test.local Is there a way to have/see the ECS-IP in the RPZ log? Many thanks. Kind regards, Tom ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC questions
Hi Allesandro,
Your policy has three keys:
keys {
ksk key-directory lifetime unlimited algorithm rsasha256 2048;
zsk key-directory lifetime unlimited algorithm rsasha256 2048;
csk key-directory lifetime unlimited algorithm rsasha256 2048;
};
Two of them require DS records (ksk and csk), so that is why you have
double CDS/CDNSKEY records.
On 27-10-2021 12:54, Alessandro Vesely wrote:
Hi all,
I recently installed version 9.16, and have a number of doubts. During
the upgrade, named didn't want to load signed zones because of
CDS/CDNSKEY inconsistency. There were CDS records in the zone files,
which I removed.
I also switched to dnssec-policy. Somewhere I read that I should have
defined a policy with keys matching the existing keys. I also defined a
"combined" key. Now I have two DS, two CDS, and two CDNSKEY RRs. I
attach a picture of a zone and paste the policy below.
Adding the combined key to the policy means you did not create a policy
that matched the existing keys. BIND notices that you want three keys,
you only have two, so it creates the CSK.
The questions:
1. Now, how do I get rid of the extra ksk and zsk? Is it enough to
remove them from the policy?
You can remove them from the policy yes, but make sure the migration is
complete. You can check with "rndc dnssec -status " and make sure
that your key states are in "omnipresent".
2. I have double CDS/CDNSKEY records, but they're not in the zone
files. Do I have to run rndc dnssec -checkds to remove them?
That's because you added the additional CSK to the policy. It is
probably best to remove it again from the policy and only change the
policy if the migration is complete.
3. The server produces new .signed and .signed.jnl files every day,
which is inconvenient as the zone files directory is checked by
tripwire. Is that timing determined by the dnskey-ttl? Would it be
okay to set it to one month?
The zone is signed if a signature is about to expire. It is not
determined by dnskey-ttl. I would exclude these files from tripwire
because they need to written out anyway.
4. Is rndc managed-keys status supposed to display anything meaningful,
given my setup? It talks about a non-existing key id. The sync option
produces no output at all. How do I know the overall dnssec status?
"rndc managed-keys status" is for trust anchors, use "rndc dnssec
-status " instead.
Best regards,
Matthijs
Here's my policy setting:
dnssec-policy "explicit" {
// Keys
keys {
ksk key-directory lifetime unlimited algorithm rsasha256 2048;
zsk key-directory lifetime unlimited algorithm rsasha256 2048;
csk key-directory lifetime unlimited algorithm rsasha256 2048;
};
nsec3param iterations 1 optout false salt-length 16;
// Key timings
dnskey-ttl 86400;
publish-safety P3W;
retire-safety P3W;
purge-keys P1Y;
// Signature timings
signatures-refresh P2M;
signatures-validity P6M;
signatures-validity-dnskey P6M;
// Zone parameters
max-zone-ttl 86400;
zone-propagation-delay PT1H;
// Parent parameters
parent-ds-ttl 86400;
parent-propagation-delay PT1H;
};
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Query on issue#2389 BIND 9.16.10
-- Ondřej Surý (He/Him) ond...@isc.org > On 27. 10. 2021, at 7:03, Mayank Maheshwari M > wrote: > > Hi Ondrej, > > Thanks for all your responses so far. > > As per the recommendation from BIND community we plan to proceed with an > upgrade to latest BIND version (9.16.21) where, as per BIND this issue is > fixed. > But referring to your last email, where you stated that " All the information > available is always written down in the issue you have already referenced." > Based on our findings, we only able to see limited (Single line) information > for this issue which is mentioned in below mail. Yes, that’s it. The issue states that issues like this were resolved by refactoring the TCPDNS component and it was already released by the time we got the report. And that’s it. > I really appreciate if you could direct us with some more details on this > issue, this will really help us in explaining the fault to our customers and > reproduction of this issue in our labs. There are no “more details” available anywhere. You should explain to your customers that you failed to upgrade the BIND 9 version on time and that’s what is causing the fault. There were at least 4 CVEs fixed since BIND 9.16.10. > Or redirect it to correct person, who have this information. There’s no other “correct person”. > Really appreciated your support so far and looking forward for the same. I already suggested that if you want somebody to look into it, you would have to pay for the extra time. Nobody is going to analyse bug in year old version of BIND 9 since the bug has been already fixed. But you seem to ignored that message and insist we do the work for you, so I am going to repeat it here again: """ BIND 9.16.10 was tagged and released in December 2020. That’s almost a year ago. You can’t and should not expect people do work for free when you slacked on updates. You have to carry the costs of the bad decision you made when you decided to stick with old version. The word “free” in free software is to be interpreted as the word “free” in free speech and not as in free beer. We do not limit what can you do with the software beyond MPL-2.0 license, but that’s it. There’s no obligation to do any work for free. For everything else there’s a hint in the mailing list footer, I’ll copy it here for your convenience: ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. """ > Best Regards > Mayank Maheshwari > > -Original Message- > From: Rajnish Kamboj > Sent: Tuesday, October 26, 2021 5:50 PM > To: Ondřej Surý > Cc: bind-users@lists.isc.org; Mayank Maheshwari M > ; Swaminathan Plsi > > Subject: RE: Query on issue#2389 BIND 9.16.10 > > Hi Ondřej > > We have gone thru the issue " > https://gitlab.isc.org/isc-projects/bind9/-/issues/2389"; and could not find > the scenario which causes this issue. > Before upgrading to latest BIND, we want to reproduce the issue in our labs. > > In the issue it is mentioned that "The sends is -1 in the coredump which > means that there was a double call to the callback. This class of issues > were fixed in !4455 (merged)" > It would be of great help if the scenario which causes this issue is shared, > so that we can reproduce it in our labs, before upgrading BIND. > > > > > Regards > Rajnish Kamboj > > -Original Message- > From: Ondřej Surý > Sent: Monday, October 18, 2021 4:39 PM > To: Rajnish Kamboj > Cc: bind-users@lists.isc.org > Subject: Re: Query on issue#2389 BIND 9.16.10 > > All the information available is always written down in the issue you have > already referenced. That’s always the case - even with security issues, > there’s only 1 month+ delay to give people chance to upgrade. > > Ondřej > -- > Ondřej Surý — ISC (He/Him) > > My working hours and your working hours may be different. Please do not feel > obligated to reply outside your normal working hours. > >> On 18. 10. 2021, at 12:58, Rajnish Kamboj >> wrote: >> >> Thanks Ondrej for your quick reply, >> >> Upgrading to latest release will fix the issue. >> Can you also help us with scenarios as to why this issue is occurring? >> May be this will help us in quick workaround (if possible) till the time we >> plan for latest BIND. >> >> >> Regards >> Rajnish Kamboj >> >> -Original Message- >> From: Ondřej Surý >> Sent: Monday, October 18, 2021 3:28 PM >> To: Rajnish Kamboj >> Cc: bind-users@lists.isc.org >> Subject: Re: Query on issue#2389 BIND 9.16.10 >> >> Hi, >> >> there were several security issues since 9.16.10, you should be running >> either last 9.16.x release (9.16.21 as of time writing this email) or have >> all of the issues patched. >> >> The thing you are asking for is so wrong on so many levels. Don’t do that, >> upgrade to last version instead. >> >> Ondrej >> -- >> Ondřej Surý (He/Him) >> ond...@isc.org >> >>> On 18. 10. 2021, at 11:51
Re: DNSSEC questions
Hi Matthijs, thanks for clarifications. On Wed 27/Oct/2021 17:53:46 +0200 Matthijs Mekking wrote: On 27-10-2021 12:54, Alessandro Vesely wrote: I also switched to dnssec-policy. Somewhere I read that I should have defined a policy with keys matching the existing keys. I also defined a "combined" key. Now I have two DS, two CDS, and two CDNSKEY RRs. I attach a picture of a zone and paste the policy below. Adding the combined key to the policy means you did not create a policy that matched the existing keys. BIND notices that you want three keys, you only have two, so it creates the CSK. Yup, the intention was (and still is) to migrate to CSK, as it's simpler, without breaking existing status. So now I need to get rid of the old keys. 1. Now, how do I get rid of the extra ksk and zsk? Is it enough to remove them from the policy? You can remove them from the policy yes, but make sure the migration is complete. You can check with "rndc dnssec -status " and make sure that your key states are in "omnipresent". Thanks, that's what I was looking for. I have to check all zones (and two views each). I'll write a script for that. 2. I have double CDS/CDNSKEY records, but they're not in the zone files. Do I have to run rndc dnssec -checkds to remove them? That's because you added the additional CSK to the policy. It is probably best to remove it again from the policy and only change the policy if the migration is complete. Right. So the script must also check that the new keys have a parental DS. 3. The server produces new .signed and .signed.jnl files every day, which is inconvenient as the zone files directory is checked by tripwire. Is that timing determined by the dnskey-ttl? Would it be okay to set it to one month? The zone is signed if a signature is about to expire. It is not determined by dnskey-ttl. I would exclude these files from tripwire because they need to written out anyway. Then, why does it have to rewrite it every day, if the zone didn't change? dnskey-ttl is the only one-day timing thing, except parent-ds-ttl. BTW, DS RR has a ttl of 10800 at the parent; should I copy that to parent-ds-ttl in my policy definition? What for? 4. Is rndc managed-keys status supposed to display anything meaningful, given my setup? It talks about a non-existing key id. The sync option produces no output at all. How do I know the overall dnssec status? "rndc managed-keys status" is for trust anchors, use "rndc dnssec -status " instead. OK. Thanks again, Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ECS-IP in the RPZ-Log?
Submit a issue at https://gitlab.isc.org/ > On 28 Oct 2021, at 01:00, Tom wrote: > > Hi > > Using BIND-9.16.21. I'm wondering, if it's possible to have the ECS client IP > address in the RPZ log. > In front of our BIND, which has an RPZ configuration, is a dnsdist, which > inject the ECS-IP. > > BIND could log the ECS-IP with the builtin "querylog" (rndc querylog on). In > the following example, the effective client-IP is 172.16.16.33/32, which is > logged fine here: > 27-Oct-2021 15:41:27.940 queries: info: client @0x7f3db81aa0f8 > 127.0.0.1#44353 (example.ch): query: example.ch IN A +E(0)K (127.0.0.1) [ECS > 172.16.16.33/32/0] > > > But in the RPZ log, I can correctly see only the dnsdist IP and not the one > from the effective source (172.16.16.33): > 27-Oct-2021 15:41:27.940 rpz: info: client @0x7f3db81aa0f8 127.0.0.1#44353 > (example.ch): rpz QNAME NXDOMAIN rewrite example.ch/A/IN via > example.ch.blacklist-rpz.test.local > > Is there a way to have/see the ECS-IP in the RPZ log? > > Many thanks. > Kind regards, > Tom > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list 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
