Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

2015-01-13 Thread Paul Vixie
> Evan Hunt > Tuesday, January 13, 2015 10:41 PM > > Didn't we decide a while back that this was a bad idea, that resolvers > needed to stop trusting CNAME chains sent by authorities, and that > authorities really ought to stop sending them? yes, we did, "unless dnssec sign

Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

2015-01-13 Thread Guangqing Deng
It is said in this draft that "The authoritative nameserver SHOULD include as many of the additional records as will fit in the response." It may be true that some of the Resource Records in the same DNS zone file are highly related. But authority servers do not know which resource records are i

Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

2015-01-13 Thread Evan Hunt
On Tue, Jan 13, 2015 at 10:08:00PM -0800, Paul Vixie wrote: > you've left the box i thought we were standing in. CNAME chains are > already returned by authorities, if in your above example, the alias and > the canonical name are served by the same authority server. Didn't we decide a while back t

Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

2015-01-13 Thread Paul Vixie
> Warren Kumari > Tuesday, January 13, 2015 9:22 PM > > ... I wrote it because it seemed interesting to me. i think you should do a deeper cost:benefit dive before proposing new signalling on-the-wire. > > i've long believed that just as A and are optional >

Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

2015-01-13 Thread Warren Kumari
On Tue, Jan 13, 2015 at 11:28 PM, Paul Vixie wrote: > > > Warren Kumari > Tuesday, January 13, 2015 8:19 PM > ... I'm surprised that no-one has yet commented on the 'Let's just co-opt > the Z bit for this' - I'm guessing that folk are not sure if I'm kidding or > not, and are scared to ask :-

Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

2015-01-13 Thread Mukund Sivaraman
Hi Warren I didn't read the whole thing, but quickly browsed it. I will follow up with a better review, but here's one point: > 2. Additional records MUST only be served over TCP connections. > This is to mitigate Denial of Service reflection attacks.[1] I think this draft should not co

Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

2015-01-13 Thread Paul Vixie
> Warren Kumari > Tuesday, January 13, 2015 8:19 PM > ... I'm surprised that no-one has yet commented on the 'Let's just > co-opt the Z bit for this' - I'm guessing that folk are not sure if > I'm kidding or not, and are scared to ask :-) W i think you're not kidding,

Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

2015-01-13 Thread Warren Kumari
On Tue, Jan 13, 2015 at 9:17 PM, John Levine wrote: >>> First, for a same transaction, the cost from using TCP may be more than the >>> gain from the queries you save, which may ultimately let the performance >>> become even worse. Do you have any consideration on this? >> >>And also, if already d

Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

2015-01-13 Thread John Levine
>> First, for a same transaction, the cost from using TCP may be more than the >> gain from the queries you save, which may ultimately let the performance >> become even worse. Do you have any consideration on this? > >And also, if already doing tcp the the auth server, why not just ask the >4 ques

Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

2015-01-13 Thread Mark Andrews
In message , George Michaelson writes: > > Mark.. can you amplify a bit on: > > >FORMERR will just cause the nameserver to think that EDNS is not > >supported. This is not a issue unless there are signed zones and > >the resolver is validating. > > Because somewhere north of 10% of the world

Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

2015-01-13 Thread George Michaelson
Mark.. can you amplify a bit on: >FORMERR will just cause the nameserver to think that EDNS is not > supported. This is not a issue unless there are signed zones and >the resolver is validating. Because somewhere north of 10% of the world now validates.. On Wed, Jan 14, 2015 at 10:09 AM, Mark A

Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

2015-01-13 Thread Mark Andrews
In message , Paul Wouters wr ites: > On Tue, 13 Jan 2015, Davey Song () wrote: > > > As to the draft itself, there are two questions: > > > > First, for a same transaction, the cost from using TCP may be more than > > the gain from the queries you save, which may ultimately let the > > performan

Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

2015-01-13 Thread Paul Wouters
On Tue, 13 Jan 2015, Davey Song (宋林健) wrote: As to the draft itself, there are two questions: First, for a same transaction, the cost from using TCP may be more than the gain from the queries you save, which may ultimately let the performance become even worse. Do you have any consideration on

Re: [DNSOP] comments on draft-ietf-dnsop-edns-client-subnet-00

2015-01-13 Thread Wessels, Duane
Hello All, Some time ago (when there was a Verisign coauthor on this draft) I was asked to review it internally. I'm not sure if all of my comments were passed back, so I am sending them here. Hopefully I have correctly accounted and adjusted for changes between the current version and the one t

Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

2015-01-13 Thread Paul Hoffman
On Jan 13, 2015, at 9:37 AM, Warren Kumari wrote: > > On Tue, Jan 13, 2015 at 9:13 AM, Paul Wouters wrote: >> Also, why hardcode the records on the auth server. I think it is much >> better to leave the auth servers as is, and have resolvers figure out >> dynamically what is often asked in bundl