Answer the question
In order to leave comments, you need to log in
How to organize DNS correctly?
Good afternoon!
There is a small company COMPANYNAME, which has a website COMPANYNAME.ru. The site is spinning on one of the well-known hosts. There are few computers on the network, they worked in the same working group, the links are registered by IP addresses, DNS is configured for all 8.8.8.8. Created an internal domain COMPANYNAME.ru. Accordingly, the domain controller became the DNS server. We register it as the main DNS server on all computers. When you try to go to an Internet site, we get to the same server. If we write 8.8.8.8 as the first DNS server, and the internal DNS server as the second, then problems will begin with the domain.
Tell me how to organize the DNS structure more correctly?
Answer the question
In order to leave comments, you need to log in
On a vskidku are "sticking out" addresses of computers in the Internet.
It's better to make .loc
if the certificate is needed locally - then distribute it through the Microsoft active directory certification authority. All internal clients will trust him. Letting outside customers in is bad. a self-signed certificate (including CA) will not be trusted by external clients, and one signed by a trusted root certification authority costs money, however. each such certificate. And it costs so much to sign a root certificate... that it's better not to.
So inside - there will still be a self-signed root. and in this case - does it matter what the domain is called? at least .loc, at least local - and the name will not play a role - EVERYTHING can be signed with this CA. and dns-name will be null there.
I faced it myself. I have been cutting out the old domain for a year, changing it to .loc. and I won't be able to finish it.
PS. also, there are things like "internal browsing" and "external browsing" - the same dns-names will give different names when resolving, depending on the address of the requester. so it is quite possible to put a mail server inside and call it mail.companyname.ru, providing access to both local network clients and "external" employees. This can also be useful when planning a domain, because I can't imagine a situation where you would need to use an actual registered domain as the domain name.
ZY2. I recommend to read: once and twice
It is not entirely clear how your computer dc1.COMPANYNAME.ru turned into www.COMPANYNAME.ru
When there are multiple domain controllers, then a random controller replies when pinging the DOMAIN NAME. If he is alone in the domain, then he responds.
This is a common problem when the AD domain name is the same as the site name. The easiest way out, as already correctly noted, is to use www within the company. Or do policy based routing, if the infrastructure allows.
Thanks everyone. I read a bunch of information on crutches invented by the people, but I did not find a beautiful solution to the problem. Decided to lose a few hours of work, crashed the COMPANYNAME.ru domain and created office.COMPANYNAME.ru. While everything has not gone far, I decided to do it right right away, so that after years various incorrigible problems would not come out.
I would rename the internal domain to COMPANYNAME.lan and everything would fall into place. The site is separate, the office is separate. Why do you need it, to expose your office domain controller to the public, or should it serve as a dns server for the site?
Crutch - install a proxy server on port 80 on the domain controller.
And where did the habravchans recommend you a proxy in this thread? In addition, you have the wrong idea of what a crutch is and what a typical solution is. In essence, few people at all care about how you implement something in the office. Everything should work. And dns is not the area in which the cant can be deadly. Let's take a look at your crutch. The client has 0_o registered (have you heard about the dynamics?) by the second dns server google public. That is, you are worried that you will not be able to ensure the smooth operation of the domain controller and fence a crutch. But according to Feng Shui there should be two controllers! Sorry, of course .. you here slightly lowered people with their advice and at the same time you yourself are making crutches.
Пара комментариев. Типовое решение - это не всегда правильное решение. Правильное решение, это когда админ забыл о способе решения или пришел другой админ и в случае любых проблем, корень ее находится за несколько минут. В некоторых организациях видел костыли, которые до поры до времени работают, но про которые все забыли или не знают. Потом поиск проблемы и ее устранение займут лишние часы.
По фен-шую серверов должно быть 2. Сейчас его нет, т.к. не предусматривали выделение финансов на него в этом году. На второй деньги заложены в бюджете следующего года. Надеюсь, существующий проживет несколько месяцев до получения второго. Придет второй сервер - добавлю одну строчку в настройках DHCP и все будет работать нормально. Где вы проблему увидели?
Вы писали
The job of a system administrator is to do something like that. And your wording makes a tragedy out of it. If the record is not needed, then it is stupidly demolished. They start a new one. And everything is back on track. And this is not a "failure" as you write. The decision with www just also is commonly used.
There are not so many servers, you never know, I want to post a telephone directory updated from AD or other crap on the ceb page.
Such a site can be given the name office.companyname.ru.
The proxy by the field "Host:" will turn to the internal web server, which can be hung up on a neighboring port.
It's easier than renaming a domain.
I am now planning to raise a gateway on a freight that will prioritize the use of traffic to different network segments. Packets going through the proxy will look the same to the gateway. And to fence several proxies for each segment is another crutch. This is how systems are obtained, when it is lazy to cross out the work of several hours once and do it right, incredible constructions of crutches begin to fence. All the same, someday it must be destroyed or it will crumble itself over time. I decided to do it right.
God. Well, you are my friend and a bore. They asked for help in an issue that they did not understand, and then they also began to teach. I know as well as you about this topic. All that was required of you .. is to close the topic after the solution is found and not get bored.
Why does the discussion of technical issues very often turn into rudeness? And there is also the "smartest boss" who decides who should do what. I asked the question: "how to MOST CORRECTLY solve this issue", and not "what crutches can be heaped up so that they leave me behind today." I myself offhand came up with about 5 solutions from the category of "crutches". I just wanted to know the opinion of a knowledgeable and more experienced specialist, and not a tyap-lyapkin solution that works with reservations or within certain limits. Some of the proposed solutions I do not consider crutches, but they did not fit into my plans to expand the network structure. But it is still very interesting to read the recommendations of colleagues.
Still, it is correct not to mix the external and internal domain.
You have a zone COMPANYNAME.ru, and you create another zone COMPANYNAME.ru
Naturally, there will be problems.
this means that you need to create either COMPANYNAME.loc (COMPANYNAME.local) or office.COMPANYNAME.ru (which will also not be a very correct solution)
Or try to write an SRV record for _http._tcp
example here help.dnsmadeeasy.com/record-entry /srv-2/
It is not certain that browsers will check this entry. didn't test.
Well, either still drive a crutch like "redirect requests to port 80 of the domain controller to an external site." But it will still be a crutch.
I have little idea how various software processes this entry, but thanks for the idea. I didn't even think about that. COMPANYNAME.loc decided not to do it, you never know what will happen in the future? We want to make a certificate in the future, but, as far as I remember, it is not done for left domains. I decided to do it from the "recommended" range of names, and settled on the office.COMPANYNAME.ru method. And what pitfalls can come out in this case? Offhand, I haven’t come up with any problems yet, but maybe it’s worth redoing something else, until the computers are driven into the domain?
They do not "stick out" on the Internet. Gateway behind the PPPoE tunnel to the provider, the range of received addresses is dynamic. The computers themselves are behind NAT on the fryah, access lists and all that. If you do not raise the VPN to the computer using the allowed ports, then you cannot get into the network from the outside.
I am not talking about self-signed certificates, they are not a problem to generate at all. I'm talking about official ones issued by a trusted center. They are expensive, but branded server equipment, cisco network equipment, licensed software - everything is expensive.
You yourself say that you have been removing the crutch for a year and cannot remove it. I immediately want to make it beautiful, so that in the future, with any extensions, I won’t have problems.
In the future, I plan to expand the channel, leave the provider, move the DMZ zone with the mailer, file server, web server, etc. to the COMPANYNAME.ru root domain, and the computers behind the firewall will be in office.COMPANYNAME.ru. IMHO it's ok. Or are there other pitfalls?
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question