On 2014-02-16 17:39, Patrik Fältström wrote:
On 2014-02-16 16:52, Paul Hoffman wrote:
On Feb 15, 2014, at 11:15 PM, Patrik Fältström p...@frobbit.se wrote:
On 2014-02-16 03:04, David Conrad wrote:
Perhaps DNSOP actually is the DNS innovation WG (if perhaps only as a
seeding ground
On 2014-02-13 10:23, Marc Blanchet wrote:
- why not just register a URN namespace and use it as they see fit?
Because you only type in a string that looks like a domain name in
applications (for example browsers) without the URI scheme nowadays, and
people want that to work also with strings in
On 2014-02-04 02:21, Andrew Sullivan wrote:
On Mon, Feb 03, 2014 at 08:08:59PM -0500, Ted Lemon wrote:
purely on the basis that some of us don't like what they did. We
need a better reason than that, and thus far none has been stated.
In the particular case of .onion, I'm not sure I
FWIW, very good summary Andrew. Resonates with what my thinking has been.
Thanks!
In short:
This draft do point out a presumed need for other kind of namespaces, most
notably ones that:
+ are local but unique where each user can have a unique namespace where the
name globally is not unique
On 10 dec 2013, at 18:23, Peter Koch p...@denic.de wrote:
At this time, after 25 IETF meetings, I have informed our AD that I'd
like to step down from the position of a DNSOP co-chair and hand over
the responsibility to somebody else to join Tim in chairing the group.
...and I presume there
On 9 dec 2013, at 02:19, David Conrad d...@virtualized.org wrote:
This is one of the main reasons why the notion of using a different
class for GNS is rather silly.
It would mean revising the stub resolver on each client system that is using
GNS, which would be necessary in environments
On 5 dec 2013, at 16:02, Warren Kumari war...@kumari.net wrote:
Convincing all existing users (e.g .local) to move under the new labor (e.g
local.alt) is probably a non-starter, but perhaps things like .bit, and new
things may do so…
One of the things that we repeatedly heard during the
On 4 dec 2013, at 01:50, David Conrad d...@virtualized.org wrote:
Ignoring that, other than aesthetics, what is the downside of p2p.alt or
p2p.not-dns or p2p.arpa again?
Not much but it is hard to exclude the aesthetics and issues for deployed
software. Same question as for .local, part from
Btw, I did ask a person working with these things how this is implemented in
reality, out in the world, and the following is the response:
*** At this point I don't think there's a global plugin for all of
them. The Tails distribution has a nice page explaining how to enforce
Tor (and I2P)
On 2 dec 2013, at 10:56, Marco Davids (SIDN) marco.dav...@sidn.nl wrote:
On 12/01/13 17:48, Stephane Bortzmeyer wrote:
For the record, I've reviewed
draft-grothoff-iesg-special-use-p2p-names-00, I find it well-written
and clear and I fully support it. Registering these names would be a
On 2 dec 2013, at 16:16, Andrew Sullivan a...@anvilwalrusden.com wrote:
On Sun, Dec 01, 2013 at 12:35:44PM -0500, Paul Wouters wrote:
It would make more sense to me to reserve something like .alt where
people can plugin onion.alt, gnu.alt, etc, and are guaranteed that
the .alt domain will
On 2 dec 2013, at 16:40, Olafur Gudmundsson o...@ogud.com wrote:
I have a big conceptual problem with it,
Why do people think that different namespaces should be identified by a
postfix?
The people that use browsers...that just type in something that looks like,
smells like, and acts
On 13 nov 2013, at 16:04, Suzanne Woolf suzworldw...@gmail.com wrote:
I'm nervous of any assumption that any jurisdiction won't compromise its Data
Protection regime under some conditions. I'd simply assume such contracts
can't be reliably kept inside the US or outside, unless I'm sure that
On 9 jul 2013, at 09:46, Antoin Verschuren antoin.verschu...@sidn.nl wrote:
Signed PGP part
Op 08-07-13 20:28, Patrik Fältström schreef:
One such situation is what is to happen when NS records changes in
the parent zone.
An immediate reaction is that change of NS records should
On 8 jul 2013, at 20:49, Dickson, Brian bdick...@verisign.com wrote:
However, maybe something like a PNS (parent NS) in the child, where the
child is authoritative for the data, could signal {change | validation}
(depending on the RRR requirements), would do the trick?
Might solve some
On 27 feb 2013, at 14:18, Alexander Mayrhofer alexander.mayrho...@nic.at
wrote:
We've been discussing internally whether or not including DS records into a
zone without respective NS record(s) makes any sense (assuming that there are
no other RRSETs for the respective label in the zone
is ever a spec, infers that
NS-less DS's aren't to be seen. From RFC 4035:
3.1.4.1. Responding to Queries for DS RRs
The DS resource record type is unusual in that it appears only on the
parent zone's side of a zone cut.
On Feb 28, 2013, at 0:59, Patrik Fältström wrote:
On 27
On 24 jul 2012, at 16:07, Antoin Verschuren wrote:
On 16-07-12 22:37, Patrik Fдltstrцm wrote:
Just back from holidays, some aditions:
JUST talk about things like:
1. we have registry, registrar, registrant and DNS operator
In the DNSSEC transfer issues we discussed, we did enter a
On 13 jul 2012, at 13:57, Peter Koch wrote:
while this discussion is refreshing, the reason Paul (was) volunteered
to write this document was less the (re-)definition of the lame delegation
terminology but more to address (potential) requirements for an in-band
child parent key exchange.
On 16 jul 2012, at 16:25, Paul Wouters wrote:
On Mon, 16 Jul 2012, Paul Hoffman wrote:
Subject: Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00
On Jul 16, 2012, at 12:40 AM, Patrik Fältström wrote:
On 13 jul 2012, at 13:57, Peter Koch wrote:
while this discussion
Suggestion:
JUST talk about things like:
1. we have registry, registrar, registrant and DNS operator
2. any of those might give the right to a third party to act on their behalf
3. we only know there are direct connections and knowledge between
registry-registrar, registrar-registrant and
On 15 apr 2012, at 03:23, Warren Kumari wrote:
Once most ISPs are performing validation there should be fewer screwups, and
NTAs should be almost never needed -- but until we get to that point I think
that they are needed, and the net security wins outweigh the costs…
...and my point is
On 15 apr 2012, at 17:46, David Conrad wrote:
The decisions as to whether to deploy an NTA vs. whether to deploy DNSSEC are
made a different times and (I suspect) different places within the
organization. Obviously, an organization must decide to deploy DNSSEC before
the question of
On 14 apr 2012, at 00:30, Jaap Akkerhuis wrote:
(paf)
But, all of this thinking leads me to think about DNSSEC validation
risks are very similar to the risk with deploying IPv6?
We have an IPv6 day, but why not a DNSSEC day? One day where
*many* players at
On 14 apr 2012, at 01:50, Mark Andrews ma...@isc.org wrote:
What one needs to do is validate answers from one's own zones
internally as well as answers from the rest of the world.
Unfortunately too many of the broken zones we have in Sweden are the ones where
split DNS is in use and the
On 13 apr 2012, at 22:09, Evan Hunt wrote:
On Fri, Apr 13, 2012 at 05:43:42PM +, Paul Vixie wrote:
i'm opposed to negative trust anchors, both for their security
implications if there were secure applications in existence, and for
their information economics implications.
+1
+1
On 13 apr 2012, at 22:24, Patrik Fältström wrote:
+1
In a private chat I am asked to explain my +1.
Let me explain why.
Today, before negative trust anchors, the responsibility for whether a the
resolution that is basis for a connection establishment is with the zone owner.
If the signature
On 13 apr 2012, at 22:44, Nicholas Weaver wrote:
Because practice has shown that it is the recursive resolver, not the
authority, that gets blamed.
As you saw in my mail, I completely disagree from my own personal experience.
If I look at the number of failures, the number of cases where
On 24 nov 2010, at 02.26, Doug Barton wrote:
no _technical_ reason that TLD labels should be all-alphabetic
FWIW, when you display internationalized domain names, and mixed RTL and LTR
contexts (overall, in a label etc), you can get interesting results when
characters that have not
On 24 nov 2010, at 03.15, James Mitchell wrote:
If deployed software does not work with a TLD, it is the TLD owner who loses.
I would like to say that the registrants that buy domain names in that TLD are
the ones that loose.
Patrik
___
DNSOP
On 21 nov 2010, at 22.27, Andrew Sullivan wrote:
My point is that if there were some reason to have this data available in a
convenient machine readable format, then iris would already be deployed.
There is no reason. Noone is asking strong enough to get correct data from the
whois service.
On 17 nov 2010, at 14.08, James Mitchell wrote:
As a thought, consider names written in the Arabic script. Being a cursive
script, how is a TLD applicant expected to separate 'words' in a top level
domain without the use of a hyphen or equivalent. Removing the spaces will
cause the
On 13 nov 2010, at 01.05, Masataka Ohta wrote:
Some non-ASCII name wrote:
3. the general category of all code points, is one of { Ll, Lo, Lm,
Mn }.
If you want more clarification than that (and the reference to
RFC5890 where it is discussed further), please send text.
OK.
On 11 nov 2010, at 23.24, Masataka Ohta wrote:
Joe Abley wrote:
http://www.ietf.org/id/draft-liman-tld-names-04.txt
is the latest iteration of an effort started quite some time
ago to clarify the somewhat vague inference in RFC 1123 and
create a more precise specification for the syntax
On 11 nov 2010, at 19.42, Joe Abley wrote:
[sending separately to dnsext and to dnsop, apologies for duplicates]
http://www.ietf.org/id/draft-liman-tld-names-04.txt
is the latest iteration of an effort started quite some time ago to clarify
the somewhat vague inference in RFC 1123 and
Thanks Olaf!
Patrik
On 8 jul 2010, at 15.04, Olaf Kolkman wrote:
On Mar 24, 2010, at 11:19 PM, Patrik Fältström wrote:
General comment:
The document is not clear enough regarding the roles of the registrant, dns
operator, registrar and registry -- where the dns operator
General comment:
The document is not clear enough regarding the roles of the registrant, dns
operator, registrar and registry -- where the dns operator is in the document
implied to be the one that hold the private keys. Further, the same
organsiation might have one or more of these roles.
On 14 jan 2010, at 10.38, ray.bel...@nominet.org.uk wrote:
EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations
will not send more even if client ask for it. Firewalls will
enforce this.
RFC 2671 enforces no such limit - the strict limit is 65535, and §4.5.5
has a hint that
On 14 jan 2010, at 17.58, Patrik Fältström wrote:
On 14 jan 2010, at 10.38, ray.bel...@nominet.org.uk wrote:
EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations
will not send more even if client ask for it. Firewalls will
enforce this.
RFC 2671 enforces no such limit
On 30 jun 2009, at 16.43, Mark Andrews wrote:
This is simultaneous roll of KSK and ZSK keys. You introduce
the keys the *same* way as you would with a single operator.
The new operator generates new keys. The are added to the
existing DNSKEY RRset and the
[On request from Olaf, also dnsop is included:ed]
I think this discussion have derailed a bit, while on the other hand
explained somewhat to me what things are really creating problems.
We have a problem when a domain changes hands and the private DS key
in some way is changed, should be
On 30 jun 2009, at 12.02, Antoin Verschuren wrote:
So let's not discuss the mixing up of roles like registrar,
registrants, dns-operators, etc.
The only reason they matter is because in practice:
Where have you got these numbers from?
-95% of registrar changes INVOLVE a change of DNS
On 9 mar 2009, at 19.16, David Conrad wrote:
This doesn't make any sense to me. I am fairly certain there will
be a request to add the U-label 日本 (Japanese Kanji for Japan).
This isn't alphabetic in any sense of the term.
To some degree it is, as the two characters are:
U+65E5 : Lo,
On 9 mar 2009, at 19.11, Edward Lewis wrote:
If A-labels conform to the rules in 1123 and all U-labels can be
translated to A-labels, is BiDi an issue (for the DNS)?
The $1 question has to do with the (for the DNS) part of what you
write. Domain names are not only used in the DNS as
On 10 mar 2009, at 08.30, Patrik Fältström wrote:
If you use a mac, let me recommend UnicodeChecker from http://earthlingsoft.net
Hmm...that domain seems to be not delegated at the moment. Anyone have
other contacts?
Patrik
___
DNSOP
On 10 mar 2009, at 19.07, David Conrad wrote:
P.S. Out of curiosity, what is 一 (Japanese Kanji for the number
1) considered?
U+4E00 : Lo, Other_Letter, L, Left_To_Right
I.e. it is a letter. With strong directionality. So according to the
Unicode properties that we use so far, that is not
On 9 mar 2009, at 18.35, Edward Lewis wrote:
For those of us not reading idnabis, what is an A-label and what is
a U-label? I have not seen a reference to their definition so I'm
assuming these are idnabis terms.
In short, an A-label is what is registered in DNS (xn-- version) and U-
On 6 mar 2009, at 21.54, Edward Lewis wrote:
And, from what I have heard, I believe display issues is at the
heart of the problem.
I'm sure Patrik is active in the IDNABIS WG. So if it is an issue,
he'd have spoken about it.
Yes, active there, following this list.
Still, seriously, all
On 7 mar 2009, at 14.56, bmann...@vacation.karoshi.com wrote:
does this mean my chances for ^B. are nil? :)
Go for it!
But I think foo^H^H^Hbar is more interesting as a label. Maybe with a
^G in there as well.
Patrik
--bill
On Sat, Mar 07, 2009 at 12:07:01PM +0100, Patrik
On 7 mar 2009, at 15.31, bmann...@vacation.karoshi.com wrote:
na... the ^B. is for the visually impared. the DNS can talk!
(and it does meet your explict directionality concern.)
If you with ^B talk about U+0002, then it does not fulfil the explicit
directionality requirements as it is
On 7 mar 2009, at 16.25, David Conrad wrote:
On Mar 7, 2009, at 1:07 AM, Patrik Fältström wrote:
I think it is time to not have a general rule lets add something
if not proven that adding will create harm, but instead lets add
something only if proven that it absolutely not does create any
On 7 mar 2009, at 16.25, David Conrad wrote:
Define harm.
Here is a link to one of the blog pages of mine that show in a
filesystem what I think is harm if we allow mix of codepoints etc
that give same result(s) for domain names.
http://stupid.domain.name/node/681
I claim that is
On 7 mar 2009, at 18.14, David Conrad wrote:
On Mar 7, 2009, at 5:33 AM, Patrik Fältström wrote:
If you want a TLD, you tell me that you will not create any harm.
You do, you get the domain, things go poof, then you did not do
your homework beforehand.
So, just to be clear, you would
On 7 mar 2009, at 21.04, David Conrad wrote:
On Mar 7, 2009, at 8:40 AM, Patrik Fältström wrote:
The problem with writing exact objective rules is that with the
6000 languages, and enormous number of codepoints, it is extremely
hard to create say a regular expression that we know
On 26 aug 2008, at 14.23, Andrew Sullivan wrote:
I should have been clearer. If I were to go down this path, the point
of the NAPTR or SRV (or now URI, or whatever other kind of) RR would
actually be just to provide the place to look up the policy (and maybe
how), rather than to provide the
On 25 aug 2008, at 22.24, Andrew Sullivan wrote:
To provide clients with a convenient way of learning about the policy
statements, I think I'll need a facility that I can be fairly sure the
client could use. One that has occurred to me is the S-NAPTR
approach, as defined in RFC 3958. My
On 15 aug 2008, at 22.01, David Conrad wrote:
Let me try to (hopefully) more clearly articulate my question: given
the fact that caching servers only care about DNSSEC if they're
explicitly configured to do so, does anyone anticipate any stability/
security concerns to those folks who
On 25 jun 2008, at 14.17, Joao Damas wrote:
On Jun 25, 2008, at 10:58 AM, 黄理灿 wrote:
For example, the fibre cables connecting US with China was broken
by earthquake, then almost all web pages was unreachable even the
machine was in China because of root servers are located in USA.
Not
On 9 jun 2008, at 15.41, Gervase Markham wrote:
Patrik Fältström wrote:
The problem with any such mechanisms is that the barrier of entry for
new players (that does not match the currently used list -- including
non-upgraded software) is increased. More than what people think.
This isn't so
101 - 159 of 159 matches
Mail list logo
