lvers who
ignore any new special use names. I'm sure you all know that, but it
seems foolhardy to negotiate sensitive information over .onion
resolution when that is highly likely to leak.
Surely .onion could have been handled in the application, without
pushing it down to the res
-- Original Message --
From: "John Levine"
To: "dnsop@ietf.org"
Cc: "adr...@qbik.com"
Sent: 30/03/2016 2:55:22 p.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
Surely .onion could have been handled in the application, without
pushing it down to the resolution la
and secondly to encourage
developers to stub it out in DNS resolvers so that .onion requests
don't leak into the DNS. The only thing that anyone's asking DNS
developers to do is to fail .onion requests rather than forwarding
them along.
That's the problem. Creating new requirements for DNS d
don't leak into the DNS. The only thing that anyone's asking DNS
developers to do is to fail .onion requests rather than forwarding
them along.
That's the problem. Creating new requirements for DNS developers to
do anything at all is a huge problem.
It's not a requirement. It's a request.
7;d still expect it to be in google somewhere.
Is this the justification for having an extensible registry of special
names?
Cheers
Adrien
-- Original Message --
From: "John R Levine"
To: "Adrien de Croy"
Cc: "dnsop@ietf.org"
Sent: 30/03/2016 3
g a
clear need and lack of alternative solution to the problem.
Regards
Adrien
-- Original Message --
From: "Andrew Sullivan"
To: "dnsop@ietf.org"
Sent: 31/03/2016 6:38:55 a.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
On Wed, Mar 30, 2016
I don't know the answer to that. If the leakage is still a significant
problem, maybe they should be looking at alternatives anyway.
Adrien
-- Original Message --
From: "John Levine"
To: "dnsop@ietf.org"
Cc: "adr...@qbik.com"
Sent: 31/03/2016 10:49:52 a.m.
Subject: Re: [DNSOP] dr
-- Original Message --
From: "Paul Hoffman"
To: "dnsop@ietf.org"
Cc: "adr...@qbik.com"
Sent: 1/04/2016 12:31:53 a.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
On 30 Mar 2016, at 18:49, John Levine wrote:
Isn't it a little late to be refighting this argument?
sorry, that second reference should have also been RFC 2826
neither the word "Maintaining" nor "architectural" are present in 2826
according to the search function in Chrome.
Adrien
-- Original Message ------
From: "Adrien de Croy"
To: "Paul Hoffma
s any time soon?
Adrien
-- Original Message --
From: "Robert Edmonds"
To: "Adrien de Croy"
Cc: "Paul Hoffman" ; "dnsop@ietf.org"
Sent: 3/04/2016 8:11:37 a.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
You are complaining about t
-- Original Message --
From: "Mark Andrews"
To: "Adrien de Croy"
Cc: "Robert Edmonds" ; "dnsop@ietf.org"
; "Paul Hoffman"
Sent: 3/04/2016 4:47:20 p.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
In message
Why do DNS programmers need to care about these "special" names in the
normal domain name space?
The question is what protocol to use.
I think we still need to answer the question about whether DNS namespace
should be polluted for non-DNS resolution.
-- Original Message --
From: "
-- Original Message --
From: "Philip Homburg"
To: "dnsop@ietf.org"
Sent: 7/04/2016 3:05:26 a.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft
In your letter dated Wed, 6 Apr 2016 09:21:31 -0300 you wrote:
Strong dissensus here. The problem is there is no s
-- Original Message --
From: "Stephane Bortzmeyer"
To: "Ted Lemon"
Cc: "dnsop@ietf.org"
Sent: 7/04/2016 4:53:31 a.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft
4.1.2. Does Every Domain Name Have The Same Meaning Everywhere?
Your claim is that toda
nly being the
part of the tree that is left after you add these other TLDs. Seems a
bit circular to me.
So, we're left with the 1 single TLD that is the problem and that's
.onion, and regardless of the problems that is demonstrating, we wish to
roll out more of these.
Adrien
Hi Stephane
don't worry, I didn't take it that way. For me, the concept of
perversion and LGBT are entirely independent, and I think people who
associate the 2 concepts need to look at their own prejudices.
Regards
Adrien de Croy
-- Original Message --
From: "Step
-- Original Message --
From: "David Conrad"
To: "Philip Homburg"
Cc: "dnsop@ietf.org"
Sent: 8/04/2016 12:38:26 a.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft
Philip,
On Apr 7, 2016, at 7:57 AM, Philip Homburg
wrote:
However, having lived through a p
-- Original Message --
From: "Stephane Bortzmeyer"
To: "Adrien de Croy"
Cc: "Philip Homburg" ; "dnsop@ietf.org"
Sent: 8/04/2016 12:35:32 a.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft
On Wed, Apr 06, 2016 at
-- Original Message --
From: "John Levine"
To: "dnsop@ietf.org"
Cc: "adr...@qbik.com"
Sent: 8/04/2016 9:26:51 a.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft
Just because TOR asks for .onion doesn't mean it should be given it.
The TOR project has been
.local is another excellent example of where we ignore the specs.
If we stopped sending lookups for .local names via DNS (not multicast
DNS), a lot of things would break.
Regards
Adrien
-- Original Message --
From: "Patrik Fältström"
To: "Adrien de Croy"
-- Original Message --
From: "Stephane Bortzmeyer"
To: "Adrien de Croy"
Cc: "Philip Homburg" ; "dnsop@ietf.org"
; "Ted Lemon"
Sent: 8/04/2016 3:06:43 a.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft
Hi all
I guess you're all aware of the issue of what constitutes a valid domain
name, what characters are valid in labels etc. So forgive me for what
must be me re-raising an ancient maybe long-thought-put-to-rest issue...
but there's a serious problem out there.
RFC1034 secion 3.5 which is
-- Original Message --
From: "Ted Lemon"
To: "Adrien de Croy"
Cc: "dnsop@ietf.org"
Sent: 8/04/2016 2:03:17 p.m.
Subject: Re: [DNSOP] hostnames vs domain names vs RFC1034/1035 vs
RFC2818 vs Wikipedia etc
No, you're confusing hostnames and do
-- Original Message --
From: "Ted Lemon"
::= | " " ::= |
"." ::= [ [ ] ]
::= |::=
| "-" ::= | ::= any one
of the 52 alphabetic characters A through Z in upper case and a
through z in lower case ::= any one of the ten digits 0
through 9
if this was a BNF prod
Lemon"
To: "Adrien de Croy"
Cc: "dnsop@ietf.org"
Sent: 8/04/2016 2:24:33 p.m.
Subject: Re: [DNSOP] hostnames vs domain names vs RFC1034/1035 vs
RFC2818 vs Wikipedia etc
Have you read the rest of the documents? E.g.,:
https://tools.ietf.org/html/rfc2181#section-11
On T
ience!
-- Original Message --
From: "Ted Lemon"
To: "Adrien de Croy"
Cc: "dnsop@ietf.org"
Sent: 8/04/2016 2:31:13 p.m.
Subject: Re: [DNSOP] hostnames vs domain names vs RFC1034/1035 vs
RFC2818 vs Wikipedia etc
The document I mentioned updates RFC 1034. T
library one that is used purely to resolve addresses (e.g.
A and records)?
Adrien
-- Original Message ------
From: "Ted Lemon"
To: "Adrien de Croy"
Cc: "dnsop@ietf.org"
Sent: 8/04/2016 2:35:40 p.m.
Subject: Re: [DNSOP] hostnames vs domain names vs RFC1034/10
I think this approach would really hamper adoption.
If we simply added a new QTYPE which permitted a server to respond with
all matching A and records then that would solve a lot of problems.
"fixing" multiple queries per message by an extension option may fail
on every DNS inspection f
sure
the whole point of doing anything is to try and avoid mutliple lookup
hacks, like the existing concurrent A and lookups.
What about allowing the responses in an A query? Even if only in
additional.
Adrien
-- Original Message --
From: "Rob Austein"
To: "dnsop@ietf
sounds like there could be trouble with that
https://icannwiki.com/.home
based on the applicants currently investing in acquiring that TLD.
on another note, TOR is proving its worth as a troll aggregator. Since
blocking TOR exit nodes from posting to our forums, our forum spam
problem has d
Hi Davey
Some general comments:
I don't think you can claim that https provides data integrity or
privacy any more, since MitM proxies are abundant.
I think some thought should be given to how a DNS stub might deal with a
captive portal or http proxy authentication.
I think also that any
n/dns-wireformat definition, or some other
new meta format, or just base64 encode the message, and include both
parts as form data (application/x-www-form-encoded).
The same applies to unknown response headers (may be stripped or
blocked)
Regards
Adrien
-- Original Message --
From: "
r. Sure, DNS servers should be hardened,
but they may not realise they can't trust requests from the gateway.
Adrien
-- Original Message --
From: "Shane Kerr"
To: "Adrien de Croy"
Cc: "dnsop@ietf.org"
Sent: 5/05/2016 2:18:24 a.m.
Subject: Re:
yeah, my email client wasn't quoting properly due to something about the
original message I was replying to... so I had to cut n paste. sorry
bout that!
-- Original Message --
From: "Mark Andrews"
To: "Adrien de Croy"
Cc: "Shane Kerr" ; "dn
From: "Stephane Bortzmeyer"
To: "Adrien de Croy"
Cc: "Shane Kerr" ; "dnsop@ietf.org"
Sent: 6/05/2016 8:59:45 p.m.
Subject: Re: Fwd: New Version Notification for
draft-song-dns-wireformat-http-03.txt
On Wed, May 04, 2016 at 10:13:09PM +,
Adrien d
-- Original Message --
From: "Paul Hoffman"
To: "Adrien de Croy"
Cc: "dnsop@ietf.org"
Sent: 7/05/2016 7:24:46 a.m.
Subject: Re: [DNSOP] New Version Notification for
draft-song-dns-wireformat-http-03.txt
On 6 May 2016, at 12:14, Adrien de Croy wro
I think you and many others will continue to disagree on that point.
try using https for OCSP or CRL checking and see how you go.
-- Original Message --
From: "Stephane Bortzmeyer"
To: "Adrien de Croy"
Cc: "Shane Kerr" ; "dnsop@ietf.org"
age --
From: "Stephane Bortzmeyer"
To: "Adrien de Croy"
Cc: "Shane Kerr" ; "dnsop@ietf.org"
Sent: 7/05/2016 7:40:17 a.m.
Subject: Re: [DNSOP] Fwd: New Version Notification for
draft-song-dns-wireformat-http-03.txt
On Fri, May 06, 2016 at 07:14:29
-- Original Message --
From: "Stephane Bortzmeyer"
To: "Adrien de Croy"
Cc: "dnsop@ietf.org" ; "Paul Hoffman"
Sent: 7/05/2016 10:10:35 p.m.
Subject: Re: [DNSOP] New Version Notification for
draft-song-dns-wireformat-http-03.txt
On Fri, M
-- Original Message --
From: "Stephane Bortzmeyer"
To: "Adrien de Croy"
Cc: "Shane Kerr" ; "dnsop@ietf.org"
Sent: 7/05/2016 10:13:37 p.m.
Subject: Re: [DNSOP] Fwd: New Version Notification for
draft-song-dns-wireformat-http-03.txt
,
I really don't feel like making them again here. I'm sure members of
this list are already sick of me posting about this.
-- Original Message --
From: "Adrien de Croy"
To: "Stephane Bortzmeyer"
Cc: "Shane Kerr" ; "dnsop@ietf.org"
One thing I think has always been bugging me about DNS over HTTP is the
appalling performance we will likely see in a lot of cases. Even small
latencies in normal DNS lookups cause major impact on page load times on
complex pages with resources from many servers, and adding HTTP overhead
to
I guess presuming that the back end will use TCP for DNS you could do
this, but I would imagine that's not always the case?
As an on-the-wire format goes there are worse ones, so if DNS over TCP
is used, which supports this, then I guess some mention in this proposal
could be useful to get p
for a web to DNS proxy to decide to send a reply back, it would need to
consider it complete?
Or are you proposing that the http server would start streaming back the
payload as it received the (possibly out of order) replies?
Maybe instead should use WebSockets
-- Original Message --
> If the admin's goal is to block access to malicious sites, then they
> want to block the traffic, not falsify DNS. If the goal is to warn
> users away from bad places, they can publish the list as a filter for
> end-system firewalls.
That may be your view about how blocking should work, but
presuming that the client will have to look up the hostname of the
destination at some stage, and presuming that a passive network attacker
may see DNS requests as well as TCP connections, how does this help?
Or does this require the use of DNS over TLS.
And also there will be leakage of ce
not need to contact their
>> customers for this: it's a .co.uk policy.
>>
>
> OK. Then we are basically back to Yngve's suggestion. But this does
> require universal take-up for universal support - and that, as someone
> else has pointed out, makes it (in my opini
47 matches
Mail list logo
