I agree, the priming volume for a private enterprise is on a much smaller scale
than the public Internet. But, at the same time, a notable difference between
priming and normal DNS traffic (or mDNS, or ARP, etc.) is that priming traffic
is more likely to traverse WAN links (because, unlike the public Internet, the
root-server pool is typically a fairly *centralized* subset of all the
published nameservers in the enterprise, since root servers generally only live
in datacenters or "major" sites). WAN bandwidth cost-efficiencies haven't kept
pace with other areas of information technology. This can, of course, be
optimized using techniques like authoritative-nameserver Anycast, but, to be
honest, not all organizations have the technological wherewithal to implement
that.
As for how much priming traffic... what if an organization wanted to implement
full-service resolvers on all of its endpoints (e.g. to provide "end-to-end"
DNSSEC coverage)? Endpoints reboot or restart *a*lot*. When you have tens of
thousands, or hundreds of thousands of endpoints that could prime several times
a day, and priming is TCP instead of UDP, that might make such an approach
cost-prohibitive. IMO, the desire to achieve some artificial "parity" between
transport protocols, for priming, shouldn't displace security-enhancing
approaches like end-to-end DNSSEC, into the "economically infeasible" category.
I admit, I haven't worked out the economics of this down to the last penny. I'm
still more of a technologist than a businesscritter. But I see a lot of
potential downside in allowing TCP priming and, frankly, the arguments for it,
seem to be rather fluffy (parity, really?)
- Kevin
-----Original Message-----
From: Joe Abley [mailto:[email protected]]
Sent: Friday, October 16, 2015 5:18 PM
To: Darcy Kevin (FCA)
Cc: dnsop WG
Subject: Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming
On 16 Oct 2015, at 16:36, Darcy Kevin (FCA) wrote:
> It would be wise to get a clear statement of preference from the
> Internet root operators on this, but don't forget that whatever gets
> defined in IETF standards, and implemented in leading DNS software
> packages, also affects private enterprises too. Many of us run
> internal roots and I, for one, don't want to see an influx of traffic
> and/or spiky saturation of bandwidth, because priming suddenly morphed
> from UDP to TCP in the latest software update.
Let's make sure we put this in perspective, though -- how often do your
resolvers restart? If it's once per few months to apply a kernel patch, then
we're talking about far less traffic than your printers, phones and laptops are
spewing every second onto the network with mDNS (or ARP, even :-)
Real root servers deal with internet-scale numbers of resolvers. It seems
unlikely you have that problem in your campus network.
Joe
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
