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