Problems with (unsigned) forward zones, dnssec-validation auto and validate-except on BIND 9.16 and 9.17

[Gehrkens . IT GmbH | Heiko Wundram]

Dear list,

 

I'm currently setting up a resolver using bind (tested with both 9.16 and
9.17), which uses multiple views to expose forwarded zones (under .lan and
.local, old Windows-AD zones which I don't control and can't change.) under
some of their views. All of the views have dnssec-validation auto (set as a
global option), and the forwarding zones are configured as "type forward;
forward only;" in each specific view using an import from a single
configuration file which contains all forward zone specifications and also a
"validate-except" clause which lists all of the forwarded zones.

 

Generally, this works: in the views that should resolve the internal
forwarded zone names, I can resolve them, and BIND also skips DNSsec
validation for those zones. Now comes the but: if I resolve a zone name in
.lan or .local which is not forwarded I get an NXDOMAIN with "ad" as I would
expect (coming from the roots which authoritatively don't know e.g. .local),
but the cached entry for the authoritative NXDOMAIN seems to block future
resolution of all forwarded zones under this pseudo-TLD. When the resolved
records under the forwarded .lan or .local zone time out, I get an NXDOMAIN
for any record that I try to resolve in a zone that should be reachable
through forward, with "authority" for the result pointing to the roots. It
seems that this also kills the connectivity of the forward zone completely
(i.e., the zone is removed from BIND in some way or another): I need to
restart bind to make the forward-zones resolvable again, clearing the
resolver cache does not seem to help to get them to resolve again.

 

>From what I gather, this behaviour sounds almost like what RFC 8020 proposes
(NXDOMAIN cut), but at least according to the corresponding ticket, that
isn't implemented in BIND.

 

BIND 9.11 (which comes with Debian Buster) did not have this behaviour with
this configuration (for BIND 9.11, I did not use validate-except but
periodic rndc nta for the injected forward zones, but using that with BIND
9.16/.17 gives the same result as above), but after updating BIND to the
version in bullseye (which comes with 9.16), I see this behaviour, and it
seems that this only happens when DNSsec validation is on. Turning it off
makes the forward zones work correctly. I do not want to turn off DNSsec
validation completely, and neither do I want to "validate-except" lan and
local (which does not help anyway, as I currently don't have a .lan/.local
zone file set up and would rather not have to manage one, as the forwarders
aren't the NS records for the zones I'm looking up anyway, so it'd be rather
difficult to make a proper glue entry for the forwarded zones without
additional network magic).

 

Thanks for any hints on where I might look; I tried to follow the actual
resolver code, but that gave me no immediate cause for the change, and I
also found no entries in the bugtracker.

 

Heiko.



smime.p7s
Description: S/MIME cryptographic signature
___
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

9.18.0 now available

[Peter Davies]

For those of you that may not be on the -announce list, I
would like to make you aware of the following:

https://lists.isc.org/pipermail/bind-announce/2022-January/001205.html

--
Peter Davies
Support Engineer
Internet Systems Corporation
pet...@isc.org
001 650-423-1460

___
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: test - ignore

[Matus UHLAR - fantomas]

On Jan 25, 2022, at 8:50 AM, Benny Pedersen  wrote:
Authentication-Results: lists.isc.org;
dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z


On 25.01.22 12:25, Dan Mahoney wrote:

The headers you cite are lying to you.  :) The message passed DKIM on the
way IN to lists.isc.org (the dedicated vm that runs our lists), but then,
when the message got to the mailman python scripts and then shot back out
via the MTA, they had an altered body and no longer passed, and the header
was rewritten to say "fail".  (This is visible from the logging on the
servers, but nowhere else).


there were multiple headers when that mail came here:

Authentication-Results: fantomas.fantomas.sk;
   dkim=fail reason="signature verification failed" (1024-bit key; secure) 
header.d=isc.org header.i=@isc.org header.b="q/vOEba5";
   dkim=fail reason="signature verification failed" (1024-bit key; secure) 
header.d=isc.org header.i=@isc.org header.b="ozeUkO/Z";
   dkim-atps=neutral
Authentication-Results: lists.isc.org;
   dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
   dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z

obviously when the mail came to list, DKIM was fine, not so after it left
(thanks to list signature)


will my dkim fail aswell ?


it did...


Altering the body or headers at all (whch lists do) will often break the
hashing.  For this reason, most recent versions of mailman have an option
to rewrite your mail from:


[...]

...but only in the event you have a restrictive DMARC policy. 


this explains why both your and Benny's mail did fail here, while Eduard's
did not - that one was signed by mailman because of his domains' restrictive
policy.

I missed this part before.


I've argued that it should be possible to do so for *any* dmarc policy,
even p=none, but that option is not present in mailman 3, at least.


I agree.
spam filter is something that can use dkim fail and should not be ignored.

--
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.
___
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: test - ignore

[Sten Carlsen]

Thanks

Sten

> On 26 Jan 2022, at 17.14, Matus UHLAR - fantomas  wrote:
> 
>>> On Jan 25, 2022, at 8:50 AM, Benny Pedersen  wrote:
>>> Authentication-Results: lists.isc.org;
>>> dkim=fail reason="signature verification failed" (1024-bit key; 
>>> unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
>>> dkim=fail reason="signature verification failed" (1024-bit key; 
>>> unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z
> 
> On 25.01.22 12:25, Dan Mahoney wrote:
>> The headers you cite are lying to you.  :) The message passed DKIM on the
>> way IN to lists.isc.org (the dedicated vm that runs our lists), but then,
>> when the message got to the mailman python scripts and then shot back out
>> via the MTA, they had an altered body and no longer passed, and the header
>> was rewritten to say "fail".  (This is visible from the logging on the
>> servers, but nowhere else).
> 
> there were multiple headers when that mail came here:
> 
> Authentication-Results: fantomas.fantomas.sk;
>   dkim=fail reason="signature verification failed" (1024-bit key; secure) 
> header.d=isc.org header.i=@isc.org header.b="q/vOEba5";
>   dkim=fail reason="signature verification failed" (1024-bit key; secure) 
> header.d=isc.org header.i=@isc.org header.b="ozeUkO/Z";
>   dkim-atps=neutral
> Authentication-Results: lists.isc.org;
>   dkim=fail reason="signature verification failed" (1024-bit key; 
> unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
>   dkim=fail reason="signature verification failed" (1024-bit key; 
> unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z
> 
> obviously when the mail came to list, DKIM was fine, not so after it left
> (thanks to list signature)
> 
>>> will my dkim fail aswell ?
> 
> it did...
> 
>> Altering the body or headers at all (whch lists do) will often break the
>> hashing.  For this reason, most recent versions of mailman have an option
>> to rewrite your mail from:

When the dkim is set up, you can select which parts of the header you want to 
include in the signature.

I have selected a smaller part of the headers for my signature,  so does this 
go through?

> 
> [...]
> 
>> ...but only in the event you have a restrictive DMARC policy. 
> 
> this explains why both your and Benny's mail did fail here, while Eduard's
> did not - that one was signed by mailman because of his domains' restrictive
> policy.
> 
> I missed this part before.
> 
>> I've argued that it should be possible to do so for *any* dmarc policy,
>> even p=none, but that option is not present in mailman 3, at least.
> 
> I agree.
> spam filter is something that can use dkim fail and should not be ignored.
> 
> -- 
> 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.
> ___
> 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

9.11, 9.16 and ESV designation

[John Thurston]

We're running mostly 9.11, with a couple of hosts running 9.16. We've 
been sticking with 9.11 while we waited for 9.16 to be labeled the 
Extended Support Version (ESV). The recent announcement of 9.18 made me 
go digging to learn . .. 9.16 _is_ the ESV and 9.11 is EOL and will no 
longer be supported after March 2022!


https://kb.isc.org/docs/aa-01540

Here are our current ESV versions and their EOL dates:

BIND 9.11 is our out-going Stable/Extended Support Version, currently in EOL 
status, supported until March, 2022.
BIND 9.16 is our current Stable/ESV version.
BIND 9.18 is our newest Stable version.



That document was last updated on Jan 5, 2022, so this news is at least 
three weeks old. I don't recall seeing anything on the "Announce" 
mailing list regarding the change in ESV designation. Nor do I see any 
difference in the COPR packages:


https://copr.fedorainfracloud.org/coprs/isc/bind-esv/

which continue to offer 9.11.

Now, I don't expect my 9.11 installation to give me any trouble, and I 
don't expect it suddenly stop working in April. But I do expect someone 
with a clipboard and checklist to drag me over the coals if they 
discover I'm running an "end of life" version without a mitigation plan.


So I gotta start sketching paths from 9.11 -> 9.16 and 9.16 -> 9.18. To 
assist me in that, I'm looking for answers to two questions:


A) Where was the ESV-switch announced? (I though I had my bases covered 
by subscribing to 'announce' and 'user' mailing lists. I need to find 
and plug this communication hole.)


B) What are the plans for the 'bind-esv' COPR? (Will it soon start 
serving 9.16? Do I need to manually switch from 'bind-esv' to 'bind'? Is 
COPR dead?)


--
--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
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: 9.11, 9.16 and ESV designation

[Victoria Risk]

Hi John,

> 
> That document was last updated on Jan 5, 2022, so this news is at least three 
> weeks old. I don't recall seeing anything on the "Announce" mailing list 
> regarding the change in ESV designation.

…..
> Nor do I see any difference in the COPR packages:
> 
> https://copr.fedorainfracloud.org/coprs/isc/bind-esv/
> 
> which continue to offer 9.11.
> 
> A) Where was the ESV-switch announced? (I though I had my bases covered by 
> subscribing to 'announce' and 'user' mailing lists. I need to find and plug 
> this communication hole.)

This is my fault. I am sorry. 

I posted a blog last June, in which we declared 9.16 ESV (and started marking 
it that way on the downloads page and in the release notes). 
https://www.isc.org/blogs/bind-update-summer2021/ 


We do try to keep the matrix showing EOL dates current here: 
https://kb.isc.org/docs/aa-00896 , and that 
hasn’t been changed since last summer, when we finally declared 9.16 ESV, 6 
months after the point at which we would normally have done so. 

Normally, we would also send some reminders to the list(s) when we are at T-3 
months from EOL. 2021 was a difficult year in more ways than one, and 
apparently, we didn’t do this. My only excuse, which is a weak one, is that I 
was reluctant to pull the plug on 9.11 until we were more confident that 9.16 
was really solid, so I put it off. However, even though we failed to remind the 
list, we haven’t changed the 9.11 EOL date, it has been set for ages. 

I will send a note to bind-announce pointing out that it is time to move off of 
9.11.

> 
> B) What are the plans for the 'bind-esv' COPR? (Will it soon start serving 
> 9.16? Do I need to manually switch from 'bind-esv' to 'bind'? Is COPR dead?)

Good question. This is admittedly confusing. 

We already have 3 BIND versions in our packages, bind, bind-dev and bind-esv. 
We have just a brief overlap here between 9.11 and 9.18, but we don’t want to 
create yet another repo.  Because we are still patching 9.11, and we haven’t 
yet issued a new dev branch, we are putting 9.18.0 into the bind-dev repo, for 
now.

In April, we plan to do a version rollover:
- bind-esv will go from 9.11 to 9.16
- bind will go from 9.16 to 9.18
- bind-dev will go from 9.18.1 to 9.19.0

I hope this helps.

Regards,

Vicky Risk

___
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

Reminder: BIND 9.11 is going EOL in March 2022

[Victoria Risk]

Hello bind-announce,

BIND 9.11 is now in its last quarter of support. We are fixing critical 
security issues only at this point. It is time to start making plans to update 
if you are still running a 9.11 version. (The current release plan is published 
at https://kb.isc.org/docs/aa-00896 .)

BIND 9.11.0 was published in October of 2016. A *lot* has happened since then. 
Also, we have refactored some significant functions in BIND and 9.16 has quite 
a few changes compared to 9.11.

One of our support engineers analyzed the differences in options between the 
versions, and wrote this KB article for people migrating: 
https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-911-to-916 
 .

We also have updated the ‘BIND Significant Features Matrix’ with the major 
feature differences between releases. This is not as detailed as the KB 
mentioned above. https://kb.isc.org/docs/aa-01310 
.  

While we don’t have current performance tests that compare the latest 9.11 
version to the latest 9.16 version, we did quite a bit of performance testing 
on the 9.16 branch in 2021 and we do not expect any loss of performance moving 
from 9.11 to 9.16. (see 
https://www.isc.org/blogs/bind-resolver-performance-july-2021/ 
 for 
performance results for resolver operations) There may be some changes in 
memory utilization, which we have tried to minimize in the latest versions. 
(see https://kb.isc.org/docs/bind-memory-consumption-explained 
 for more details).

For those using the ISC BIND packages:  

Because we are still patching 9.11, and we haven’t yet issued a new development 
branch, we are putting 9.18.0 into the bind-dev repositories, for now.

In April, we plan to do a version rollover:
- bind-esv will go from 9.11 to 9.16
- bind will go from 9.16 to 9.18
- bind-dev will go from 9.18.1 to 9.19.0 

BIND 9.19.0 will be the new development branch.

Regards,

Vicky Risk___
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: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)

[Mark Andrews]

DNSSEC involves lots of timing / co-ordination points and if any of them get 
delayed for any reason the
following ones also need to be delayed.  While dnssec-keygen will allow you to 
set all of the timers for
all of a keys life, it is bad practice to do that. 

If you are going to set the timers like this there needs to be much more time 
between the inactivation time
and the deletion time.  As I said earlier about 30 days with default values for 
sig-validity-interval.

Mark


> On 25 Jan 2022, at 18:46, ego...@ramattack.net wrote:
> 
> Hi!!
> 
> 
> 
> Don't really know if it could help, but I generate the ZSK keys this way :
> 
> 
> 
> /usr/local/sbin/dnssec-keygen -3 -a 8 -b 1024 -P now -A now -I +45d -D +47d 
> _
> 
> 
> 
> Cheers!!
> 
>  
> 
> 
> El 2022-01-25 02:48, Mark Andrews escribió:
> 
>> 
>> 
>> 
>> 
>>> On 25 Jan 2022, at 11:55, ego...@ramattack.net wrote:
>>> 
>>> Hi Mark!!
>>> 
>>> 
>>> 
>>> Thank you so much for your answer!! and your time!!.
>>> 
>>> 
>>> 
>>> I have a couple of questions. I ask them between your lines and in blue for 
>>> instance... for emphasizing and being easier to see what I'm referring to. 
>>> I'm talking about ZSK keys in the questions I am asking in blue.
>>> 
>>>  
>>> 
>>> 
>>> El 2022-01-25 00:36, Mark Andrews escribió:
>>> 
 
 How 'named' manages DNSSEC is very different to how 'dnssec-signzone' 
 manages DNSSEC.  When you tell named to
 inactivate a DNSKEY it stops re-signing the zone with it and it stops 
 signing new records added to the zone
 with it.  
  
  
 The fact is, I don't tell named nothing really. It maintains the zone 
 signatures (I'm using inline-signing yes; auto-dnssec maintain; per zone). 
 I just provide it keys and then I wait, until the ZSK key's delete time 
 arrives, then I remove it's files (.key and .private). I don't wait until 
 the inactive time. I wait until the delete time (not the inactive time). 
 After the delete time of the key, can still records (rrsigs) exist signed 
 with that key then?.
>> 
>> Yes.  
>> 
 It DOES NOT immediately replace all RRSIGs generated using that key.  
 Those records will be replaced
 over the sig-validity-interval as they fall due for re-signing.  Once all 
 those RRSIG records have been
 replaced and they have expired from caches, you can then delete the DNSKEY 
 record.
 
 With the default sig-validity-interval (30) that takes up to 22.5 days to 
 which you have to add the record TTL.
  
 Ok, but does sig-validity-interval affect too, after the key deletion 
 date?. Or does it affect only from the inactivation date to the deletion 
 date of a key?.
>> 
>> sig-validity-interval and re-signing is independent of inactive and delete 
>> dates.
>> 
 Mark
  
  
 Best regards
 
> On 25 Jan 2022, at 05:21, egoitz--- via bind-users 
>  wrote:
> 
> Hi!!
> 
> 
> 
> Thanks a lot for your answer!!
> 
> 
> 
> I tried before the fact of renaming back and rndc sign... but does not 
> work just has removed the error from the log
> 
> 
> 
> I have changed my key managing code, for not renaming to "-OLD"  the ZSK 
> (.key and .private) until have passed at least 2 days from the deletion 
> time... Let's see if this way works better
> 
>  
> 
> 
> Any more ideas mates?.
> 
> 
> 
> Thank you so much for your time :)
> 
> 
> 
> Best regards,
> 
> El 2022-01-24 17:51, Tony Finch escribió:
> 
>> ATENCION
>> ATENCION
>> ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. No 
>> pinche en los enlaces ni abra los adjuntos a no ser que reconozca el 
>> remitente y sepa que el contenido es seguro.
>> 
>> egoitz--- via bind-users  wrote:
>>> 
>>> These are the contents of a cat of the private file I have renamed to
>>> samename.private-OLD :
>>> 
>>> Created: 20211031230338
>>> Publish: 2020220241
>>> Activate: 2020220341
>>> Inactive: 20211215230338
>>> Delete: 20211217230338
>> 
>> Yes, it can be confusing when the state of the key files doesn't match 
>> the
>> state of the zone.
>> 
>> I think you said you have renamed all your key files back to their usual
>> non-OLD names. Good; that is necessary if named is still looking for a 
>> key
>> file even if it shouldn't need it any more.
>> 
>> Then, try running `rndc sign `, to make named reload the keys. I
>> think that should also get it to make whatever updates might be 
>> necessary.
>> 
>> Then look at the logs to see if there are errors, and look at the DNSKEY
>> RRset (with its RRSIGs) to make sure it matches what you expect.
>> 
>> If that doesn't get things straightened out then, um, dunno :-)
>> 
>> I 

Re: test - ignore

[Matus UHLAR - fantomas]

On 26 Jan 2022, at 17.14, Matus UHLAR - fantomas  wrote:

Altering the body or headers at all (whch lists do) will often break the
hashing.  For this reason, most recent versions of mailman have an option
to rewrite your mail from:



On 26.01.22 17:30, Sten Carlsen wrote:

When the dkim is set up, you can select which parts of the header you want
to include in the signature.


this is not possible for body: modification of body (which this list does)
will always break DKIM signatures.

modifying list of headers to sign should be done carefully, to avoid
either breaking and faking.


I have selected a smaller part of the headers for my signature,  so does
this go through?


since domain s-carlsen.dk don't have dmarc policy, mailman does not care and
leaves dkim as is (broken) as described below.


...but only in the event you have a restrictive DMARC policy.



this explains why both your and Benny's mail did fail here, while Eduard's
did not - that one was signed by mailman because of his domains' restrictive
policy.


however, this discussion should be probably closed as it's not anymore
related to this mailing list operatiorns.

--
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.
I'm not interested in your website anymore.
If you need cookies, bake them yourself.
___
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