DNS noise

Fri Apr 6 20:44:00 UTC 2012

Jimmy,

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.

Regards,
-drc