and we're saying DNSSEC
now is all about on-the-fly signing, then that discussion of course
changes).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
seem like a
pretty high value to lower bound TTLs at.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
https://www.icann.org/news/announcement-2017-09-27-en
Thought this might be relevant to some.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
oth spaces.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
plications can tell the user what went
wrong, instead of just throwing a DNS failure. If there is need to update
the DNS specs for this to be possible, then that should be done.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
DNSOP mailing
there is benefit in signing your zone now, there wasn't as
much before when nobody was validating.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
However, introducing a really high head start for IPv6 in this setup is
not desireable either, let's say 500ms head start to handle that the
authoritative DNS server is 400ms RTT away. This would give a bad user
experience in some other cases.
Thoughts?
--
Mikael Abrahamssonema
if ICANN could write a document outlining how to do
this and perhaps even provide FOSS example code.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
life and then DNSSEC fails is
just not usable for things that don't have active human intervention in
its configuration and setup.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman
you're thinking of here. Can we get a
solution that does that, that isn't a DDOS amplification vector or
something else hugely problematic?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org
On Wed, 16 Nov 2016, George Michaelson wrote:
I feel this is a corner case. My experience with 'mom' whitegoods is
that they age out much faster than the 10+ year case. Shops do not hold
electronic goods for sale that long, if its old but unboxed, you have
taken yourself into a dark alley
?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
users to do in order to make their device
work again?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
an algorithm called "99" (or
something), and we could test that. Anyone not loading the "99" resource
is violating the "SHOULD", even if they understand ECDSA.
This would investigate ratio of problems when we want to introduce a new
algorithm in the future.
--
Mi
the last of these two, because they're hindering
rollout of new algorithms. I'd like to understand how big this breakage
is.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
reported error for ECDSA signed domains?
From reading Geoffs text, it's not obvious to me that this error case is
caught by his tests?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman
previous experience, it seems we want to change them every 5-10
years).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
19 matches
Mail list logo