Using public DNS for internal network?

[KapsZ28]

I've posted about this before, but I am trying to get some additional information. Our company is an ISP and also a Cloud provider, mostly hosted servers. We have 6 public DNS servers, technically Linux BIND that our ISP customers use. Now we use these 6 public DNS servers for almost our entire internal network as well with the exception to our AD domain that is setup for vCenter. Since we are using it for our internal network, all of our internal IP addresses are published with a DNS name. Obviously this is not good. However, Zone Transfers is not enabled, so you can't use that to get a complete list of our DNS entries.

Being that zone transfers is not allowed, what are the real risks of having our internal IP addresses on our public DNS server? I was also told that our internal IPs will not be published to other DNS servers around the world.

 

[TCM]

Where's the problem with setting up different views for internal/rest?

 

[KapsZ28]

I'm not sure what that has to do with security.

Based on what I have been reading, a split-split architecture is the most secure solution.

 

[TCM]

Well if you are unable to run two different DNS daemons on different IP addresses, 2 different views are your best option.

Internal names really shouldn't be on the outside.

 

[KapsZ28]

We actually already have two DNS daemons on separate networks. One is internal and the other is public. However the internal one is only used for VMware and the public DNS is used for everything else. My goal is to separate them completely, but I also need to show our CTO that it is setup incorrectly. So I am looking for ways to exploit our public DNS to get information on our internal network to show him that it should not be setup this way. The only way I know of is doing a zone transfer which is disabled.

 

[TCM]

You don't have to show an actual "exploit" to justify a best practice. If your CTO doesn't understand that, good luck to you and run from that place as fast as you can.

 

[KapsZ28]

He is open to suggestions, but just wants a good justification. He is one of those, "if it ain't broke, then don't fix it" kind of guys. On top of all this, our DNS servers are not even behind a firewall. We probably have at least 15 servers directly on the public Internet. I don't know how they have made it this long without any serious hacks.

 

[mwarps]

Run away screaming. Don't even bother giving notice, just run.

Are you providing public recursive or public authoritative?

Have you actually checked to see if zone transfers are disabled, with dig AXFR? or are you just taking for granted that zone transfers are disabled?


He wants a good justification?

"You're a fucking idiot, Mister CTO. No one with a tenth of a brain in their heads leaves DNS servers open and unprotected. Fuck knows how completely un-configured the servers themselves are. You probably don't even log queries. You're probably being used as an attack vector."

 

[KapsZ28]

Yes, I tried using dig axfr and it failed. I asked him and he said all DNS servers are setup as masters. They make all their changes on one DNS server and then use a script to copy the information to the other DNS servers.

It is public recursive.

They also use DNS to designate location of servers and other devices. So we have a server in LA called backup01 and another server in NY called backup01. The DNS entry for the one in LA is backup01.la.domain.net and the one in NY is backup01.ny.domain.net. Our internal AD domain is corp.domain.net. So If I move everything to the internal DNS, the naming convention would be backup01.la.corp.domain.net and backup01.ny.corp.domain.net which I am not overly thrilled about. All other companies I have worked at used a naming convention for computers to designate location. Such as BULA01 and BUNY01 instead of relying on DNS to determine the location.

Another issues is that some Linux servers are administered with a local account. Others are through OpenLDAP and then the Windows environment using AD. Eventually they would like to just use AD instead of OpenLDAP. To do this everything will need a unique name.

So, do I spend the time moving about 700 records from public DNS to internal DNS which would also require adding "corp" into the FQDN and updating a ton of other systems that are using DNS to resolve the names. Or do I start renaming devices first, then moving them to internal DNS, and eventually joining them to AD?

 

[mwarps]

Yes, I tried using dig axfr and it failed. I asked him and he said all DNS servers are setup as masters. They make all their changes on one DNS server and then use a script to copy the information to the other DNS servers.

ow. this is really archaic. stop it.

It is public recursive.

Good. Unless the public recursive is also answering domain.com, delegated through the chain, you're afforded at least that small level of "protection"..

They also use DNS to designate location of servers and other devices. So we have a server in LA called backup01 and another server in NY called backup01. The DNS entry for the one in LA is backup01.la.domain.net and the one in NY is backup01.ny.domain.net. Our internal AD domain is corp.domain.net. So If I move everything to the internal DNS, the naming convention would be backup01.la.corp.domain.net and backup01.ny.corp.domain.net which I am not overly thrilled about. All other companies I have worked at used a naming convention for computers to designate location. Such as BULA01 and BUNY01 instead of relying on DNS to determine the location.

naming is naming. You can do it in the hostname, or you can have it as a subdomain. matter of management preference.

Another issues is that some Linux servers are administered with a local account. Others are through OpenLDAP and then the Windows environment using AD. Eventually they would like to just use AD instead of OpenLDAP. To do this everything will need a unique name.

Someone really needs to get their shit together here.. separate servers should always have unique names, and .. using AD for Linux makes my skin crawl (not saying it doesn't work, but I wouldn't trust it). Infrastructure should always have uniform access.

So, do I spend the time moving about 700 records from public DNS to internal DNS which would also require adding "corp" into the FQDN and updating a ton of other systems that are using DNS to resolve the names. Or do I start renaming devices first, then moving them to internal DNS, and eventually joining them to AD?

This is an absolute shit show. "corp" DNS needs to be in its own view. your internal infrastructure should never be exposed, under any circumstances.

EDIT: DNS is easy. "moving 700 records" involves an IXFR or AXFR and importing to a corp.blah.puke with its own view. ... unless the zone files are all garbled.. then you can get friendly with grep.

 

[KapsZ28]

ow. this is really archaic. stop it.

Yeah, I am not sure why they went with it. Most likely because that is what they were used to.

naming is naming. You can do it in the hostname, or you can have it as a subdomain. matter of management preference.

Someone really needs to get their shit together here.. separate servers should always have unique names, and .. using AD for Linux makes my skin crawl (not saying it doesn't work, but I wouldn't trust it). Infrastructure should always have uniform access.

I don't mind using sub-domains to determine the location, but it is the lack of unique names that bothers made, especially if we plan on moving everything into a single LDAP. That is why I was thinking about creating a standard naming convention and re-naming the servers before moving everything into the internal DNS.

As far as the AD for Linux, the purpose would be for maintaining access and rights for everyone. Right now we have AD for the Windows environment and OpenLDAP for Linux. Is there any other way to centrally manage both without joining the servers to AD?

This is an absolute shit show. "corp" DNS needs to be in its own view. your internal infrastructure should never be exposed, under any circumstances.

EDIT: DNS is easy. "moving 700 records" involves an IXFR or AXFR and importing to a corp.blah.puke with its own view. ... unless the zone files are all garbled.. then you can get friendly with grep.

That is the goal to move all internal records off the public DNS and into the internal DNS. Problem is the internal DNS is Windows DNS. So I am not sure the IXFR and AXFR commands will help.

 

[Red Squirrel]

I don't see how it could be a security issue if people can see your internal IPs (basically what having the DNS on the external would do). My router's main IP is 10.1.1.1, my main server is 10.1.1.10. Does not matter if there are any exploits on those machines, by knowing that information there's no way you're getting in.

I would still prefer to put the DNS server locally though. If the internet goes down it will still be accessible.

 

[KapsZ28]

I don't see how it could be a security issue if people can see your internal IPs (basically what having the DNS on the external would do). My router's main IP is 10.1.1.1, my main server is 10.1.1.10. Does not matter if there are any exploits on those machines, by knowing that information there's no way you're getting in.

I would still prefer to put the DNS server locally though. If the internet goes down it will still be accessible.

Any information a hacker can get about your internal network is a security issue and DNS is one of the first places they look to obtain this information. Not only can they get the internal IP address, but if your hosts name have information about what the server does, then they also know what to exploit. Example: I gain access to your DNS and find a server called MSSQLDB01 at 10.0.0.20. Now I know what exploits to use when I attack that server, such as SQL injection. You don't want any internal information available publicly.

 

[Red Squirrel]

Any information a hacker can get about your internal network is a security issue and DNS is one of the first places they look to obtain this information. Not only can they get the internal IP address, but if your hosts name have information about what the server does, then they also know what to exploit. Example: I gain access to your DNS and find a server called MSSQLDB01 at 10.0.0.20. Now I know what exploits to use when I attack that server, such as SQL injection. You don't want any internal information available publicly.

And how are you going to connect to 10.0.0.20 that is on MY network? That was kind of my point...

If you happen to BE on my network, then you'll also have access to the DNS server.

Regardless, I don't really think it's a good practice anyhow, I just don't think it's that huge of a security risk that people are making it out to be. Unless there is something here that I'm completely missing. I guess one risk is if someone hacks into the DNS server they could make internal stuff actually point to the outside.

That brings up another interesting topic, server naming. It's not a bad idea to use a naming scheme that does not identify what the server is for. If someone with access does want to cause damage they'll know what server may have the most likely exploits and also which one will do the most damage if brought down.

 

[TCM]

Regardless, I don't really think it's a good practice anyhow, I just don't think it's that huge of a security risk that people are making it out to be.

It doesn't matter if you think it's a risk or not. It's not necessary and that's enough reason not to do it. That's how you think in security.

And internal network doesn't automatically mean RFC1918.

 

[KapsZ28]

And how are you going to connect to 10.0.0.20 that is on MY network? That was kind of my point...

Well, that is kind of the point to hacking. If everything on an internal network could not be accessed, then all this security wouldn't be necessary. The first part of hacking is reconnaissance. Gaining all the information you can about your target, especially their internal network.

 

[DeChache]

And internal network doesn't automatically mean RFC1918.

Yep all of our machines have public IPs.

I can sit here and find the internal network name of the printer next to my office. Hmmm looks like we have the same problem.... I'm not network though.... I run media servers straight on the internet with only the windows firewall.... No firewall just router ACLS

We actually just sub-neted out network used to have a giant flat class C network....


Any way OP I feel your pain but I just get told I have no idea because I'm not on the network team.

 

[Red Squirrel]

Yep all of our machines have public IPs.

I can sit here and find the internal network name of the printer next to my office. Hmmm looks like we have the same problem.... I'm not network though.... I run media servers straight on the internet with only the windows firewall.... No firewall just router ACLS

We actually just sub-neted out network used to have a giant flat class C network....


Any way OP I feel your pain but I just get told I have no idea because I'm not on the network team.

Yikes why would they use external IPs? Seems like a lot more work to maintain and much more risk. Not to mention cost. IP's arn't free.

 

[DeChache]

Yikes why would they use external IPs? Seems like a lot more work to maintain and much more risk. Not to mention cost. IP's arn't free.

Because that's the way it's always been done?.?.?. Up to a year ago we had somebody manually assigning all the addresses for the network. No DHCP all manually assigned. I really have no idea why.

I'm low man and in the multimedia group. The guy on the street has more say in the network than I do.

 

[KapsZ28]

Wow, good to know I am not the only one out there. But hopefully I will be completely re-vamping their entire infrastructure.

 

[KapsZ28]

I have a question about Linux BIND. I was told that something as simple as missing a "period" at the end entry can cause major issues. Not only for that entry, but possibly the entire server.

Example: mail.domain.com has to be entered as mail.domain.com. with a period at the end or it can break DNS.

I can imagine the DNS entry not working if it isn't formatted properly, but I was told that a small mistake like this can also break the entire DNS server. Any truth to this, or are there other ways to easily break Linux BIND?

 

[TCM]

A missing dot makes that data relative to the current $ORIGIN, e.g.

foo CNAME bar

in a zone "baz" means "foo.baz" points to "bar.baz" and not just "bar".

foo CNAME bar.

means "foo.baz" points to "bar".

That's basically it. You need to be aware of it but I don't know what they mean by breaking the entire DNS server. Maybe if you accidentally claim too much authority it can break name resolution but I'm not really sure.

 

[Red Squirrel]

What sucks is when you do a syntax error, restart the server and it fails, then you have to scramble to find the syntax error because the server is down till you fix it. One of these days I want to code a web based program to automate stuff like this.

 

[TCM]

Don't restart the server. rndc reload

 

[KapsZ28]

So I just found that our OpenLDAP and syslog servers have public IP addresses. And of course all our Linux servers have SSH enabled on the public IP. Of course that is among all the other ports that are open as well.

 

[Christopher]

What sucks is when you do a syntax error, restart the server and it fails, then you have to scramble to find the syntax error because the server is down till you fix it. One of these days I want to code a web based program to automate stuff like this.

named-checkconf -z

 

[mwarps]

I have a question about Linux BIND. I was told that something as simple as missing a "period" at the end entry can cause major issues. Not only for that entry, but possibly the entire server.

Example: mail.domain.com has to be entered as mail.domain.com. with a period at the end or it can break DNS.

I can imagine the DNS entry not working if it isn't formatted properly, but I was told that a small mistake like this can also break the entire DNS server. Any truth to this, or are there other ways to easily break Linux BIND?

Missing a . can cause SERVFAIL under some circumstances for an entire zone. If you miss a . in a conf file, either it won't load or it'll just not start.

Get a book, please.. and read it.
http://www.amazon.com/Pro-DNS-BIND-Ron-Aitchison/dp/1590594940

Cricket Liu's (O'Reilly) books are also very good.

 

[TCM]

Missing a . can cause SERVFAIL under some circumstances for an entire zone. If you miss a . in a conf file, either it won't load or it'll just not start.

Got an example? The only time you actually have to use a trailing . is when you reference zone-foreign data in a zone. You certainly don't need trailing dots in the config.

 

[mwarps]

Got an example? The only time you actually have to use a trailing . is when you reference zone-foreign data in a zone. You certainly don't need trailing dots in the config.

I've seen it happen with MX records.

Many types of improper data in zone file will cause a SERVFAIL, not just a trailing .

You don't need trailing dots in config, no. But missing dots in general is bad, and will mess up your day.

 

[Electrofreak]

I don't know why everyone was suggesting running away from this company screaming. I love finding an IT flustercluck I can fix (I work for an ISP too) because after all the conference calls are done and the bosses are convinced and the necessary changes finally get made, I'm the hero. I can drop it on my resume as a project I initiated and I develop a reputation in the office.

Granted, I know practically nothing about DNS. But currently I'm working on repairing an infrastructure long broken by the integration of several acquisitions which has been ignored for far too long. Thousands of nodes aren't backing up anymore and while that's fine while everything is running, when equipment fails, it's a long and exhausting process bringing it online and weeding out all the little things that got missed after the fact.

Of course, months of asking people to get things done didn't get anywhere. It ultimately took walking into a Director's office and pointing out the financial implications of the problem. As soon as there were red dollar signs next to the issue, I was given all the resources I could possibly need. This is how things get fixed, and this is how promotions are earned.

So seriously, fucked-up DNS? Sounds like a career opportunity to me. Best of luck to you Kaps!

 

[KapsZ28]

I don't know why everyone was suggesting running away from this company screaming. I love finding an IT flustercluck I can fix (I work for an ISP too) because after all the conference calls are done and the bosses are convinced and the necessary changes finally get made, I'm the hero. I can drop it on my resume as a project I initiated and I develop a reputation in the office.

Granted, I know practically nothing about DNS. But currently I'm working on repairing an infrastructure long broken by the integration of several acquisitions which has been ignored for far too long. Thousands of nodes aren't backing up anymore and while that's fine while everything is running, when equipment fails, it's a long and exhausting process bringing it online and weeding out all the little things that got missed after the fact.

Of course, months of asking people to get things done didn't get anywhere. It ultimately took walking into a Director's office and pointing out the financial implications of the problem. As soon as there were red dollar signs next to the issue, I was given all the resources I could possibly need. This is how things get fixed, and this is how promotions are earned.

So seriously, fucked-up DNS? Sounds like a career opportunity to me. Best of luck to you Kaps!

Thanks buddy! And I definitely look at it the same way. A decent sized project and it goes on the resume. Plus this project is going to be a lot more than just DNS.