Hi Ted,
At 06:02 15-05-2014, Ted Lemon wrote:
I think it's worth documenting this option because there's a code
reserved for it, but I think it's highly questionable whether it
makes the internet better, because it encourages practices with DNS
that wind up violating the expectations resolvers
On May 16, 2014, at 5:35 AM, S Moonesamy sm+i...@elandsys.com wrote:
I sent a few comments about that CDNI draft. The DNS discussion in the draft
was problematic. It is worth documenting what people are doing. It is
worthwhile to consider whether the mechanism should be standardized by the
On 5/16/14, 8:18 AM, Andrew Sullivan wrote:
On Thu, May 15, 2014 at 09:02:43AM -0400, Ted Lemon wrote:
makes the internet better, because it encourages practices with DNS
that wind up violating the expectations resolvers might have for
consistency of zones and so on.
Despite my personal
On May 16, 2014, at 8:18 AM, Andrew Sullivan a...@anvilwalrusden.com wrote:
But it seems to me we ought to
be more enthusiastic than resigned in this case, even if we have to
hold our collective nose as well. Either those who understand how the
DNS works will document what to do, or else
On May 16, 2014, at 10:00 AM, Olafur Gudmundsson o...@ogud.com wrote:
few people saying this would cause the world to end and calling the
proponents names.
FWIW, when mailing list subscribers behave this way, what they say probably
can't easily be considered part of the consensus evaluation,
On Fri, May 16, 2014 at 7:24 AM, Nicholas Weaver
nwea...@icsi.berkeley.eduwrote:
No its not. All you have to be willing to do is release the constraint on
all signatures offline. Doing online signatures allows all the CDN
functionality you want to be DNSSEC validated (not like DNSSEC really
On May 16, 2014, at 10:24 AM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote:
No its not. All you have to be willing to do is release the constraint on
all signatures offline. Doing online signatures allows all the CDN
functionality you want to be DNSSEC validated (not like DNSSEC really
On May 16, 2014, at 10:29 AM, Colm MacCárthaigh c...@allcosts.net wrote:
You won't survive a trivial DOS from a wristwatch computer with that approach
:) Having static answers around greatly increases capacity, by many orders of
magnitude.
Argh. Having just agreed with Nick, I have to
On May 16, 2014, at 7:29 AM, Colm MacCárthaigh c...@allcosts.net wrote:
And even 4096b RSA signatures only take a handful of milliseconds to
construct on the fly, you can cache signature validity for minutes even in
the very dynamic case, and this is one of those operations that parallelize
On 05/16/2014 02:18 PM, Andrew Sullivan wrote:
First, if resolvers have expectations about consistency of zones and
so on, then they're broken. The DNS has only ever been loosely
coherent. You're simply _not allowed_ to make that assumption from
any point in the network except inside the
On Fri, May 16, 2014 at 7:34 AM, Nicholas Weaver
nwea...@icsi.berkeley.eduwrote:
On May 16, 2014, at 7:29 AM, Colm MacCárthaigh c...@allcosts.net wrote:
And even 4096b RSA signatures only take a handful of milliseconds to
construct on the fly, you can cache signature validity for minutes
On May 16, 2014, at 7:44 AM, Colm MacCárthaigh c...@allcosts.net wrote:
Actually, you can. You prioritize non-NSEC3 records, since thats a finite,
identifiable, priority set, and cache the responses. Thus if you have 10k
valid names, each with 100 different possible responses, and have a
On May 16, 2014, at 10:54 AM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote:
You miss my point. That server is doing a million QPS, but its only
providing ~16k/s distinct answers.
[...]
I will reiterate that it would be really wonderful if all this creative energy
could go into writing
On Fri, May 16, 2014 at 7:50 AM, Paul Vixie p...@redbarn.org wrote:
what we do have is advice: if you're going to do this, here is a way
that works. in many cases, and DNSSEC is an example, the advice has an
additional property: if you want a system like this, here is how
everybody else is
On Fri, May 16, 2014 at 7:54 AM, Nicholas Weaver
nwea...@icsi.berkeley.eduwrote:
16k/second is nothing, and I can generate that from a wristwatch
computer. Caching doesn't help, as the attackers can (and do) bust caches
with nonce-names and so on :/ A 16 core machine can do a million QPS
Hi Ted,
At 04:56 16-05-2014, Ted Lemon wrote:
Did you feel that your comments were adequately addressed by the
working group?
I gave up on reading the first response to my comments as I did not
want to push back strongly; it's an effort and it can be viewed as
antagonistic.
Regards,
S.
On Fri, May 16, 2014 at 04:41:17PM +0200, Jelte Jansen wrote:
To implement client-subnet means to implement a form of views within
your resolver in the form of split caches. If you don't implement it at
all there is no problem, but it certainly does change the model of the
world that
On May 16, 2014, at 11:02 AM, S Moonesamy sm+i...@elandsys.com wrote:
I gave up on reading the first response to my comments as I did not want to
push back strongly; it's an effort and it can be viewed as antagonistic.
I think there's a fine line between ratholing and not getting the point
I don't want to spend a lot of time in this rathole (and this will be
my last remark on it), but I want to clarify something about what I
was trying to say. I suppose I should have picked better language.
On Fri, May 16, 2014 at 07:50:10AM -0700, Paul Vixie wrote:
not allowed is interesting
one of the icann ssac (then secsac) consensus processes i am most
proud to have been part of was this, in 2004:
http://www.icann.org/en/groups/ssac/report-redirection-com-net-09jul04-en.pdf
indeed, this document and the process followed in creating it may still
stand today, as ssac's finest
You would be insane to publish varient DS records with edns-client-subnet
to the public as there is no requirement for clients to use the
same address to lookup DS records as they use to lookup DNSKEY
records. Similarly for DNSKEY or RRSIGs based on DNSKEYs which are
varient based on
Doug Barton schreef op 06-05-14 19:27:
Just because we _can_ make something work better doesn't mean we _should_.
Off course we should, it's our mission: :-)
The goal of the IETF is to make the Internet work better.
(http://www.ietf.org/)
--
Marco
On May 15, 2014, at 2:53 AM, Marco Davids (SIDN) marco.dav...@sidn.nl wrote:
The goal of the IETF is to make the Internet work better.
Indeed so. And making things _other_ than the Internet work better can be
damaging to the Internet. It isn't always, but it's something we need to
consider
On May 8, 2014, at 12:43 PM, Suzanne Woolf suzworldw...@gmail.com wrote:
Ah, sorry. Was trying to reflect what the discussion was saying, not impose
an “edict”. It seemed like a reasonable starting position.
Do you disagree? If so I’ll hope you’ll say what you think on the subject….
Yes,
Barry Margolin pointed out an amusing interaction between two stupid DNS
tricks on the bind-users list:
https://lists.isc.org/pipermail/bind-users/2014-May/093171.html
If you have an authoritative server with ANAME or CNAME flattening
support, and the target of the ANAME is a CDN that does
Tony Finch wrote:
Barry Margolin pointed out an amusing interaction between two stupid DNS
tricks on the bind-users list:
https://lists.isc.org/pipermail/bind-users/2014-May/093171.html
If you have an authoritative server with ANAME or CNAME flattening
support, and the target of the ANAME
Moin!
On 08 May 2014, at 17:47, Paul Vixie p...@redbarn.org wrote:
Tony Finch wrote:
Barry Margolin pointed out an amusing interaction between two stupid DNS
tricks on the bind-users list:
https://lists.isc.org/pipermail/bind-users/2014-May/093171.html
If you have an authoritative server
Ralf Weber wrote:
...
There is madness, but the madness is in mixing authoritative and recursive
functions in one server and not in using DNS to direct traffic.
while i'm on record has holding that view, it turns out that RFC 1035
does describe recursion and authority as co-residing in a
#1 - support doing the work to finalize the edns-client-subnet standard.
now... (I hope my inline response is accepted by the readers of this
wg's list, I would note that someone's quoting is all jacked up... oh
well)
pull up waders
On Thu, May 8, 2014 at 12:17 PM, Paul Vixie p...@redbarn.org
On Thu, May 8, 2014 at 9:15 AM, Ralf Weber d...@fl1ger.de wrote:
There is madness, but the madness is in mixing authoritative and recursive
functions in one server and not in using DNS to direct traffic.
That's a pretty big assumption to jump to. It's pretty unlikely that all
ANAME
On Tue, 6 May 2014, Doug Barton wrote:
So NAT is an interesting case, since there's no doubt that the IETF dropped
the ball on that. But the problem there was not that the IETF chose not to
act in order to not support NAT, the problem there was that the collective
decision process failed by
On 6 May 2014, at 22:34, Doug Barton do...@dougbarton.us wrote:
You could say that I'm arguing 'ad absurdum' here, but I'm not. There really
are such things as bad ideas, and it's perfectly reasonable for the IETF to
decide that something is a bad idea, and shouldn't be done. Or at least,
On Wed, May 07, 2014 at 12:36:18PM -0400, Joe Abley wrote:
(a) use of edns-client-subnet effectively involves a large depth of
undocumented experience and knowledge about specific implementations and
where those specific implementations are used.
NAT *is* a bad idea. And the amount of
I think if we want good engineering then we should recommend on host or on net
validating resolvers.
I think if we want interoperability then we have to standardize anything
anybody is doing.
If ietf documents client-subnet then it should be an FYI. That's hardly a death
sentence... Look what
On Wed, May 07, 2014 at 07:06:34PM +0200, P Vixie wrote:
If ietf documents client-subnet then it should be an FYI.
Can't do that. https://tools.ietf.org/html/rfc6360, Conclusion of FYI RFC
Sub-Series.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
Ouch. Well so if a large body of ietf participators think wide area rdns is a
bad idea and that this option should never be recommended then we would
presumably have to say so in the document which standardized the option.
Strange.
On May 7, 2014 7:09:26 PM CEST, Andrew Sullivan
This sounds to me like a) support for working on edns-client-subnet (and
possibly things like it in the future), with b) a resulting RFC as
Informational.
I've found this discussion very helpful in solidifying the thoughts Tim already
wrote about, particularly with regards to carrying out our
On 7 May 2014, at 13:12, P Vixie p...@redbarn.org wrote:
Ouch. Well so if a large body of ietf participators think wide area rdns is a
bad idea and that this option should never be recommended then we would
presumably have to say so in the document which standardized the option.
Strange.
Joe... To clarify... Client subnet is not what I an complaining about. It's
wide area rdns itself that I think is a bad idea. One reason wide area rdns is
a bad idea is that it needs client subnet options.
Centralized rdns is not necessary and it makes the internet brittle. Better
alternatives
On Wed, May 07, 2014 at 07:12:21PM +0200, P Vixie wrote:
Ouch. Well so if a large body of ietf participators think wide area rdns is a
bad idea and that this option should never be recommended then we would
presumably have to say so in the document which standardized the option.
Strange.
On May 7, 2014, at 10:23 AM, P Vixie p...@redbarn.org wrote:
Joe... To clarify... Client subnet is not what I an complaining about. It's
wide area rdns itself that I think is a bad idea. One reason wide area rdns
is a bad idea is that it needs client subnet options.
Centralized rdns is
Dear Uncle Ben,
On Wed, May 07, 2014 at 07:26:51PM +0200, P Vixie wrote:
The architectural context of a feature should not be divorced from its
specification. RFC is an imprimatur. With great power comes great
responsibility.
I disagree with this point of view. I see nothing at all wrong
On May 7, 2014, at 12:23 PM, P Vixie p...@redbarn.org wrote:
Centralized rdns is not necessary and it makes the internet brittle. Better
alternatives exist. The architecture of DNS assumes localized rdns. If we're
going to document client subnet then all that advice will have to go into it.
Andrew Sullivan wrote:
Dear Uncle Ben,
keep it civil, please.
On Wed, May 07, 2014 at 07:26:51PM +0200, P Vixie wrote:
The architectural context of a feature should not be divorced from its
specification. RFC is an imprimatur. With great power comes great
responsibility.
I disagree
On May 7, 2014, at 1:13 PM, Suzanne Woolf suzworldw...@gmail.com wrote:
This sounds to me like a) support for working on edns-client-subnet (and
possibly things like it in the future), with b) a resulting RFC as
Informational.
I've found this discussion very helpful in solidifying the
On 05/06/2014 10:18 AM, Joe Abley wrote:
I think not picking up this work will result in implementation and operational
problems.
Those of us who still have the vomity taste would like the problems with
interop and implementation to continue.
Just because we _can_ make something work
On 6 May 2014, at 13:27, Doug Barton do...@dougbarton.us wrote:
On 05/06/2014 10:18 AM, Joe Abley wrote:
I think not picking up this work will result in implementation and
operational problems.
Those of us who still have the vomity taste would like the problems with
interop and
On May 6, 2014, at 10:30 AM, Joe Abley jab...@hopcount.ca wrote:
On 6 May 2014, at 13:27, Doug Barton do...@dougbarton.us wrote:
On 05/06/2014 10:18 AM, Joe Abley wrote:
I think not picking up this work will result in implementation and
operational problems.
Those of us who still have the
On Tue, 6 May 2014, Joe Abley wrote:
I think dnsop should pick up some or all of this work. I think not picking up
this work will result in implementation and operational problems. (I am
reminded of the consequences of not standardising NAT, for example.)
I would be happy to contribute
Moin!
On 06 May 2014, at 19:18, Joe Abley jab...@hopcount.ca wrote:
Google DNS supports edns-client-subnet, which by recent GIH+GGM count means
10%+ of all client queries now trigger queries to authority servers with that
option included.
On the authority side, support for this option has
On Tue, May 6, 2014 at 10:18 AM, Joe Abley jab...@hopcount.ca wrote:
On the authority side, support for this option has a potential impact on
query load. On the recursive side, support for this option has a potential
impact on cache size.
Just to add some limited data; CloudFront (a large
Section 3.1.1. Responses Tailored to the Originator in the
draft-iab-dns-applications-07
has some related discussion to this topic.
From the IAB draft, it seems that IAB does not prefer to tailor dns response
based on the originator.
Jiankang Yao
From: Joe Abley
Date: 2014-05-07 01:18
On Tue, May 6, 2014 at 6:04 PM, Jiankang Yao ya...@cnnic.cn wrote:
Section
3.1.1http://tools.ietf.org/html/draft-iab-dns-applications-07#section-3.1.1.
Responses Tailored to the Originator in the draft-iab-dns-applications-07
has some related discussion to this topic.
From the IAB draft,
Subject: Re: [DNSOP] call to work on edns-client-subnet
On Tue, May 6, 2014 at 6:04 PM, Jiankang Yao ya...@cnnic.cn wrote:
Section 3.1.1. Responses Tailored to the Originator in the
draft-iab-dns-applications-07
has some related discussion to this topic.
From the IAB draft, it seems that IAB does
On 05/06/2014 10:30 AM, Joe Abley wrote:
On 6 May 2014, at 13:27, Doug Barton do...@dougbarton.us wrote:
On 05/06/2014 10:18 AM, Joe Abley wrote:
I think not picking up this work will result in implementation and operational
problems.
Those of us who still have the vomity taste would like
Tencent has been supporting edns client subnet for nearly a year . On the
authority side , we benifit so much from ECS for the extra accuracy of user
geo-location identification ,which helps a lot for our users' network access
optimization and our access traffic scheduling at a totally
56 matches
Mail list logo
