In message <57579895-55ef-439d-9e10-2f2b349e5...@isoc.org>, Dan York writes:
> Mikael,
>
> On Oct 15, 2016, at 11:22 AM, Mikael Abrahamsson
> mailto:swm...@swm.pp.se>> wrote:
>
> These kinds of migration scenarios to newer algorithms MUST be hashed
> out, because otherwise we're never going to be
Mikael,
On Oct 15, 2016, at 11:22 AM, Mikael Abrahamsson
mailto:swm...@swm.pp.se>> wrote:
These kinds of migration scenarios to newer algorithms MUST be hashed out,
because otherwise we're never going to be able to deploy new algorithms (and
per previous experience, it seems we want to change
Hi Mikael,
> I via these found RFC4035:
>
> "If the resolver does not support any of the algorithms listed in an
>authenticated DS RRset, then the resolver will not be able to verify
>the authentication path to the child zone. In this case, the
>resolver SHOULD treat the child zone as
In message <20161016223109.6856756c8...@rock.dv.isc.org>, Mark Andrews writes:
>
> In message
> ,
> =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= writes:
> > I will be happy to do that, stay tuned as I need to create a special
> > signer for it :-)
> >
> > Olafur
>
> dnssec-signzone + awk + dnsse
In message
,
=?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= writes:
> I will be happy to do that, stay tuned as I need to create a special
> signer for it :-)
>
> Olafur
dnssec-signzone + awk + dnssec-dsfromkey works well.
e.g.
awk '$4 == "RRSIG" && $6 == 8 { $6 = 99 }
$4 == "DNSKEY" && $7 ==
I will be happy to do that, stay tuned as I need to create a special
signer for it :-)
Olafur
On Sun, Oct 16, 2016 at 4:16 AM, Mikael Abrahamsson
wrote:
> On Sat, 15 Oct 2016, Ólafur Guðmundsson wrote:
>
> I have domains signed by all combinations of signing algorithms and DS
>> digests as we
On Sat, 15 Oct 2016, Ólafur Guðmundsson wrote:
I have domains signed by all combinations of signing algorithms and DS
digests as well as Nsec variants
Ds-n.alg-m-nsec.dnssec-test.org
Replace n with 1..4
M with 1..14
Nsec is one of Nsec nsec3 none
I'd be veryinterested if you could create an a
On Sun, 16 Oct 2016, Geoff Huston wrote:
so I have three tests:
A: a validly-signed ECDSA P-256 domain
B: an invalidly-signed ECDSA P-256 domain
C: an unsigned control
now if the resolver does NOT recognise ECDSA we should see a fetch for A, B and
C (as they treat both A and B as if they w
I have domains signed by all combinations of signing algorithms and DS
digests as well as Nsec variants
Ds-n.alg-m-nsec.dnssec-test.org
Replace n with 1..4
M with 1..14
Nsec is one of Nsec nsec3 none
Ólafur
sent from phone
On Oct 15, 2016 17:29, "Geoff Huston" wrote:
>
> > On 16 Oct. 2016, at
> On 16 Oct. 2016, at 2:53 am, Mikael Abrahamsson wrote:
>
> On Sat, 15 Oct 2016, Ralf Weber wrote:
>
>> Geoff Houston did some research here some years ago and just did an update
>> to his findings. You might want to look at:
>> http://www.potaroo.net/ispcol/2016-10/ecdsa-v2.html
>
> Do
Hi,
not sure if it's exactly what you're looking for, but there's
https://github.com/CZ-NIC/deckard for (generic) resolver testing.
It mocks the environment for the tested binary, so you'll have to
provide a configuration template for dnsmasq.
Marek
On Fri, Oct 14, 2016 at 11:22 PM, Mikael Abrah
On Sat, 15 Oct 2016, Ralf Weber wrote:
Geoff Houston did some research here some years ago and just did an update to
his findings. You might want to look at:
http://www.potaroo.net/ispcol/2016-10/ecdsa-v2.html
Do we know how many experiments failed because the resolver erroneously
re
Moin!
On 15 Oct 2016, at 10:22, Mikael Abrahamsson wrote:
set up a domain with a algorithm ID nobody will ever implement
(reserve it if need be), and check that this domain returns as
unvalidated (as per SHOULD in the RFC).
Geoff Houston did some research here some years ago and just did an
u
On Sat, 15 Oct 2016, Ray Bellis wrote:
I hadn't considered algorithm-specific tests, but the app could in
theory include tests for whether zones known to be signed with specific
algorithms can be correctly resolved with +AD returned.
What I would like to see are tests like:
set up a domain w
> On 15 Oct 2016, at 07:22, Mikael Abrahamsson wrote:
>
>
> Hi,
>
> we have a deployment of home gateways, based on OpenWrt BB that uses dnsmasq
> v2.71 as resolver, with DNSSEC validation turned on. It seems some
>
> Dnsmasq v2.71 does not support ECDSA. A rather large CDN uses ECDSA only.
On 15/10/2016 01:22, Mikael Abrahamsson wrote:
> So... my question to you fine people is:
>
> Is there any (existing and freely available) testing suite I can run
> against my chosen resolver that tests all the SHOULDs and MUSTs
> regarding DNSSEC validation, including future proofing for new a
Hi,
we have a deployment of home gateways, based on OpenWrt BB that uses
dnsmasq v2.71 as resolver, with DNSSEC validation turned on. It seems some
Dnsmasq v2.71 does not support ECDSA. A rather large CDN uses ECDSA only.
I also found bug reports for Debian with same problem, because they al
17 matches
Mail list logo
