private address 192.168.x.x or 10.x.x.x on a public dns

Kevin Darcy kcd at chrysler.com
Tue Apr 29 00:11:24 UTC 2008


roger wrote:
> Hello,
>
> I am trying to find some information that I already believe to be
> true.
>
> I belive: You shouldn't configure a DNS, that answers queries to the
> internet, with a host that will point to a private address.
>
>
> Our engineering department wants me to do the following:
>
> host      IN       A     192.168.99.154
>
> on a nameserver that answers queries to the internet.
>
>
> I feel this is wrong, I think this is not allowed, but I can not find
> the RFC, book, internet article that will support my claim. My google-
> foo has failed me. Can anyone lend a helping hand, or if someone can
> lead me to documentation that says it is ok to do so would also be
> helpful.
>
>   
Well, RFC 1918 is a BCP (Best Current Practice) document, not an 
Internet Standard, but it says (near the end of section 3):

"Indirect references to such addresses should be contained within the
   enterprise. Prominent examples of such references are DNS Resource
   Records and other information referring to internal private
   addresses."

Seems to me, that if people are implementing RFC 1918 *at*all*, then 
they should follow it *consistently*, including conformance to the 
verbiage above. I'll also note that RFC 1918 was published before RFC 
2119, which firmed up the various "requirement levels", e.g. "SHOULD" 
versus "MUST" and so forth. Many of the "should"s of earlier RFCs have 
been re-interpreted as "must" because there weren't clear distinctions 
before RFC 2119.

But, even if there's nothing technically wrong with putting RFC 1918 
addresses in public DNS, if you include *any* internal DNS names in your 
externally-visible zones -- whether they resolve to routable addresses 
or not -- and *any* of those names are easily guessable and/or you allow 
zone transfers for untrusted clients, then you're exposing information 
about your internal network to would-be attackers, and most 
organizations would be uncomfortable with that from a security standpoint.

Running a split namespace moots this whole issue, but has a few 
challenges, such as ensuring that the right "view" gets zone transferred 
between masters and slaves, and that all of the entries in the external 
DNS also appear in the internal DNS, either in NAT'ed form (if you're 
using NAT; you didn't specify), or _verbatim_.

When you put private, unroutable addresses in your public DNS, then you 
*add* to the inherent security problem of putting internal-only names in 
external DNS, especially if the public names and private names are 
similar to each other, e.g. "form" (for downloading of forms appropriate 
to your business) versus "forum"; one could easily be mistyped for the 
other, potentially causing the user to attempt a connection to an 
internal resource on their own private network, rather than an external 
resource, which might cause unforeseen problems.

                                                                         
                     - Kevin




More information about the bind-users mailing list