public FQDN resolves to private IP

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Greg Mohr - 26 Jul 2005 18:59 GMT

I just took over a network where a developer set the sub-domain,
metal.domain.com to a private IP address, 192.168.9.99 on a public DNS server
he controls. Now I have to take over the domain and bring it home to the
corporation.

The server handles a LOB app and is at a co-location with VPN's to 5
branches. Not all of the branches use the domain.local as their domain. I
am looking for the best way to maintain the metal.domain.com on the
application without having to go and have the application break by taking
away the DNS entry or recoding the application.

Any help or suggestions would be appreciated.

T.I.A.
Greg

Reply to this Message

Steve Duff [MVP] - 26 Jul 2005 23:30 GMT

Is the problem that these 5 sites are all using their own, independent DNS servers to resolve names? If so, I'd suggest using
secondary zones on those DNSen, pulling from your common primary, authoritative DNS server for that domain. If they have Windows
2003 Server DNS, they can use stub zones or conditional forwarding to achieve the same thing more simply.

Alternatively, if it is a relatively small number of workstations, you can simply use a HOSTS file hack to overrule DNS for that
FQDN. This of course has very little intrinsic appeal, but it does work just fine and is easy to setup -- if not maintain over time.

RFC1918 recommends that IANA-private addresses not be "visible" on a public DNS server. However I don't know that in a situation
like this it would really create any problems as the only ones that should be looking at the metal... name would be your own
internal clients and so there isn't any ambiguity with the IP address. It depends somewhat on your definition of "visible."

Steve Duff, MCSE, MVP
Ergodic Systems, Inc.

>I just took over a network where a developer set the sub-domain,
> metal.domain.com to a private IP address, 192.168.9.99 on a public DNS server
[quoted text clipped - 11 lines]
> T.I.A.
> Greg

Reply to this Message

Greg Mohr - 26 Jul 2005 23:46 GMT

Steve,

Three of the offices have servers, but they are subsidiary companies and I
am not allowed to change domains on them. 2 are using DHCP appliances.

On the network, they seem to be able to find, metal.domain.local, but I
cannot verify this from 2 of the networks.

Unfortunately all of the servers are W2K as the previous IT person had a
major aversion to anything MSFT. I am doing major cleanup and getting back
to standards and best practices.

The new host provider for the domain for email and website will not create a
sub-domain with a private address, so I guess I'm screwed there unless I send
out an email to everyone with a batch file to install a new LMHOSTS file.

Greg

> Is the problem that these 5 sites are all using their own, independent DNS servers to resolve names? If so, I'd suggest using
> secondary zones on those DNSen, pulling from your common primary, authoritative DNS server for that domain. If they have Windows
[quoted text clipped - 25 lines]
> > T.I.A.
> > Greg

Reply to this Message

Steve Duff [MVP] - 28 Jul 2005 06:28 GMT

I don't understand how you are serving a .local TLD zone on a public DNS, but regardless
f you cannot administer the individual DNS servers to reflect the zone and cannot add the
required entries on the public side, you have few choices but to use HOSTS files on the workstations.

One alternative that might work is to simply grab a small slice of non-private IP space, and
overlay that onto your internal NIC as secondary addressing. If your ISP allows you to point to a public IP
outside your allotted addresses (a few don't), then you can direct the workstations through the public
DNS that way.

Of course, this makes a little bit of a mess and you lose the ability to talk to that public subnet so you have
to choose somewhat carefully. And the VPN gateway routers have to be able to handle this configuration
to get the traffic to you.

Steve Duff, MCSE, MVP
Ergodic Systems, Inc.

> Steve,
>
[quoted text clipped - 44 lines]
>> > T.I.A.
>> > Greg

Reply to this Message

Kevin D. Goodknecht Sr. [MVP] - 28 Jul 2005 07:31 GMT

> I just took over a network where a developer set the sub-domain,
> metal.domain.com to a private IP address, 192.168.9.99 on a public
[quoted text clipped - 7 lines]
> application break by taking away the DNS entry or recoding the
> application.

I would imagine the reason he has a sub domain with private addresses is to
prevent having to use hosts files to resolve resources used over the VPN.
I do this myself for one client that required his users to use a VPN to
access all of his ftp sites.

Signature

Best regards,
Kevin D4 Dad Goodknecht Sr. [MVP]
Hope This Helps
===================================
When responding to posts, please "Reply to Group"
via your newsreader so that others may learn and
benefit from your issue, to respond directly to
me remove the nospam. from my email address.
===================================
http://www.lonestaramerica.com/
===================================
Use Outlook Express?... Get OE_Quotefix:
It will strip signature out and more
http://home.in.tum.de/~jain/software/oe-quotefix/
===================================
Keep a back up of your OE settings and folders
with OEBackup:
http://www.oehelp.com/OEBackup/Default.aspx
===================================

Reply to this Message

Greg Mohr - 28 Jul 2005 14:03 GMT

I finally got in touch with the developer and that is exactly why she did
this. She current hosts the DNS records on here NS and wants to migrate
that back to the company. She definitely worked outside of the standards
and now I have to provide a way to fix it without breaking the company's
main LOB application. I am not a great DNS person, so I 'm sort of left
hanging here looking for a best solution without breaking the app. I have a
new host to take over the website and email, as well as host the DNS for the
domain, but I still don't know which would be the best way to handle this,
outside of trying to get lmhosts on every PC.

The server that hosts the LOB app is co-located and has static VPN's set up
for each office.

Greg

> > I just took over a network where a developer set the sub-domain,
> > metal.domain.com to a private IP address, 192.168.9.99 on a public
[quoted text clipped - 12 lines]
> I do this myself for one client that required his users to use a VPN to
> access all of his ftp sites.

Reply to this Message

Kevin D. Goodknecht Sr. [MVP] - 28 Jul 2005 15:18 GMT

> I finally got in touch with the developer and that is exactly why she
> did this. She current hosts the DNS records on here NS and wants to
[quoted text clipped - 9 lines]
> The server that hosts the LOB app is co-located and has static VPN's
> set up for each office.

I can't say she worked outside the standards because I don't think there is
a rule that says you can't publish a record with a private IP in a public
zone, as long as the IP conforms to IANA's allowed private IPs.
As to the part about you trying to find away around this, I don't really
understand what you are trying to achieve or why you can't continue to use
something that works. After all, the private record is useless without the
VPN connected, so it can't be construed as a security risk. That is, as long
as the VPN server and accounts allowed to connect by VPN are secured with
strong passwords.

Signature

Reply to this Message