Thanks Paul. Please see the reply in line. On Thu, Nov 27, 2014 at 10:41 AM, Paul Vixie <p...@redbarn.org> wrote:
> > > Davey Song <songlinj...@gmail.com> > Wednesday, November 26, 2014 11:18 AM > Hi folks, I just post a draft on Priming Exchange over TCP. Comments are > welcome! > > > davey, your abstract says "DNS payload size limitation constrains > operational and policy choice for many years." your document does not give > any examples of specific operational or policy constraints caused by this > limitation. > I try to address the constraints in section 2, see "2. Operational and policy constraints with Priming Exchange" . Actually, I start to study the constraint from your draft (draft-ietf-dnsop-respsize-15) > today a priming query returns 755 octets of udp payload without dnssec, or > 913 octets of udp payload with dnssec. what's missing? > If a priming query only contains the existing NS/A/AAAA RRset of root zone, and do not sign for A/AAAARRset, it will be OK, given UDP fragmentaion dose not happen. But if it constrains the operational possibility for the root zone operator who want to address issue in section2.2 and section 2.3. > if EDNS is not used then TC=1 will cause TCP fallback, thus giving us > either one round trip for EDNS, or four round trips (one TC=1 UDP, then > three for TCP) for non-EDNS. in your model, we would always use three round > trips. what does this optimize for? > In you draft (draft-ietf-dnsop-respsize-15) ,it mentioned "Note that truncation of the additional data section might not be signaled via the TC bit since additional data is often optional (see discussion in Appendix B of [RFC4472]).". I execute "dig . ns +noedns @l.root-servers.net " on my desktop and receive a reply packets (<512bytes) without truncated. So in that case the resolver will not issue any other AAAA query. it lose other AAAA records. As to the optimization, Fast open TCP (dickinson-dnsop-5966-bis, ietf-tcpm-fastopen) may helps in that case involving only 1 or 2 rounds trips. it need more work to test Fast open TCP to check whether (or to what extent) it can relieve the constraints described in section 2. > your reference to [I-D.lee-dnsop-scalingroot] is in error. that draft > specifies two NS RR's, each having one A RR and one AAAA RR. thus, a > priming response from an authority server using that approach would fit > easily in 512 octets (without EDNS), with or without DNSSEC. > Yes. It's my problem. "13 to millions" is not your word in the draft. I should be more precise. > you wrote: > > The author of this memo is the advocate for DNS over TCP, especially > on the very occasions when it is needed. In this memo, the priming > exchange is identified as one of these occasions. > > > you have nowhere shown cause why root priming would be one of those > occasions > > > you wrote: > > From the technical point of view, the number of NS server should be > treated as a parameter of the root system, rather than a constant > making the root server as some kind of rare resource of Internet > which only incurs constant disputes with Internet governance issue. > > > you say "from a technical point of view" but then you give a completely > non-technical reason. this makes your intent difficult to understand. > > later you say "Without actions above, be aware of the large possibility of > risk due to truncated UDP packets or fragmentation", but you give no > specific examples. what risks do you know of -- and are we facing them > today? > > in your listing of pro's and con's for this proposal, you note as a "pro": > > 1)Adding full A/AAAA address of Root server in priming response, > which will enhance the resiliency of Root system for IPv6 users, > especially under the consideration of IPv6-only deployment > [I-D.song-sunset4-ipv6only-dns]. > > > i am appending below my signature a priming query performed just now, > using EDNS and DNSSEC. as you will see, all IPv6 addresses are present, and > there is plenty of room for additional addresses. > > with specific reference to your mention of "constant disputes with > Internet governance issue", the only constantly disputed internet > governance issue i am aware of in the area of DNS root name service is the > desire by several national governments around the world to have a root name > server "letter" of their own, for prestige reasons. i usually dismiss this > as crazy talk, as you know. if however that is one of your concerns, then i > suggest you address it as a policy matter and not as a technical matter. > if someone told you that more countries can't have their own "root name > server letter" because root DNS priming queries don't use TCP by default, > then i would appreciate knowing exactly who said it, and in what context, > and when. > > I try to express the idea: is there any possibility that if we can breaks the rareness of Root servers. The arguments and disputes will cease accordingly. Actually this idea is out of the scope of this draft. -- > Paul Vixie > > > re: > > ; <<>> DiG 9.10.1b1 <<>> @f.root-servers.net +dnssec > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45593 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 25 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;. IN NS > > ;; ANSWER SECTION: > . 518400 IN NS k.root-servers.net. > . 518400 IN NS f.root-servers.net. > . 518400 IN NS j.root-servers.net. > . 518400 IN NS i.root-servers.net. > . 518400 IN NS a.root-servers.net. > . 518400 IN NS d.root-servers.net. > . 518400 IN NS m.root-servers.net. > . 518400 IN NS g.root-servers.net. > . 518400 IN NS e.root-servers.net. > . 518400 IN NS b.root-servers.net. > . 518400 IN NS l.root-servers.net. > . 518400 IN NS c.root-servers.net. > . 518400 IN NS h.root-servers.net. > . 518400 IN RRSIG NS 8 0 518400 > 20141203170000 20141126160000 22603 . > KdqZRoBzFv8Uzh6jksly2gCNGzaJtqa4c3P8LScFLQiPSh/pZ8DP+/Zb > pIIEYBON23y2cQBQF0KrFbOr3nlVHieYTSP76Y6VBPRa11V7f8GVrC47 > bKdCULo5esc1u6C7OOCerLrXabP1UNdGq0SWfIXnyquJ6fhBVn0rt6jv jCw= > > ;; ADDITIONAL SECTION: > a.root-servers.net. 3600000 IN A 198.41.0.4 > a.root-servers.net. 3600000 IN AAAA 2001:503:ba3e::2:30 > b.root-servers.net. 3600000 IN A 192.228.79.201 > b.root-servers.net. 3600000 IN AAAA 2001:500:84::b > c.root-servers.net. 3600000 IN A 192.33.4.12 > c.root-servers.net. 3600000 IN AAAA 2001:500:2::c > d.root-servers.net. 3600000 IN A 199.7.91.13 > d.root-servers.net. 3600000 IN AAAA 2001:500:2d::d > e.root-servers.net. 3600000 IN A 192.203.230.10 > f.root-servers.net. 3600000 IN A 192.5.5.241 > f.root-servers.net. 3600000 IN AAAA 2001:500:2f::f > g.root-servers.net. 3600000 IN A 192.112.36.4 > h.root-servers.net. 3600000 IN A 128.63.2.53 > h.root-servers.net. 3600000 IN AAAA 2001:500:1::803f:235 > i.root-servers.net. 3600000 IN A 192.36.148.17 > i.root-servers.net. 3600000 IN AAAA 2001:7fe::53 > j.root-servers.net. 3600000 IN A 192.58.128.30 > j.root-servers.net. 3600000 IN AAAA 2001:503:c27::2:30 > k.root-servers.net. 3600000 IN A 193.0.14.129 > k.root-servers.net. 3600000 IN AAAA 2001:7fd::1 > l.root-servers.net. 3600000 IN A 199.7.83.42 > l.root-servers.net. 3600000 IN AAAA 2001:500:3::42 > m.root-servers.net. 3600000 IN A 202.12.27.33 > m.root-servers.net. 3600000 IN AAAA 2001:dc3::35 > > ;; Query time: 34 msec > ;; SERVER: 2001:500:2f::f#53(2001:500:2f::f) > ;; WHEN: Thu Nov 27 02:21:54 UTC 2014 > ;; MSG SIZE rcvd: 913 > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
