It seems to me to be a situation similar to that with MIME types - there is
value in having a well understood part of the namespace for unregistered
experimentation on an FCFS basis.
David
> On 19 Jul 2015, at 3:08 am, John R Levine wrote:
>
>> the ietf's stated purpose is to ensure interoper
As someone with moderate experience in both DNS and web server configuration,
FWIW I found the meaning relatively obvious. The notion that HTTP Host headers
might be used to change web server response independent of name resolution
(e.g. that two names that return identical responses to every po
> On 17 Jul 2015, at 10:52 pm, hellekin wrote:
>
> On 07/17/2015 11:32 AM, David Conrad wrote:
>>
>> No. .LOCAL was not already in the root zone. .FOO is.
>>
> *** Therefore the .FOO label is not available for Special-Use anymore,
> end of story. A Special-Use name cannot be an already registe
There are plausible, if unlikely, circumstances in which a fork, not just of
the Tor project software itself, but of the entire project including the
specific URL, might happen. While this argument is an attempt at a reductio ab
absurdum, I do not think it is - the circumstance described is unli
> On 16 Jul 2015, at 3:35 am, Francisco Obispo wrote:
>
> +1.
>
> I don’t think IETF should be chasing around widely used TLDs and trying to
> block them, it will be a never ending chase.
>
> We are trying to mitigate against unknowns and perhaps the best solution is
> to have the TOR folks
In message <001201d0c288$317fe330$947fa990$@rozanak.com>, "Hosnieh Rafiee"
writes:
> > > When the clients are not seen, I just wonder how the attacker can
> > > target them??
> >
> > Clients talks to things other than DNS servers. The attacker gets the
> address of
> > the address of the client
> On 15 Jul 2015, at 8:42 pm, Edward Lewis wrote:
> 4. Caching DNS Servers and
> 5. Authoritative DNS Servers
>
> I really believe that for DNS elements, there should be no change. By
> intent, the onion names are not to be presented to the DNS by what's in
> category 2 and 3 (Applications and
> > When the clients are not seen, I just wonder how the attacker can
> > target them??
>
> Clients talks to things other than DNS servers. The attacker gets the
address of
> the address of the client from those transactions.
This is not highlighted in the draft which makes it confusing for the
Manning,
I will add this thread to DNSOP WG and 6lo WG.
This is because a good target application area of my draft is 6lo
environment.
Today I discussed my draft with Samita, who is a co-chair of 6lo WG.
She recommended to me that I can announce my draft to 6lo WG.
DNSOP WG and 6lo WG,
if you have
David Conrad wrote:
> ...
>
> With an exclusive registry:
>
> Them: "Hey IANA, we're using .PAUL and here's the docs describing who we are
> and how."
> IANA: "Um, sorry. Someone else is already using that label."
> Them: "But we really like .PAUL and we have deployed a zillion instances that
>
On 18 July 2015 at 04:25, Joel M. Halpern wrote:
> Major issues: It seems to this reviewer that at least the definition of how
> to use these names, reference tor-rendezvous, needs to be a normative
> reference. It appears likely that tor-address also ought to be a normative
> reference.
>
> Mino
In message <01d0c225$8c4d0260$a4e70720$@rozanak.com>, "Hosnieh Rafiee"
writes:
> > > So, you want such mechanism is implemented in NAT devices to protect
> > > all clients in that network, right? If not, the implementation of that
> > > in a single client behind the NAT, doesn't help all the
> > So, you want such mechanism is implemented in NAT devices to protect
> > all clients in that network, right? If not, the implementation of that
> > in a single client behind the NAT, doesn't help all the clients inside
> > that NAT network because the target is a public address of this device
>
In message <001501d0c1ec$52898050$f79c80f0$@rozanak.com>, "Hosnieh Rafiee"
writes:
> Mark,
>
> Thanks for your explanation. My comments are inline...
>
> > -Original Message-
> > From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Mark Andrews
>
>
> > > If the victim node is behi
* Stephane Bortzmeyer:
> On Wed, Jul 15, 2015 at 02:22:58PM -0700,
> Francisco Obispo wrote
> a message of 48 lines which said:
>
>> Well, even worse, what happens if decides
>> to create a new dns-like protocol that uses .foo, does that mean
>> that we should automatically block it?
>
> No n
Paul,
On Jul 19, 2015, at 6:01 AM, Paul Vixie wrote:
> there are no hoops here.
> people will register if they want to, and people will
> check the registry if they want to.
For the people who want to register, an exclusive registry explicitly creates a
discussion for everyone but the first reg
On 19 Jul 2015, at 10:02, Steve Crocker wrote:
> When I was chair of ICANN’s Security and Stability Advisory Committee (SSAC)
> we noted that .belkin was one of the undelegated names that shows up quite
> frequently at the root. If .belkin were delegated in the root, it would
> instantly chang
On 7/19/15 10:47 AM, Stephane Bortzmeyer wrote:
On Mon, Jul 06, 2015 at 03:48:13PM -0400,
Warren Kumari wrote
a message of 68 lines which said:
A number of people approached me at DNS-OARC and the RIPE DNS track
in Amsterdam asking what became of this draft, and could we please
update it
On Mon, Jul 06, 2015 at 03:48:13PM -0400,
Warren Kumari wrote
a message of 68 lines which said:
> A number of people approached me at DNS-OARC and the RIPE DNS track
> in Amsterdam asking what became of this draft, and could we please
> update it.
It's not on the agenda on monday, isn't it?
John R Levine wrote:
> But here's the two options:
>
> A) registry says "ONION.ALT exists, see http://someplace and/or
> http://someplace_else";, you say hm, two different packages, I better
> look at both of them to see which one is installed on my computer.
>
> B) registry says "ONION.ALT exist
Hugo, et al,
I think the experience is exactly the opposite, i.e. these names will *always*
show up in the DNS. As a consequence, I would argue that names being used for
any of these purposes should not be delegated into the DNS root unless it’s for
the same purpose. Thus, if the village of E
Hugo, et al,
I think the experience is exactly the opposite, i.e. these names will *always*
show up in the DNS. As a consequence, I would argue that names being used for
any of these purposes should not be delegated into the DNS root unless it’s for
the same purpose. Thus, if the village of E
On 07/19/2015 05:27 AM, John R Levine wrote:
>>>
>>
>> By this logic, using a FCFS 'registry' model implies at least enough
>> information (if not a requirement) for some of tracking the registrant
>> to confirm continued use, transfer, release or abandonment at the very
>> least, no?
>
> To the e
On Sat, Jul 18, 2015 at 11:27:21PM -0400, John R Levine wrote:
> But once again, if we start inventing hoops for people to jump through, they
> won't. That's counterproductive since we have no control over what they're
> doing, so we'd like them to voluntarily tell us.
Yes. The point of the alt s
Hi,
My reflections on this interesting discussion:
Software using names under *.alt (or whatever it will be) do not use DNS, by
definition.
Thus, there can never be a DNS name collision. It will be up to the alternate
name
resolution software, and its users, to deal with the name collision pr
25 matches
Mail list logo
