On 1 Sep 2015, at 18:28, Mark Andrews wrote:
In message , "Joe
Abley" writ
es:
On 1 Sep 2015, at 11:45, Jacob Appelbaum wrote:
In my view and the DNS has a critical flaw: it does not provide
query
privacy.
You're on the wrong list. The people working on DNS privacy are over
at
DPRIV
In message , "Joe Abley" writ
es:
>
>
> On 1 Sep 2015, at 11:45, Jacob Appelbaum wrote:
>
> > In my view and the DNS has a critical flaw: it does not provide query
> > privacy.
>
> You're on the wrong list. The people working on DNS privacy are over at
> DPRIVE. For the problem statement, se
On 1 Sep 2015, at 11:45, Jacob Appelbaum wrote:
In my view and the DNS has a critical flaw: it does not provide query
privacy.
You're on the wrong list. The people working on DNS privacy are over at
DPRIVE. For the problem statement, see RFC 7626, recently published.
Joe
___
On 9/1/15, John R Levine wrote:
>>> In any event, from the point of the DNS, a reservation that just says
>>> don't resolve .onion would be quite adequate.
>>
>> You may consider the privacy leakage issues of no consequence. Others do
>> not.
>
> Please do not put words in my mouth. They're
In any event, from the point of the DNS, a reservation that just says
don't resolve .onion would be quite adequate.
You may consider the privacy leakage issues of no consequence. Others
do not.
Please do not put words in my mouth. They're important but they're not a
DNS problem.
R
> On 1 Sep 2015, at 10:35 pm, John Levine wrote:
>
>> This is a language quibble. I said ICANN had no mechanisms for
>> specifying how a domain should be handled, and I would think a SHOULD
>> specification is exactly that in formal language.
>
> ICANN has vast sets of rules about how GTLDs are
>This is a language quibble. I said ICANN had no mechanisms for
>specifying how a domain should be handled, and I would think a SHOULD
>specification is exactly that in formal language.
ICANN has vast sets of rules about how GTLDs are handled at the server
end. They have rules about DNSSEC and ab
This is a language quibble. I said ICANN had no mechanisms for specifying how a
domain should be handled, and I would think a SHOULD specification is exactly
that in formal language. ICANN has no good mechanism to make recommendations
for DNS resolver behaviour of an undelegated domain, even min
I’d add that ICANN has no mechanism for specifying how a top level
domain should be handled other than the simple delegation/non-delegation
binary (it can specify how certain sub-domains should be handled as a
condition of delegation). It cannot, as the .onion proposal does,
specify that the do
I’d add that ICANN has no mechanism for specifying how a top level domain
should be handled other than the simple delegation/non-delegation binary (it
can specify how certain sub-domains should be handled as a condition of
delegation). It cannot, as the .onion proposal does, specify that the dom
>It seems to me that ICANN could well decide that certain names are
>just not going to be delegated in the DNS root, and could do that on
>the understanding that it is because of existing deployments. There
>is an argument to ne made that the "corp" and "mail" examples are of
>this sort, although
11 matches
Mail list logo
