i wrote:
... confuse and make errors for whoever queries it:
@ SOA localhost hostmaster.localhost NS localhost localhost A 127.0.0.1 * MX 0 localhost A 127.0.0.1
if you put a zone like that in place on a server that's receiving unwanted queries for some zone, they will soon stop, or not. you win either way -- the queries stop, or you laugh your ass off.
dan answered:
There weren't rfc1918.
i'm sorry if i mixed too many topics in one post. it doesn't have to be rfc1918. let's say that someone registers a zone, let's call it nanogtest.vix.com, and points it at your nameservers without your permission. in response, let's create a zone file with this content: --- @ SOA localhost hostmaster.localhost 42 3600 1800 604800 3600 NS localhost localhost A 127.0.0.1 * MX 0 localhost A 127.0.0.1 --- note that this content is all-purpose. it doesn't matter what the real zone is called. in bind's named.conf, add something like this: --- zone "nanogtest.vix.com" { type master; file "pri/nanogtest.vix.com"; }; --- and you're done. any query that anyone sends to your server for that zone will be sent something that will hurt them. eventually they will realize that it's hurting them, and they will stop.
Paul Vixie wrote:
@ SOA localhost hostmaster.localhost 42 3600 1800 604800 3600
Or if you're feeling really PO'd about a piece of spyware crap that got itself installed by convincingly imitating a browser's "Could not find server" error dialog: $ORIGIN internet-optimizer.com. $TTL 31536000 @ SOA localhost. root.localhost. ( 1 1h 30m 7d 1h ) @ NS localhost. * A 127.0.0.1 Would it be asking too much to see BIND10 implement something like: $TTL when_hell_freezes_over TIA!
Paul Vixie wrote:
and you're done. any query that anyone sends to your server for that zone will be sent something that will hurt them. eventually they will realize that it's hurting them, and they will stop.
yes but you pointed out before, deploying this would not be a good idea when the queries are coming in from spoofed source addresses .. the best thing for that would be to filter these out. srs
suresh@outblaze.com (Suresh Ramasubramanian) writes:
and you're done. any query that anyone sends to your server for that zone will be sent something that will hurt them. eventually they will realize that it's hurting them, and they will stop.
yes but you pointed out before, deploying this would not be a good idea when the queries are coming in from spoofed source addresses .. the best thing for that would be to filter these out.
someone else pointed that out. i don't agree. you can send back three things. icmp-unreach (if there's no nameserver running where the bogus NS+A is pointing); or servfail (or upward delegation) if there's a name server running where the bogus NS+A points but it does not serve the zone; or harmful garbage designed to shift the pain back toward the person who pointed the bad traffic at you in the first place. it's possible that with spoofed-source, these three alternatives are interchangeable. it's definite that filtering out spoofed-source is the best thing to do, but since this is way harder to do as a recipient than as a sender, it's not a realistic alternative to running a dns server with deliberately bad zone data. -- Paul Vixie
participants (4)
-
Mike Lewinski -
Paul Vixie -
Paul Vixie -
Suresh Ramasubramanian