Re: [DNSOP] Fwd: I-D Action: draft-song-dnsop-tcp-primingexchange-00.txt

[Paul Vixie <[e-mail]>]

> Davey Song <mailto:[e-mail]>
> Friday, November 28, 2014 12:22 AM
>
> On Fri, Nov 28, 2014 at 3:21 PM, Paul Vixie <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>     for example, if 13 is good, would 130 (10X) or 1300 (100X) be better?
>     even with 1300 root name servers, the fallback to TCP after TC=1 in a
>     priming query (even with EDNS) would only add one extra round trip
>     over
>     the three that are required to run a TCP query. since priming queries
>     are uncommon, i still don't see why that first round trip is worth
>     avoiding.
>
> At least we can try Fast Open TCP on it to save more round for
> performance purpose .

if it's a rare query, then what is the payback for the complexity of
treating this query differently from other dns queries?
>  
>
> Priming exchange is special because this exchange lead the people to
> the unique name space of Internet. If we share the same dream of "One
> World One Internet" ,

you know i do.

> any extra effort is deserved to protect its resiliency in IPv6
> network(section 2.1), integrity with fully signed(section 2.2) and
> more NS server to enable more participation of  CDOs. (section 2.3)

with respect to ipv6 support, as marka@isc said, ipv6 nodes must support
edns, and a minimum of 1280 bytes. this means that without truncation or
TCP, all 13 servers can have their AAAA RR's returned in a single round
trip.

with respect to dnssec support, dnssec does not sign glue. there is one
signature, over the NS RRset for the ".", which as shown in my previous
example, fits with all 13 A RR's and 12 AAAA RR's in less than 1000 octets.

with respect to enabling more participation by CDO's, that is not a
technical consideration, but i think you can progress that matter by
modeling the optimal number of root name servers for the expected RDNS
population and the expected AS graph. in other words, if more would be
better for the internet itself, in terms of reliability and performance
and security and resiliency, that is a technical consideration worth
arguing here.

vixie