On Wed, Apr 29, 2020 at 12:49 AM Paul Vixie wrote:
> On Wednesday, 29 April 2020 01:17:04 UTC Shumon Huque wrote:
> > ...
> >
> > Paul - I guess I'm missing some background here. In what sense did
> > getting DS working throw validating stubs overboard? Do you mean it
> > took the focus away from
My understanding of the draft is that it attempts to prevent a key to sign
a RRset it is not necessarily authoritative for. I think the WG should work
on this, and support adoption of the draft. I am happy to review further
version of the draft.
Yours,
Daniel
On Tue, Apr 28, 2020 at 4:27 PM Wes Ha
On Wed, 29 Apr 2020, Paul Vixie wrote:
no. i mean that the decision to require a "clear path" for DNSSEC meant that
no DNSSEC-dependent application has ever received investment. for example,
DANE is interesting in the SMTP market because that's small and geeky, but
will never be adopted by the W
On Wed, Apr 29, 2020 at 11:34 AM Paul Wouters wrote:
> On Wed, 29 Apr 2020, Paul Vixie wrote:
>
> > no. i mean that the decision to require a "clear path" for DNSSEC meant
> that
> > no DNSSEC-dependent application has ever received investment. for
> example,
> > DANE is interesting in the SMTP m
to the list, after Paul Wouters replied to me privately.
I realize now this was Paul W responding to Paul V. I thought in
my response below I was replying again to Paul V!
My apologies ..
Shumon.
On Wed, Apr 29, 2020 at 11:45 AM Shumon Huque wrote:
> On Wed, Apr 29, 2020 at 11:34 AM Paul Wout
Hi,
I discovered this draft during the interim meeting. We had similar thoughts
in our "Recommendations for DNSSEC Resolvers Operators". Our motivation for
supporting this work are that it 1) improves the reliability of the
resolution as well as 2) removes the temptation to (inadvertently) break
Following up on Petr's suggestion that the "DNSEC Transparency" mechanism
is documented
and somewhat tested.
I totally agree on this idea and can assure the WG that if this draft is
adopted, this will be one of the
conditions on progressing forward.
tim
On Thu, Apr 23, 2020 at 1:46 AM Petr Špač
Tim Wicinski wrote
Mon, 20 Apr 2020 14:03:03 -0400:
> This starts a Call for Adoption for draft-pwouters-powerbind
I am interested in the idea of a DNSSEC transparency system, i.e.
externally verifiable append-only logs of observed DNSSEC data, and do
support adoption of draft-pwouters-powerbind
Is there an RFC or draft that talks about what the right thing is to do when an
unsigned CNAME points to a record in a signed zone?
That is, suppose we are doing validation. The CNAME doesn’t validate, because
it’s not signed. When we look up the record the CNAME points to, do we set the
DO bit
On Wed, Apr 29, 2020 at 5:50 PM Ted Lemon wrote:
> Is there an RFC or draft that talks about what the right thing is to do
> when an unsigned CNAME points to a record in a signed zone?
That is, suppose we are doing validation. The CNAME doesn’t validate,
> because it’s not signed. When we look u
> On 30 Apr 2020, at 07:50, Ted Lemon wrote:
>
> Is there an RFC or draft that talks about what the right thing is to do when
> an unsigned CNAME points to a record in a signed zone?
>
> That is, suppose we are doing validation. The CNAME doesn’t validate, because
> it’s not signed. When we
On Apr 29, 2020, at 6:56 PM, Shumon Huque wrote:
> I believe a validating resolver always sets the DO-bit in outbound queries.
> The answer in your example can't be authenticated (i.e. no AD bit can be set)
> because not all the answers (namely the CNAME) in the response have been
> authenticat
On Apr 29, 2020, at 7:27 PM, Mark Andrews wrote:
> provably insecure: proved no DS records at a delegation at or above the
> name, proved that there are only
> unsupported algorithms in the DS RRset at a delegation at or above the
> name, not under a trust-anchor.
When I’m talking about
On 4/29/2020 5:50 PM, Ted Lemon wrote:
Is there an RFC or draft that talks about what the right thing is to do when an
unsigned CNAME points to a record in a signed zone?
That is, suppose we are doing validation. The CNAME doesn’t validate, because
it’s not signed. When we look up the record t
On Wed, Apr 29, 2020 at 7:30 PM Ted Lemon wrote:
> The question is, if the stub resolver can validate, and has been asked to
> validate, in that case what do we do if the CNAME is not in a secure zone?
> Your response makes it sound like you know the answer, but I don’t think
> it’s specified any
On Wed, Apr 29, 2020 at 8:02 PM Michael StJohns
wrote:
> See this chain
> https://mailarchive.ietf.org/arch/msg/dnsext/_kxMmGeBUI8OW03tWlcgcCW9QlU/
> (Yup - 12 years ago).
>
> I don't think I ever managed to convince anyone this was a problem.
>
Mike, perhaps there was some confusion on this poi
In article
you write:
>
>My understanding of the draft is that it attempts to prevent a key to sign
>a RRset it is not necessarily authoritative for.
If that's what it means, that's what it should say. As I read it, the flag it
defines
says that the zone will only sign NS and DS and perhaps th
On Tue, Apr 28, 2020 at 06:26:54PM -0400, John Levine wrote:
> I think we will find that the assumption that TLD zone files are
> delegation-only does not hold up very well in practice, so I am
> wondering how useful a hack to technically enforce it would really be.
There are indeed some TLDs whi
On Apr 29, 2020, at 7:12 PM, Shumon Huque wrote:
> Mike, perhaps there was some confusion on this point 12 years ago, but
> deployed validator code all agree on what the state is. I encourage
> implementers to confirm (or correct me if I misstate something).
Absolutely. You only get the AD bit
> On Apr 29, 2020, at 23:39, Viktor Dukhovni wrote:
>
>
> For example, the spec could exclude domain
> names that start with "_" or "_sentinel". And the sentinel names could
> then all live there.
It already does, because the _prefix really belongs to the domain and is never
a delegation.
> On Apr 29, 2020, at 11:46 PM, Paul Wouters wrote:
>
>> For example, the spec could exclude domain
>> names that start with "_" or "_sentinel". And the sentinel names could
>> then all live there.
>
> It already does, because the _prefix really belongs to the domain and is
> never a delegatio
21 matches
Mail list logo
