North American Network Operators Group

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

Re: what the heck do i do now?

  • From: Jeremy Chadwick
  • Date: Mon Feb 05 18:09:36 2007

On Thu, Feb 01, 2007 at 08:45:52PM +0000, Paul Vixie wrote:
> > 2) maps.vix.com.	604800	IN	NS	u1.vix.com.
> >     maps.vix.com.	604800	IN	NS	u2.vix.com.
> >     maps.vix.com.	604800	IN	NS	u3.vix.com.
> >     ... [as many as you like]
> >     u1.vix.com.		604800	IN	A	192.0.2.1
> >     u2.vix.com.		604800	IN	A	192.0.2.2
> >     u3.vix.com.		604800	IN	A	192.0.2.3
> >     ... [as many as you like]
> 
> i hadn't thought of that.  i'll think seriously about it, thanks.

The caveats to this are:

1) DNS servers which are not configured to blackhole IANA-reserved
   network blocks (read: the majority) will blindly try to reach
   192.0.0.0/17 and friends.

2) Some people (like myself) have ipfw/pf rules which block and
   log outbound packets to reserved blocks.  We log these because
   usually it's the sign of broken software or possibly some weird
   IP routing (read: OS IP stack) problem.  In the case of ipfw (I
   haven't tested pf), the block gets reported to underlying layers
   as EACCES, which can be incredibly confusing for admins.

   Of course, this isn't an issue as long as every service on the
   face of the planet has some form of blackholing.  In the case of
   someone pointing an MX record to something that has an A record
   of 127.255.255.255, for example, and lacks the blackholing
   capability, the service (postfix, sendmail, whatever) will
   blindly try to communicate with that destination, thus spewing
   out nasties on the console or in logfiles.  Example:

00200     1234       93513 deny ip from { 127.0.0.0/8 or 192.168.0.0/16 or 172.16.0.0/12 or 10.0.0.0/8 } to any in recv fxp0
00201        3         180 deny log ip from any to { 127.0.0.0/8 or dst-ip 192.168.0.0/16 or dst-ip 172.16.0.0/12 or dst-ip 10.0.0.0/8 } out xmit fxp0

   As you can see, there's still many routers which don't have
   outbound blocks in place.  Since I do not trust my ISP to do
   this for me, and I believe in taking the initiative, I block
   them locally on the system.  And as you can see (thus case
   in point), I don't have a very up-to-date list of IANA-reserved
   blocks in my list.

   Until I recently added the blackholing rules in BIND, I kept
   seeing the resolver try to contact 127.0.0.0/8 hosts, or 
   10.0.0.0/8 hosts.  People who had things like "localhost" as
   auth. NS entries -- hey, isn't this what you did?!  ;-)

My vote is to simply remove the NS and A records for maps.vix.com
and let people utilise search engines and mailing list archives to
figure out where to go (mail-abuse).

-- 
| Jeremy Chadwick                                 jdc at parodius.com |
| Parodius Networking                        http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, USA |
| Making life hard for others since 1977.               PGP: 4BD6C0CB |