To begin...thanks, Frederico, I was trying to find that case but had forgotten
which ccTLD was involved. (Web searches failed me...)
On 11/14/17, 23:11, "DNSOP on behalf of Paul Wouters" wrote:
>On Wed, 15 Nov 2017, Frederico A C Neves
On Wed, 15 Nov 2017, Frederico A C Neves wrote:
Yes. And add to that cases were TLDs rolled just before adding to the
root.
So what is the security model then?
Let's say .example rolled and now has a bad DS.
Someone overrides this with a local trust anchor so the domain does not
go dark.
-
On Mon, Nov 13, 2017 at 03:45:30PM +, Edward Lewis wrote:
> On 11/9/17, 12:48, "DNSOP on behalf of Evan Hunt" behalf of e...@isc.org> wrote:
>
> >On Thu, Nov 09, 2017 at 03:48:26PM +0100, Petr Špaček wrote:
> >> Nice write-up Edward! You have nicely
On 11/13/17, 21:15, "DNSOP on behalf of Paul Wouters" wrote:
>> I'm not sure that the need for robustness outweighs the expectation of
>> someone explicitly adding a trust anchor anymore.
>But that’s not your call to make, but the call of
On Mon, 13 Nov 2017, Paul Vixie wrote:
whether DNS can adapt remains to be seen. but declaring working and
desired configurations such as split-DNS to be undesireable, or breaking
them, or failing to support them, are head-in-sand moves. the internet
historically responds to head-in-sand
Paul Wouters wrote:
I'm not sure that the need for robustness outweighs the expectation
of someone explicitly adding a trust anchor anymore.
But that’s not your call to make, but the call of the entity deciding
to put in that hard coded trust anchor.
We just ask you not to block us from
>
> I'm not sure that the need for robustness outweighs the expectation of
> someone explicitly adding a trust anchor anymore.
But that’s not your call to make, but the call of the entity deciding to put in
that hard coded trust anchor.
We just ask you not to block us from doing as we have
On 11/9/17, 12:48, "DNSOP on behalf of Evan Hunt" wrote:
>On Thu, Nov 09, 2017 at 03:48:26PM +0100, Petr Špaček wrote:
>> Nice write-up Edward! You have nicely summarized why Mark and me agree
>> that validator should use longest