drc at virtualized.org
Fri Apr 6 15:44:00 CDT 2012
On Apr 6, 2012, at 1:24 PM, Jimmy Hess wrote:
> On Fri, Apr 6, 2012 at 1:24 PM, David Conrad <drc at virtualized.org> wrote:
>> I suspect the root server operators might not like this idea very much.
> If it solves other problems adequately, they might eventually just have to learn to like it.
I was, of course, using the root servers as a proxy for pretty much any DNS server operator. The root server operators aren't unique in the requirement to respond to an unbounded number of queries.
>> Treating a symptom and ignoring the disease. See http://tools.ietf.org/html/bcp38
> No. Implementation of BCP38 does have value, but the existence of
> BCP38 does not solve DNS application problems;
You seemed to have missed the part where it isn't just a DNS problem. Your solution would appear to be to replace every datagram-based query/response protocol such as ICMP and SNMP. I personally think it is more feasible for ISPs to implement BCP38 than it is for the entire Internet to move away from using datagram-based query/response protocols, but that's probably just me.
> but ignoring mitigation of the symptoms,
> despite there being more readily available options for symptom mitigation.
Sorry, which more readily available options are those? I don't think forcing a 3-way exchange for stuff like PMTUD is 'readily available'.
> The underlying problem is that "BCP38" is not really a "best common practice",
> despite the name of the series.
The name of the series is "Best Current Practice".
> Lots of networks don't and will not ever implement BCP38;
It is true that lots of networks don't implement BCP38. Whether or not they will ever is more debatable. I suspect that we're about one major spoofing-based infrastructure attack away from proposed legislation that would force folks to implement something like BCP38, but I may be a bit more pessimistic than most.
However, I would be interested in hearing what the excuses are for folks not implementing BCP38 these days.
More information about the NANOG