North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: On-going Internet Emergency and Domain Names

  • From: Gadi Evron
  • Date: Sat Mar 31 23:29:48 2007

On Sat, 31 Mar 2007, Paul Vixie wrote:
> > ...
> > Back to reality and 2007:
> > In this case, we speak of a problem with DNS, not sendmail, and not bind.
> > 
> > As to blacklisting, it's not my favorite solution but rather a limited
> > alternative I also saw you mention on occasion. What alternatives do you
> > offer which we can use today?
> on any given day, there's always something broken somewhere.
> in dns, there's always something broken everywhere.
> since malware isn't breaking dns, and since dns not a vector per se, the
> idea of changing dns in any way to try to control malware strikes me as
> a way to get dns to be broken in more places more often.
> in practical terms, and i've said this to you before, you'll get as much
> traction by getting people to switch from windows to linux as you'd get by
> trying to poison dns.  that is, neither solution would be anything close to
> universal.  that rules it out as an "alternative we can use today".
> but, isp's responsible for large broadband populations could do this in their
> recursion farms, and no doubt they will contact their dns vendors to find a
> way.  BIND9, sadly, does not make this easy.  i'll make sure that poison at
> scale makes the BIND10 feature list, since clustering is already coming.
> at the other end, authority servers which means registries and registrars
> ought, as you've oft said, be more responsible about ripping down domains
> used by bad people.  whether phish, malware, whatever.  what we need is some
> kind of public shaming mechanism, a registrar wall of sheep if you will, to
> put some business pressure on the companies who enable this kind of evil.

I have done public shaming in the past, as you know. I'd rather avoid it
if policy/technology can help out.

Conversationally though, how would you suggest to proceed on that front?

> fundamentally, this isn't a dns technical problem, and using dns technology
> to solve it will either not work or set a dangerous precedent.  and since
> the data is authentic, some day, dnssec will make this kind of poison
> impossible.

Not for the bad guys, unfortunately. :/