Re: DNSSEC upgrade

[Mark Elkins]

Waiting twice the TTL is the safe option. Start counting from when you 
see the new DS record in the parent. To be even more pedantic, start 
counting after all authoritative Nameservers have the new DS record...

Quite easy to do from a script.

And the recommendation to move to ecdsa-p256-sha256 is a good one - 
makes you a lot less appetising to be used in a DNS amplification attack.


On 4/30/21 3:05 AM, Edwardo Garcia wrote:

Halo Tony,
Thank you, wow ecdsa-p256-sha256 produce keys 1/10th the size of rsa, 
strange how this better but we have made change as
from your howto, thank you, now 24 hour and all seems ok from what we 
tell, and the test site says all good.


One question however it talk about longest TTL, does this mean also 
root TLD zones (.com, .net) which from memory are 48 hours, so before 
we delete old keys we need wait 48 hours, even though our zone TTL was 
24 ?


Thank you, wow much much easy than I hoped for :-)

On Wed, Apr 28, 2021 at 12:08 PM Tony Finch > wrote:


Edwardo Garcia mailto:wdgar...@gmail.com>> wrote:
>
> Many year ago we set up DNSSEC, our key were generated with sha1
as was
> recommended way back all them years. We too are not DNSSEC guru,
so some
> answer may be simple

Well, you are going to do an algorithm rollover, which is one of
the more
tricky things you can do with DNSSEC. So, plan to do some testing,
a trial
run, with a spare zone that you can break without worrying.

If you like to understand things by getting an idea of the wider
context
then there are a couple of RFCs on the general subject of key
rollovers.
The parts that are most relevant are the algorithm rollover
section in RFC
6781 and the double-KSK section in RFC 7583.

https://tools.ietf.org/html/rfc6781

https://tools.ietf.org/html/rfc7583


DNSSEC has got easier since those RFCs were written, so you might
as well
just skip to the howto bits below :-) It turns out, I wrote most
of this
reply over a year ago...

> Also we use ZSK -b 1024 and KSK -b 4096
> even modern google from apnic show example  ZSK of only 1024? is
this still
> secure?

The current recommendation for DNSSEC algorithms is:

  * you already know you want to choose something based on sha256
- it's
    secure enough, so there's no need for bigger hashes

  * ecdsa-p256-sha256 (13) is the best choice, because it is widely
    supported and produces small signatures

  * if you must use RSA, use 2048 bit keys for both zsk and ksk.
1024 bits
    is not secure; 2048 has a roughly comparable security level to
sha256
    (112ish bits vs 128 bits); 4096 is big and slow and probably
not worth
    the cost

  * I would like to be able to deploy ed25519 (a better elliptic curve
    than p256) but it is not yet supported well enough

> Is best practise for doing this, replacing the keys completely,
more or
> less like start fresh again?
>
> We do use inline signing and automatic maintain.

I did a wholesale algorithm rollover from RSASHA1 to p256 around
the end
of 2019 and I wrote an algorithm rollover guide for colleagues in
other
parts of our university who run their own DNS. It's basically
three steps
with lots of waiting in between:

https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html


The "Semi-automated DS updates" section probably isn't relevant to
you,
and the "Future" section has been made obsolete by dnssec-policy.
But the
rest of it should guide you through the essentials.

(Also, the RIPE NCC does now support CDS records.)

And use these DNS checking services to verify that it is working as
expected:

https://dnsviz.net/ 

https://zonemaster.net/ 

Tony.
-- 
f.anthony.n.finch  mailto:d...@dotat.at>>

https://dotat.at/ 
Rattray Head to Berwick upon Tweed: North or northeast 4 or 5,
occasionally 3 later. Slight or moderate. Showers. Good.


___
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 James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.826010496 
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za 



Posix SystemsVCARD for MJ Elkins

___
Please visit 

Re: DNSSEC upgrade

[Edwardo Garcia]

Halo Tony,
Thank you, wow ecdsa-p256-sha256 produce keys 1/10th the size of rsa,
strange how this better but we have made change as
from your howto, thank you, now 24 hour and all seems ok from what we tell,
and the test site says all good.

One question however it talk about longest TTL, does this mean also root
TLD zones (.com, .net) which from memory are 48 hours, so before we delete
old keys we need wait 48 hours, even though our zone TTL was 24 ?

Thank you, wow much much easy than I hoped for :-)

On Wed, Apr 28, 2021 at 12:08 PM Tony Finch  wrote:

> Edwardo Garcia  wrote:
> >
> > Many year ago we set up DNSSEC, our key were generated with sha1 as was
> > recommended way back all them years. We too are not DNSSEC guru, so some
> > answer may be simple
>
> Well, you are going to do an algorithm rollover, which is one of the more
> tricky things you can do with DNSSEC. So, plan to do some testing, a trial
> run, with a spare zone that you can break without worrying.
>
> If you like to understand things by getting an idea of the wider context
> then there are a couple of RFCs on the general subject of key rollovers.
> The parts that are most relevant are the algorithm rollover section in RFC
> 6781 and the double-KSK section in RFC 7583.
>
> https://tools.ietf.org/html/rfc6781
> https://tools.ietf.org/html/rfc7583
>
> DNSSEC has got easier since those RFCs were written, so you might as well
> just skip to the howto bits below :-) It turns out, I wrote most of this
> reply over a year ago...
>
> > Also we use ZSK -b 1024 and KSK -b 4096
> > even modern google from apnic show example  ZSK of only 1024? is this
> still
> > secure?
>
> The current recommendation for DNSSEC algorithms is:
>
>   * you already know you want to choose something based on sha256 - it's
> secure enough, so there's no need for bigger hashes
>
>   * ecdsa-p256-sha256 (13) is the best choice, because it is widely
> supported and produces small signatures
>
>   * if you must use RSA, use 2048 bit keys for both zsk and ksk. 1024 bits
> is not secure; 2048 has a roughly comparable security level to sha256
> (112ish bits vs 128 bits); 4096 is big and slow and probably not worth
> the cost
>
>   * I would like to be able to deploy ed25519 (a better elliptic curve
> than p256) but it is not yet supported well enough
>
> > Is best practise for doing this, replacing the keys completely, more or
> > less like start fresh again?
> >
> > We do use inline signing and automatic maintain.
>
> I did a wholesale algorithm rollover from RSASHA1 to p256 around the end
> of 2019 and I wrote an algorithm rollover guide for colleagues in other
> parts of our university who run their own DNS. It's basically three steps
> with lots of waiting in between:
>
> https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html
>
> The "Semi-automated DS updates" section probably isn't relevant to you,
> and the "Future" section has been made obsolete by dnssec-policy. But the
> rest of it should guide you through the essentials.
>
> (Also, the RIPE NCC does now support CDS records.)
>
> And use these DNS checking services to verify that it is working as
> expected:
>
> https://dnsviz.net/
>
> https://zonemaster.net/
>
> Tony.
> --
> f.anthony.n.finchhttps://dotat.at/
> Rattray Head to Berwick upon Tweed: North or northeast 4 or 5,
> occasionally 3 later. Slight or moderate. Showers. Good.
>
>
___
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: Deprecating BIND 9.18+ on Windows (or making it community improved and supported)

[Richard T.A. Neal]

I would personally be very sad to see the end of BIND for Windows, but I don’t 
underestimate the challenges the ISC Team has in maintaining it.

Unfortunately I'm a VB.NET hobbyist programmer rather than a C/C++ developer so 
I can't speak to the usefulness of the following statement, but the latest 
version of Visual Studio 2019 does appear to support both C11 and C17:
https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/

The installer problem is probably the easiest to fix, but I know it's a very 
small part of the overall headache. Caphyon offer free use of their Advanced 
Installer (which is what I use for WinBIND) and that can cope quite happily 
with installing & uninstalling running services.

The WSL2 option is an interesting one and not something I'd ever considered.

If we end up with option (a), which I suspect is the most likely outcome, I 
would at least like to offer to be the maintainer of the "BIND 9 on Windows via 
WSL2" documentation, but only if we can come up with a catchier name 

Richard.

-Original Message-
From: bind-users  On Behalf Of Ondrej Surý
Sent: 29 April 2021 12:36 pm
To: BIND Users 
Subject: Deprecating BIND 9.18+ on Windows (or making it community improved and 
supported)

Hi,

we’ve been discussing the /subj for quite some time and we are either thinking 
about deprecating the BIND 9 on Windows completely or just handing it over to 
the “community supported” level.

There are couple reasons for the move:

* Neither the VisualStudio 2017 which we use nor VS2019 supports the C11 
features we extensively use (stdatomic.h) which makes us to write a horrible 
horrible shims on top of Windows API
* No BIND 9 developer uses Windows even as secondary platform
* BIND 9 doesn’t compile on Windows 10 nor with VS2019 and that would require 
extensive work
* Windows now has WSL2 
(https://docs.microsoft.com/en-us/windows/wsl/install-win10) that can be used 
to run BIND 9 natively

We think that the resources that would require us to support new Windows and 
Visual Studio versions would be better spent elsewhere and therefore we would 
like to deprecate the official support for Windows since BIND 9.18 (the next 
ESV, to be released in 2022), the Windows support for BIND 9.16 will be kept 
intact.

Now, there are two options:

a) The support will be completely dropped and the official way to run BIND 9 on 
Windows would be using WSL2
b) A volunteer will step up and improve the Windows implementation to support 
newer platforms and make it up to par with POSIX platforms.

1. Let me be absolutely clear here - we are not interested to keep the Windows 
port just on the life support, that would miss the point. It has been neglected 
for too long and if we are to keep it, there are several other areas that would 
need an improvement - the installer, the system integration and the build 
system would have to be extensively improved as well.

Thanks,
Ondrej
--
Ondřej Surý (He/Him)
ond...@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

Re: Deprecating BIND 9.18+ on Windows (or making it community improved and supported)

[Ondřej Surý]

> On 29. 4. 2021, at 15:42, Timothe Litt  wrote:
> 
> Would reducing support to just the diagnostic tools be a helpful middle 
> ground?


Not really. The tools use the same internal libraries for networking. And it 
would bring more complexity and not less complexity.

There’s no middle ground - it’s either making Windows the first class citizen 
or no citizen choice here.

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.


___
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: Deprecating BIND 9.18+ on Windows (or making it community improved and supported)

[@lbutlr]

On 29 Apr 2021, at 05:35, Ondřej Surý  wrote:
> * Windows now has WSL2 
> (https://docs.microsoft.com/en-us/windows/wsl/install-win10) that can be used 
> to run BIND 9 natively

I'd suggest this be the first listed reason as it pretty much makes all the 
other reasons irrelevant. OTOH, I don't have a dog in this race.


-- 
And she was drifting through the backyard And she was taking off her
dress And she was moving very slowly Rising up above the earth

___
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: Deprecating BIND 9.18+ on Windows (or making it community improved and supported)

[Timothe Litt]

I gave up on running named on Windows long ago, so I generally support
this direction.

However, I do use the diagnostic tools (dig, delv, rndc, nsupdate) for
troubleshooting.  It can be helpful to diagnose from the client
environment (e.g. thru the same firewalls, anti-virus, buggy network
stack, and APIs).  The BIND tools are better than the windows tools, 
and
using the same tools everywhere is always beneficial.

Would reducing support to just the diagnostic tools be a helpful middle
ground?

It seems to me that they're much simpler (mostly if not all
single-threaded) and easier to maintain.  Do they have the same VS
issues? (I haven't built on windows for some time.)

I don't include tools that assume a local named instance in the
"diagnostic" category - e.g. named-journalprint, dnstap, etc. 

First order discriminant function is whether the tool talks to the
network (to make DNS queries[no, not named!], including control) - yes:
prefer to keep

FWIW - YMMV.

Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

On 29-Apr-21 07:35, Ondřej Surý wrote:
> Hi,
>
> we’ve been discussing the /subj for quite some time and we are either 
> thinking about deprecating the BIND 9 on Windows completely or just handing 
> it over to the “community supported” level.
>
> There are couple reasons for the move:
>
> * Neither the VisualStudio 2017 which we use nor VS2019 supports the C11 
> features we extensively use (stdatomic.h) which makes us to write a horrible 
> horrible shims on top of Windows API
> * No BIND 9 developer uses Windows even as secondary platform
> * BIND 9 doesn’t compile on Windows 10 nor with VS2019 and that 
would require extensive work
> * Windows now has WSL2 
> (https://docs.microsoft.com/en-us/windows/wsl/install-win10) that can be used 
> to run BIND 9 natively
>
> We think that the resources that would require us to support new Windows and 
> Visual Studio versions would be better spent elsewhere and therefore we would 
> like to deprecate the official support for Windows since BIND 9.18 (the next 
> ESV, to be released in 2022), the Windows support for BIND 
9.16 will be kept intact.
>
> Now, there are two options:
>
> a) The support will be completely dropped and the official way to run BIND 9 
> on Windows would be using WSL2
> b) A volunteer will step up and improve the Windows implementation to support 
> newer platforms and make it up to par with POSIX platforms.
>
> 1. Let me be absolutely clear here - we are not interested to keep the 
> Windows port just on the life support, that would miss the point. It has been 
> neglected for too long and if we are to keep it, there are several other 
> areas that would need an improvement - the installer, the system integration 
> and the build system would have to be extensively improved as well.
>
> Thanks,
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org


OpenPGP_signature
Description: OpenPGP digital 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

Deprecating BIND 9.18+ on Windows (or making it community improved and supported)

[Ondřej Surý]

Hi,

we’ve been discussing the /subj for quite some time and we are either thinking 
about deprecating the BIND 9 on Windows completely or just handing it over to 
the “community supported” level.

There are couple reasons for the move:

* Neither the VisualStudio 2017 which we use nor VS2019 supports the C11 
features we extensively use (stdatomic.h) which makes us to write a horrible 
horrible shims on top of Windows API
* No BIND 9 developer uses Windows even as secondary platform
* BIND 9 doesn’t compile on Windows 10 nor with VS2019 and that would require 
extensive work
* Windows now has WSL2 
(https://docs.microsoft.com/en-us/windows/wsl/install-win10) that can be used 
to run BIND 9 natively

We think that the resources that would require us to support new Windows and 
Visual Studio versions would be better spent elsewhere and therefore we would 
like to deprecate the official support for Windows since BIND 9.18 (the next 
ESV, to be released in 2022), the Windows support for BIND 9.16 will be kept 
intact.

Now, there are two options:

a) The support will be completely dropped and the official way to run BIND 9 on 
Windows would be using WSL2
b) A volunteer will step up and improve the Windows implementation to support 
newer platforms and make it up to par with POSIX platforms.

1. Let me be absolutely clear here - we are not interested to keep the Windows 
port just on the life support, that would miss the point. It has been neglected 
for too long and if we are to keep it, there are several other areas that would 
need an improvement - the installer, the system integration and the build 
system would have to be extensively improved as well.

Thanks,
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org



signature.asc
Description: Message signed with OpenPGP
___
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