North American Network Operators Group

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

Re: Why is RFC1918 space in public DNS evil?

  • From: Fred Baker
  • Date: Mon Sep 18 09:12:22 2006
  • Authentication-results:; [email protected]; dkim=pass (sig from verified; );
  • Dkim-signature: a=rsa-sha1; q=dns; l=1351; t=1158584696; x=1159448696;c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;; [email protected]; z=From:Fred=20Baker=20<[email protected]>|Subject:Re=3A=20Why=20is=20RFC1918=20space=20in=20public=20DNS=20evil?;; b=LSw0se5wgrYnSH3C0ceXWhAQutjn3Bu2BBhSIlc/5ciO/yJPpUnQX9onQmcbhbpi3w+Jg7vngTJfEKsgQyPHWcROTCvKTKx9YluDoKeg1ebf5SgASWjrFMyT776rshyg;

I know the common wisdom is that putting 192.168 addresses in a public zonefile is right up there with kicking babies who have just had their candy stolen, but I'm really struggling to come up with anything more authoritative than "just because, now eat your brussel sprouts".
I think the best answer to that is to turn it on its head.

As Joe points out, exposing interior information unnecessarily is a security risk - leaving a treasure map with "X marks the spot" invites pirates of all sorts. In this case, it is not only exposing interior information ( unnecessarily, but also in a way that doesn't actually help anyone else. The address of my telephone is But do a traceroute to that address (ar the address of my family computer, which is, and I about guarantee that you will come to a different computer, for the simple reason that you aren't in any of my private domains.

So putting those addresses in the public DNS actually *only* helps me if I am someone who is bombarding your prophylactic defenses with messages intended to reach your chewy innards. Anyone else has no actual use for the internal addresses.

I think the right question for your client is: "why exactly did you want to do that?"