Roy Arends writes:
> What is missing is how validators/validating resolvers should behave
> when presented with SHA1.
Yep; see the response to Jim.
[the draft was a starting place, of course; I'm sure there will be more
text needed. "send text" is always an adequate thing to do]
--
Wes
Jim Reid writes:
> Wes, I'm all for killing SHA1. Though the mechanism might need a
> rethink. We probably should have a simpler way to add/remove DNSSEC
> crypto algorithms. IIRC Paul Hoffman explained the problem a year or
> so ago when new code points were needed for the latest GOST
>
How to privatise the commons in names.
1) release a browser with remotely enable-able features, initially disabled
2) when you hit 95% penetration, enable the feature.
If the omnibar in the dominant browser had a selection logic akin to
nsswitch.conf or resolver.conf config options, this debate
On Kerberos, we need to note that one use case of Kerberos is Microsoft Active
Directory; MS AD is behind a number of name collisions that happened in the
2012 root zone expansion, including one string that will likely never show the
light of day in the root (.corp). So, this might be the
So I think this discussion might benefit from also
remembering that we have a decades-long and widely
deployed history of IETF standard name forms that
use the same name syntax as domain names that may
or may not be related to names used in the DNS.
Kerberos [1] does exactly that.
And the sky
David Conrad wrote on 2022-08-13 18:55:
Paul,
On Aug 13, 2022, at 3:32 PM, Paul Vixie
wrote:
i suggest that we adopt the technology "domain names (which is a concept that
precedes DNS itself)" whenever we are trying to talk about the name space as
distinct from the protocol.
Sorry,
On 14/08/2022 02:55, David Conrad wrote:
As John Levine points out, this isn’t a technology issue: it is
social/politica/economic/bureaucratic
I believe the above statement is incorrect in referring to
"this" issue in the singular. There is more than one thing
in play here and ignoring all
Paul,
On Aug 13, 2022, at 3:32 PM, Paul Vixie
wrote:
> i suggest that we adopt the technology "domain names (which is a concept that
> precedes DNS itself)" whenever we are trying to talk about the name space as
> distinct from the protocol.
Sorry, which technology are you suggesting we
On Aug 13, 2022, at 5:40 PM, Stephen Farrell wrote:
> I've no particular fondness for .alt, nor do I know if
> the GNU people could live with gnu.alt but I think the
> IETF (and not ICANN) really ought be able to, and should,
> carve out something like .alt for folk who want to not
> use the DNS
To paraphrase and bastardise an old saying:
"Domains are powerful. All the good ones are taken"
I think Paul V is right that the powerful concept here is the domain
concept, scope and hierarchy.
G
___
DNSOP mailing list
DNSOP@ietf.org
Hiya,
On 13/08/2022 23:32, Paul Vixie wrote:
warren's .ALT proposal can begin to undo that harm. internet standards
should describe roads not walls. i am no fan of blockchain naming, but
i'd like those
systems to reach the market rather than be prevented from doing so.
A strong +1 to the
Paul Hoffman wrote on 2022-08-13 15:42:
On Aug 13, 2022, at 3:32 PM, Paul Vixie
wrote:
i suggest that we adopt the technology "domain names (which is a concept that
precedes DNS itself)" whenever we are trying to talk about the name space as
distinct from the protocol.
The term
see inline.
Warren Kumari wrote on 2022-08-11 10:20:
Warren’s meta-comment -[ Please read this ]-
thanks for this, it was marvelously clarifying. i have a quibble which
might best be taken as a potential warning. but first, let me emphasize:
TL;DR: Domain names are older than the DNS
On Aug 13, 2022, at 3:32 PM, Paul Vixie
wrote:
> i suggest that we adopt the technology "domain names (which is a concept that
> precedes DNS itself)" whenever we are trying to talk about the name space as
> distinct from the protocol.
>
The term "domain name" is already defined in RFC 8499.
Peter Thomassen wrote on 2022-08-13 13:36:
On 8/13/22 15:26, Paul Vixie wrote:
...
we don't need new terminology ("dotted names") to talk about domain
names, which are older in concept and implementation than the dns is.
Sure, you're right. I used "dotted name" here only to prevent that
> On 13 Aug 2022, at 13:48, Mark Andrews wrote:
>
> So you are ready to replace SHA1 in NSEC3 and do a second algorithm renumber
> which is what is required to actually get rid of SHA1 or do you mean retire
> RSA-SHA1.
Neither. I said the I-D needs to say something about not using crypto
On 8/13/22 15:26, Paul Vixie wrote:
what people want is domain names. right now dns camps onto the whole space of domain
names, because it expected to be the last and final deliverer of domain names. it's
called the "domain name system" after all.
dns should decamp from some part of the
Peter Thomassen wrote on 2022-08-13 09:23:
On 8/13/22 11:57, John R Levine wrote:
...
It's not a technical problem, it's a social or political one. People
have projects outside the DNS and want to name them with DNS names.
Sometimes you can't have what you want.
The issue is
On 8/13/22 11:57, John R Levine wrote:
That said, I believe what Warren is suggesting is more of a ten thousand foot
view of the namespaces issue; and if that finds a way to allow innovation
without fragmentation, it would be beneficial for DNS and non-DNS names alike.
That would be swell,
I agree with this for TLD strings but the special use domain names registry is
also used for registrations under .arpa which we want to keep. Is there an RFC
other than 6761 that would cover those ? Eg currently resolver.arpa is going
through 6761.
Good point. Leaving it open for .arpa
That said, I believe what Warren is suggesting is more of a ten thousand foot
view of the namespaces issue; and if that finds a way to allow innovation
without fragmentation, it would be beneficial for DNS and non-DNS names alike.
That would be swell, but since we've been wrestling with this
Sent using a virtual keyboard on a phone
> On Aug 12, 2022, at 23:36, John Levine wrote:
>
> Given the
> history of failure, I think the sensible thing to do is to stop, which
> means closing the Special-Use Domain Names registry.
I agree with this for TLD strings but the special use
I wrote an experimental "avoid-fragmentation" patch for NSD (as per
section 3.1 and Appexdix C). Due to dependency on getsockopt(IP_MTU),
currently it should work on Linux only.
https://github.com/hdais/nsd-avoid-fragmentation#avoid-fragmentation-implementation-for-nsd
So you are ready to replace SHA1 in NSEC3 and do a second algorithm renumber
which is what is required to actually get rid of SHA1 or do you mean retire
RSA-SHA1.
People are much too imprecise in the terminology.
--
Mark Andrews
> On 13 Aug 2022, at 18:50, Jim Reid wrote:
>
> Wes, I'm
Wes,
What is missing is how validators/validating resolvers should behave when
presented with SHA1.
Roy
> On 12 Aug 2022, at 16:48, Wes Hardaker wrote:
>
>
> Because it's time...
>
> Start of forwarded message
> From: internet-dra...@ietf.org
> To:
Wes, I'm all for killing SHA1. Though the mechanism might need a rethink. We
probably should have a simpler way to add/remove DNSSEC crypto algorithms. IIRC
Paul Hoffman explained the problem a year or so ago when new code points were
needed for the latest GOST algorithms: something about that
26 matches
Mail list logo
