On Mon, 27 Jun 2022, John Levine wrote:
spec, it would take a long time for the changes to percolate out into
the field. There is still plenty of software using TLS 1.1 which was
published in 2006 and deprecated a year ago.
That does not apply to tor nodes though. These are forced to have
It appears that Peter Thomassen said:
>
>
>On 6/27/22 22:05, John Levine wrote:
>> But there is a
>> great deal of software that expects the names it uses to look like
>> hostnames, and won't work with anything else.
>
>The software for new applications which would use a _foo pseudo-TLD
On Mon, 27 Jun 2022, Peter Thomassen wrote:
In a multi-signer setup, this means that a single provider can (accidentally
or maliciously) roll the DS record at the parent.
That's a good point.
I thus propose to update RFC 7344 along the lines of (2), such that it is
REQUIRED to retrieve
On Jun 27, 2022, at 16:34, Michael StJohns wrote:
>
> It was true once! :-) That's why I said "I think" - too many twiddles to
> the DNS to keep tract of.
As of IETF 101, these twiddles are now called “humps”
Paul
___
DNSOP mailing list
On 6/27/22 22:05, John Levine wrote:
But there is a
great deal of software that expects the names it uses to look like
hostnames, and won't work with anything else.
The software for new applications which would use a _foo pseudo-TLD namespace is not yet written.
It is for future
On 6/27/2022 4:31 PM, John Levine wrote:
It appears that Michael StJohns said:
I suggest that reserving "_*" names is redundant as (I *think* - I
didn't go looking for the reference?) strings beginning with an
underscore can only be used in left-most components of a DNS name.
Dunno where you
It appears that Michael StJohns said:
>I suggest that reserving "_*" names is redundant as (I *think* - I
>didn't go looking for the reference?) strings beginning with an
>underscore can only be used in left-most components of a DNS name.
Dunno where you heard that, but it's completely not
Folks -
It's either time to put a stake through the heart of this DNS vampire
that rises from the grave every 6 months, or to push it for
publication. Given that in 8 years it has yet to gain enough traction
for publication, perhaps we de-adopt the draft back into the caring
hands of its
On 6/27/2022 4:05 PM, John Levine wrote:
It appears that Peter Thomassen said:
I am proposing to reserve all top-level underscore labels (_*) for special use.
Why?
While I don't think that reserving underscore names will break anything that is
not already broken, I also don't see what
It appears that Peter Thomassen said:
>I am proposing to reserve all top-level underscore labels (_*) for special
>use. Why?
While I don't think that reserving underscore names will break anything that is
not already broken, I also don't see what problem it solves.
Everything you say about
Dear DNSOP,
RFC 7344 describes DS rollovers using CDS/CDNSKEY records. It does not
prescribe how the CDS/CDNSKEY records should be retrieved. On the contrary, it
is fully left open (Section 6.1):
How the Parental Agent gets the CDS/CDNSKEY RRset may differ. Below
are two examples of
I am proposing to reserve all top-level underscore labels (_*) for special use.
Why?
My understanding of the problem is:
(1) There are several naming systems. Some of them can be enabled/disabled via nsswitch;
others are completely "disconnected" from OS resolution, but still use dotted
On 6/22/22 08:36, Brian Dickson wrote:
The whole point of the bootstrap mechanism is to onboard the /initial/ DS
record for a particular domain securely.
Once the initial DS is present, there is no further need for bootstrap.
For a single domain, the only purpose of doing what you propose
On 6/22/22 14:40, Paul Wouters wrote:
Unfortunately, the reverse zone is very often out of reach for those who use
the IP range and trying to do classless reverse delegation (RFC 2317) for those
who have less than a /24 is even harder to get.
That's exactly right, DNS operators will in
On Jun 27, 2022, at 13:40, Peter Thomassen wrote:
> Thinking about it, perhaps there's no reason for normative language here. If
> others agree, please let me know and I'll change to lowercase "should".
If you are going to downgrade the requirement, MAY seems better than should,
perhaps
Hi Rubens,
On 6/22/22 05:29, rubensk=40nic...@dmarc.ietf.org wrote:
On 22 Jun 2022, at 00:07, John Levine mailto:jo...@taugh.com>> wrote:
In practice, I doubt that enough reverse zones are signed or that the
provisoning crudware that people use for reverse zones would work
often enough to be
On Fri, Jun 24, 2022 at 05:31:28PM +, Eric Vyncke (evyncke) wrote:
> Dear DNSOP,
>
> As this ADD WG document relies on draft-ietf-dnsop-svcb-https from the
> DNSOP WG, as the responsible AD for the ADD WG, I will appreciate your
> review of this short IETF draft.
>
> Abstract
>
>
On 6/27/2022 11:29 AM, Ted Lemon wrote:
I think your instinct is correct, Tim. It’s not an optimization to
bypass discussion as part of a call for adoption. By asking us to
consider six drafts at once, and discuss none of them, you create a
strong likelihood of insufficient review.
+1 - the
On Mon, 27 Jun 2022, Ted Lemon wrote:
I think your instinct is correct, Tim. It’s not an optimization to bypass
discussion as part of a call for adoption. By asking us to
consider six drafts at once, and discuss none of them, you create a strong
likelihood of insufficient review.
I also
I think your instinct is correct, Tim. It’s not an optimization to bypass
discussion as part of a call for adoption. By asking us to consider six
drafts at once, and discuss none of them, you create a strong likelihood of
insufficient review.
On Mon, Jun 27, 2022 at 03:45 Tim Wicinski wrote:
>
All
We have six documents that have requested adoption from the working group.
My opinion is that we send out adoption calls for all of these and let the
working group sort it out, but was told that is just crazy. Since Warren
loves these poll things, we put another one together on all the
21 matches
Mail list logo
