DNS Blacklist feature

[Darren Reed]

Moving this to tech-net...

How do we feel about a mod to the resolver library to implement a DNS
blacklist? Verizon and others are starting to resurrect sitefinder on
a local basis. It occurs to me that one self-defense mechanism would
be the ability to add a line to /etc/resolv.conf that declares certain
IP addresses as evil^H^H^H^Hinaccurate and treat responses with those
addresses as returning NXDOMAIN. This would allow users behind those
hijacking DNS servers to identify and redirect the redirection.

What exactly is the problem?
Queries for non-existant names returns an A record that points
to one of their web servers saying "welcome"?
Do they do it when recursion is both enabled and disabled?

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[D'Arcy J.M. Cain]

On Mon, 05 Nov 2007 13:37:01 -0800

Post by Darren Reed
Moving this to tech-net...

How do we feel about a mod to the resolver library to implement a DNS
blacklist? Verizon and others are starting to resurrect sitefinder on
a local basis. It occurs to me that one self-defense mechanism would
be the ability to add a line to /etc/resolv.conf that declares certain
IP addresses as evil^H^H^H^Hinaccurate and treat responses with those
addresses as returning NXDOMAIN. This would allow users behind those
hijacking DNS servers to identify and redirect the redirection.

What exactly is the problem?
Queries for non-existant names returns an A record that points
to one of their web servers saying "welcome"?
Do they do it when recursion is both enabled and disabled?

I didn't want to start the whole NANOG discussion here about why this
is a bad thing, see NANOG archives for that, but here is the short
answer. What does your ssh/ftp/email/irc/etc client do with that
response? The Internet != web pages.

[David Brownlee]

Post by D'Arcy J.M. Cain

Post by Darren Reed
What exactly is the problem?
Queries for non-existant names returns an A record that points
to one of their web servers saying "welcome"?
Do they do it when recursion is both enabled and disabled?

I didn't want to start the whole NANOG discussion here about why this
is a bad thing, see NANOG archives for that, but here is the short
answer. What does your ssh/ftp/email/irc/etc client do with that
response? The Internet != web pages.

Mmmm.. JANET Colour Book Software. (Apologies and a pint of beer
to anyone who gets that reference & relevance - plain apologies
to anyone else :)

[Steven M. Bellovin]

On Mon, 05 Nov 2007 13:37:01 -0800

Post by Darren Reed
Moving this to tech-net...

How do we feel about a mod to the resolver library to implement a
DNS blacklist? Verizon and others are starting to resurrect
sitefinder on a local basis. It occurs to me that one self-defense
mechanism would be the ability to add a line to /etc/resolv.conf
that declares certain IP addresses as evil^H^H^H^Hinaccurate and
treat responses with those addresses as returning NXDOMAIN. This
would allow users behind those hijacking DNS servers to identify
and redirect the redirection. What exactly is the problem?

Queries for non-existant names returns an A record that points
to one of their web servers saying "welcome"?
Do they do it when recursion is both enabled and disabled?

See www.consumeraffairs.com/news04/2007/11/verizon_search.html

And the feature won't help. This nonsense is implemented by Verizon in
their customer-facing caching servers, whose addresses are handed out
by dhcp. You can even opt out, in which case you get different IP
addresses, per
http://netservices.verizon.net/portal/link/help/item?case=c32535 (tell
the form you're using FIOS and Verizon Online).


--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[D'Arcy J.M. Cain]

On Mon, 5 Nov 2007 21:42:44 +0000

Post by Steven M. Bellovin
And the feature won't help. This nonsense is implemented by Verizon in
their customer-facing caching servers, whose addresses are handed out
by dhcp. You can even opt out, in which case you get different IP
addresses, per
http://netservices.verizon.net/portal/link/help/item?case=c32535 (tell
the form you're using FIOS and Verizon Online).

Perhaps I am not explaining myself clearly. The feature doesn't change
the server that you use for DNS. It is meant to examine resonses from
any server that you may be using and if you get a "bad" response it
treats it as NXDOMAIN response. A "bad" response is one that matches
the IPs that you list.

Perhaps an example.

Let's say that I have a DSL modem that picks up my ISP's nameserver
automatically and I use the modem's DNS server on my NetBSD box behind
the modem. I ftp from ftp.NetBSD.ogr. The ISP catches my typo and
returns IP 1.2.3.4 which is it's own "helpful" web server. Since it is
not an ftp server I wind up thinking that NetBSD's ftp server is down.

If I find out that my ISP is redirecting misses to 1.2.3.4 I go
into /etc/resolv.conf and add a line that says that 1.2.3.4 is a "bad"
IP. Now whenever I make a mistake I get a proper response that the
host address I typed is invalid and I can fix my error right away.

[Martin Husemann]

Post by D'Arcy J.M. Cain
Let's say that I have a DSL modem that picks up my ISP's nameserver
automatically and I use the modem's DNS server on my NetBSD box behind
the modem.

Probably stupid question:
isn't it a lot easier to just not use that modems DNS cache at all and
run your own cahing dns on the machine where you'd put the /etc/hosts
lines in (in your example)?

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[D'Arcy J.M. Cain]

On Tue, 6 Nov 2007 11:39:08 +0100

Post by Martin Husemann

Post by D'Arcy J.M. Cain
Let's say that I have a DSL modem that picks up my ISP's nameserver
automatically and I use the modem's DNS server on my NetBSD box behind
the modem.

Certainly not stupid.

Post by Martin Husemann
isn't it a lot easier to just not use that modems DNS cache at all and
run your own cahing dns on the machine where you'd put the /etc/hosts
lines in (in your example)?

For you and I, probably. Is that level of expertise our requirement
for using NetBSD? I would like to think that our system is usable by
people whose expertise lies elsewhere. I know that it is a small fence
but it is a fence nonetheless.

[Darren Reed]

Post by D'Arcy J.M. Cain
On Tue, 6 Nov 2007 11:39:08 +0100

Post by Martin Husemann

Post by D'Arcy J.M. Cain
Let's say that I have a DSL modem that picks up my ISP's nameserver
automatically and I use the modem's DNS server on my NetBSD box behind
the modem.

Certainly not stupid.

Post by Martin Husemann
isn't it a lot easier to just not use that modems DNS cache at all and
run your own cahing dns on the machine where you'd put the /etc/hosts
lines in (in your example)?

For you and I, probably. Is that level of expertise our requirement
for using NetBSD? I would like to think that our system is usable by
people whose expertise lies elsewhere. I know that it is a small fence
but it is a fence nonetheless.

The level of expertise required here is anything but simple.

To even have a chance at making something like this usable by
non-experts would require:
- hard coding in domain name to the DHCP client that it knows will fail,
such as www.verizon-bites-my-ass.netbsd.org (*we* have to have
ultimate control over the name);
- do a query for said name when dhcp-client receives an answer with
DNS servers, sending a query to each server;
- verify that NXDOMAIN is returned by each server or;
- have a list of alternative DNS servers hard coded in somewhere to use
instead.


While we can possibly come up with code to do 1-3, doing 4...how?
How do we choose suitable DNS servers for everyone in the event
that their ISP does this?
Even then there are implied privacy issues with always querying for a
.netbsd.org name (think about it.) Why not use a totally bogus domain
name as the target like www.no-such.domain.exists? That is believably
false and maybe Verizon could be smart about what they do if lots
of people started to use something that was obviously not a real DNS
name as a canary.

But realisticly, this isn't a problem for NetBSD to solve.
One might also ask the question of why it must be a different
experience for NetBSD users vs others.

The problem is an anti-social ISP and as anyone who's been on the
Internet for long enough knows, you cannot solve social problems
by using technology - you can only push them around.

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On Mar 28, 11:46am, "D'Arcy J.M. Cain" wrote:
} On Mon, 5 Nov 2007 21:42:44 +0000
} "Steven M. Bellovin" <***@cs.columbia.edu> wrote:
} > And the feature won't help. This nonsense is implemented by Verizon in
} > their customer-facing caching servers, whose addresses are handed out
} > by dhcp. You can even opt out, in which case you get different IP
} > addresses, per
} > http://netservices.verizon.net/portal/link/help/item?case=c32535 (tell
} > the form you're using FIOS and Verizon Online).
}
} Perhaps I am not explaining myself clearly. The feature doesn't change
} the server that you use for DNS. It is meant to examine resonses from
} any server that you may be using and if you get a "bad" response it
} treats it as NXDOMAIN response. A "bad" response is one that matches
} the IPs that you list.
}
} Perhaps an example.
}
} Let's say that I have a DSL modem that picks up my ISP's nameserver
} automatically and I use the modem's DNS server on my NetBSD box behind
} the modem. I ftp from ftp.NetBSD.ogr. The ISP catches my typo and
} returns IP 1.2.3.4 which is it's own "helpful" web server. Since it is
} not an ftp server I wind up thinking that NetBSD's ftp server is down.
}
} If I find out that my ISP is redirecting misses to 1.2.3.4 I go
} into /etc/resolv.conf and add a line that says that 1.2.3.4 is a "bad"
} IP. Now whenever I make a mistake I get a proper response that the
} host address I typed is invalid and I can fix my error right away.

As a home user, you can generally easily deal with this yourself.
Just add 'named=YES' to /etc/rc.conf and put 'nameserver 127.0.0.1' in
/etc/resolv.conf. You don't need to do any custom configuring of
named. If you're running dhclient, then put this in
/etc/dhclient-enter-hooks and make it executable:

make_resolv_conf() {
}

If you follow these steps, you won't have to care what your ISP is
doing because you won't be using their DNS servers.

}-- End of excerpt from "D'Arcy J.M. Cain"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Geert Hendrickx]

As a home user, you can generally easily deal with this yourself. Just
add 'named=YES' to /etc/rc.conf and put 'nameserver 127.0.0.1' in
/etc/resolv.conf. You don't need to do any custom configuring of named.
If you're running dhclient, then put this in /etc/dhclient-enter-hooks
make_resolv_conf() {
}
If you follow these steps, you won't have to care what your ISP is doing
because you won't be using their DNS servers.

If they're allowing port 53 outbound at all (I don't know)...


Otherwise you'd have to implement your own wrapper around DNS to implement
what OP suggested.


Geert



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Paperino Fusilli]

Post by John Nemeth
As a home user, you can generally easily deal with this yourself.
Just add 'named=YES' to /etc/rc.conf and put 'nameserver 127.0.0.1' in
/etc/resolv.conf. You don't need to do any custom configuring of
named. If you're running dhclient, then put this in
make_resolv_conf() {
}

or add to your /etc/dhclient.conf
interface "YOUR_dhclient_IF" {
# prepend domain-name " your.own.domain";
prepend domain-name-servers 127.0.0.1;
}





--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de