> Davey Song <mailto: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. today a priming query returns 755 octets of udp payload without dnssec, or 913 octets of udp payload with dnssec. what's missing? 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? 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. 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. -- 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
