Split brain dns что это

What is Split-Brain DNS?

When building a lab or any services, you’re going to need DNS in most cases, however, we don’t necessarily want to expose the DNS records to the world, this is where resources like Split-Brain DNS servers come into play.

Split-Brain DNS??

Split-Brain DNS is effectively like having two DNS servers running on the same origin, they each have a set of records, and will reply different values depending on how they’re being requested. It seems complex, but it’s very easy to use.

Let’s say I’m connecting from my bedroom PC to my home wifi, and I want to ping my Nextcloud instance, I run “ping cloud.thegeekbin.com” and it returns “10.24.40.2” – perfect, I can access that and easily use it. Now, if I switched over to LTE network and ran the same command, I get a resolution error: “ping: cannot resolve cloud.thegeekbin.com: Unknown host”

We’re getting this DNS resolution error because our Split-Brain DNS sees the requesting IP address is outside the LAN scope, and returns an altered set of results. Let’s say your Jira instance was internally 10.24.42.2, and externally you used your public IPv4 address – when you queried externally, you’d get your public (eg. 123.123.123.123), but when looking from internal, you get the direct IP of the instance, which is 10.24.42.2, allowing you to skip going outside your network, and remaining entirely local.

Why do I want Split-Brain DNS?

In most cases, it’s for security and privacy, you obviously don’t want to expose to the world the topology of your entire network, right? By using split-brain you can expose just the public network to the public, and the whole private to the internal LAN, allowing you keep your topology private.

How do I set it up?

Setting up is easy, for this example I’m going to assume you’re running on Ubuntu or Debian for your DNS server, however, this should also work for CentOS/RHEL.

First, you’re going to want to install bind9 if you haven’t already, you can do this by running:

Now that we’ve got our basic DNS server installed, we’ll want to head over to /etc/bind/named.conf.options and make sure our configuration for listening on port 53 and the IP address is set, below is an example of the configuration file (tweak as necessary):

Now we’ve got our basic setup ready, but we’re not done yet! We can now create access controls and views. Views are how the split-brain defines the resolution rules, for example, let’s create an ACL for our public network on 10.0.0.0/24, and a simple zone for “test.thegeekbin.com”:

Now, we can define our rules inside the zone file for our lan, next we’ll want an outside view, which the public network will see, this will be considered the untrusted segment of the network, for this, we’ll create another view that matches on any clients like so:

Now, when we save and restart bind, throw some entries in each configuration zone file, and query from internal and external, you’ll see the bind server is responding with different entries based on the requesting IP address.

That’s all for this tutorial, leave me a comment below if you have any questions, I’d love to help out!

What are Split-Brain, Split-Horizon are Split-DNS

By Paul Burch February 25, 2022 February 25, 2022

Split-Brain DNS, Split-Horizon DNS, or Split DNS are terms used to describe when two zones for the same domain are created, one to be used by the internal network, the other used by the external network (usually the Internet). I prefer the term “Split DNS” so we will just continue with that one.

A Split DNS infrastructure is used to direct internal hosts to an internal domain name server for name resolution and external hosts to an external domain name server for name resolution. This type of DNS configuration is very common in networks that have established an internal Active Directory domain name which is the same as the public external domain name. Let’s begin by taking a look at an example where Split DNS is not used.

This diagram depicts a network design with only one DNS infrastructure which is being hosted on the internal network to service both internal and external requests. While this design will work technically, it may not be appropriate for the business due to security and other concerns. Here are some issues and concerns that may need to be addressed by implementing a Split DNS design.

• The internal DNS zone is exposed to Internet users. An Internet user can resolve ALL internal host names.
• One or more internal servers are exposed to the Internet. This can lead to exposing data due to security vulnerabilities in other services running on the servers.
• If the organization has an Internet and intranet web site, name resolution for the web site using one host name is extremely complex without additional components. For instance, the URL, http://corp.net, would point to the same resource even though there would be an intranet and Internet web site established.

This second example (Split DNS) depicts two sets of DNS systems. One pair of DNS servers are located on the intranet, while another pair of DNS servers are located on the DMZ servicing the Internet. In a Split DNS design, these two sets of DNS groups do not replicate the corp.net zone between them.

Each set of DNS servers holds a PRIMARY/SECONDARY zone for corp.net. This design mitigates each of the concerns listed above. However, it does introduce a problem for intranet users, related to name resolution. What if the Internet DNS zone has a hostname called FTP.CORP.NET and an intranet user needs to get to that resource from within the network?

Well, if this hostname is only published in the Internet zone, the intranet user will not be able to resolve the hostname. This is because the intranet DNS servers do not have this record in their zone. The intranet DNS servers will not attempt to resolve this hostname using root hints, forwarders, or any other DNS servers on the Internet, even though the answer to the query can be resolved by the Internet DNS servers located in the DMZ.

The reason is that the intranet DNS servers host an AUTHORITATIVE zone for corp.net. From their perspective, if they do not have the record, there is no reason to go anywhere else looking for an answer, since the intranet DNS servers “own” the zone. So how can this be resolved? Simply create a record on the intranet DNS servers for the hostname “FTP” in the corp.net zone, and point that record to the Internet resource.

Now that the same record is hosted in both sets of DNS infrastructures, intranet and Internet users will be able to access the same resource using the same hostname. Keep in mind that if the IP of the FTP record ever changes, it will need to be updated on the Internet and intranet DNS servers independently.

Лучшие практики: разделенная DNS (Split DNS) в инфраструктуре 3CX Phone System

1. Зайдите в свою учетную запись
2. Перейдите в Control Panel >Zone Profiles
   
3. Нажмите Add Zone Profile
4. Нажмите Rename Zone Profile и присвойте профилю имя. В этом примере мы использовали example.com. Нажмите Rename, чтобы сохранить имя профиля
5. Нажмите Add DNS Record и в меню выберите A (IPv4 Address)
   
6. В поле Host укажите желаемое имя сервера. В нашем примере это pbx
7. В поле IP Address V4 укажите публичный IP адрес вашего сервера 3CX Phone System
8. Поле TTL оставьте по умолчанию 3600
9. Для сохранения настроек нажмите ✓. A-запись (ваше FQDN имя сервера) pbx.example.com будет создана. Через некоторое время, которое может занять до 24 часов, ваше публичное FQDN имя сервера будет преобразовываться в публичный IP адрес.

Частное FQDN имя сервера

Покажем, как настроить частное FQDN имя на DNS сервере, расположенном во внутренней сети вашей компании. Пример основан на DNS сервере Windows 2012 R2 и предполагает, что сервер настраивается с нуля.

Включение роли DNS

1. Запустите Server Manager
2. В правом верхнем углу окна Server Manager нажмите Manage и из выпадающего меню выберите Add Roles and Features
3. В окне мастера Add Roles and Features Wizard нажмите Next
4. Оставьте опцию по умолчанию Role-based or feature-based installation и нажмите Next
5. Выберите сервер, которому нужно назначить новую роль и нажмите Next
6. В списке выберите DNS Server. В появившемся диалоговом окне оставьте значения по умолчанию, нажмите Add Features и Next
7. На странице Features нажмите Next
8. На странице DNS Server нажмите Next
9. Нажмите Install
10. По окончании установки нажмите Close

Добавление новой зоны

1. В правом верхнем углу оснастки выберите Tools и в выпадающем меню DNS
2. Откроется DNS manager. Кликните правой кнопкой мыши по имени сервера и выберите New Zone…
3. В мастере New Zone Wizard нажмите Next
4. Оставьте Primary zone по умолчанию и нажмите Next
5. Выберите Forward lookup zone и нажмите Next
   
6. Укажите имя зоны, в нашем примере, example.com, и нажмите Next
7. На странице Zone File оставьте параметры по умолчанию и нажмите Next
8. На странице Dynamic Update оставьте параметры по умолчанию, нажмите Next и Finish

Добавление нового хоста

Вновь созданная зона появится в разделе Forward Lookup Zones:

1. Кликните правой кнопкой мыши по созданной зоне и выберите New Host (A or AAAA)…
2. Укажите имя хоста, в нашем примере, pbx
3. Укажите частный (локальный) IP адрес сервера 3CX Phone System
4. Нажмите Add Host. Появится сообщение о том, что запись pbx.example.com создана. Нажмите OK и Done

Чтобы протестировать корректность настройки частного FQDN имени, в командной строке введите nslookup pbx.example.com. Команду нужно выполнять на компьютере, находящемся во внутренней сети. В ответ вы должны получить внутренний IP адрес сервера.
Split DNS создана. С этого момента 3CX Phone System будет использовать единое FQDN имя в публичной и частной сети.

Возможные проблемы

В зависимости от используемого типа DNS сервера, вы можете столкнуться с тем, что другие ваши хосты, например, веб сервер www.example.com, станут недоступны из внутренней сети. Это связано с тем, что ваш локальный DNS сервер начнет использовать внутреннюю DNS зону, а не перенаправлять запросы локальных клиентов на внешний DNS сервер. В этом случае необходимо продублировать во внутренней DNS зоне A записи всех хостов, находящихся во внешней DNS зоне. A запись должна содержать доменное имя хоста и его публичный IP адрес.

I’ve heard the term split brain DNS; what does it mean?

Most companies these days have a public Internet domain name, such as www.Microsoft.com. When companies begin implementing Active Directory (AD), which requires a DNS name for the domain name, they have to make a decision: use a private domain name (such as Microsoft.pri) for the AD domain, or keep using the public name (Microsoft.com) for both AD and public use.

The benefit of using a private domain name is that your domain is safer from harm. You have two domains, a public one and a private one. The downside is that users might think it’s weird. For example, in AD, users can log on using their fully qualified user name; don@braincore.net, for example. That’s easy for users because it looks like their email address. However, if you select a private domain name, users will receive email at don@braincore.net, but they’ll log on with don@braincore.pri, which is confusing.

So-called split brain DNS offers an elegant solution that combines the benefits of a private domain name with the benefits of a public domain name—with almost none of the downsides of either.

Splitting the Brain

Figure 23.1 shows how split DNS can be configured so that both your internal and public domains use the same domain name, company.com.

Figure 23.1: An example split DNS configuration.

In this example, you have two DNS servers: one on your internal network, and one that’s accessible to the public (you’d likely have at least two in each location, but that’s not relevant to the basic configuration). Both DNS servers believe they’re authoritative for your domain, meaning that they are the final source for all records related to the domain.

How it Works

Your public domain record lists your public DNS server(s), meaning that the top-level domain (TLD) domain name servers will also list your public DNS server(s). When Internet users attempt to look up any host in your domain, such as www.company.com, they’ll use your public DNS server. That server is configured with static records, including any Web servers, mail servers, and other publicly accessible servers.

Internally, your client computers are configured to use your internal DNS server. It might have dynamic DNS configured and believe it is authoritative for company.com. It might also be configured to forward requests to your ISP’s DNS server so that your client computers can access Internet Web servers. Hence, the trick—because your Web server isn’t connected to your internal DNS server, it won’t be able to dynamically register its name. Thus, your internal DNS server won’t contain a record for, say, www.company.com.

No problem, right? Isn’t that what forwarding solves? Wrong. Because your internal DNS server is authoritative for company.com, it will never forward requests for anything involving company.com. «If I don’t have it, nobody else will» is your DNS server’s motto in this case. So you will need to create static records for all publicly accessible servers in the company.com domain. Doing so will permit internal users to access these external assets.

Split-Brain Pitfalls

Split-brain DNS only has a couple of minor drawbacks. Primarily, you’ll need to manually keep both DNS servers up to date with your publicly accessible resources. Technically, the public DNS server could use dynamic DNS, but the security implications of doing so aren’t worth the convenience.

You can’t perform zone transfers between the servers because they’re both hosting a primary zone for company.com, and they can only transfer to another secondary zone of the same name. You wouldn’t necessarily configure them as forwarders to one another, either; remember, authoritative servers never forward requests for their own domains.

Same-Site Split-Brain

In the previous example, the external resources were hosted on a different network. So what if you host your own Web servers? The picture looks remarkably similar, as Figure 23.2 shows.

Figure 23.3: Split DNS in a single location.

In this example, a DMZ or perimeter network contains the publicly accessible resources, including the Web server and the public DNS server. The internal LAN contains the internal resources. Close physical proximity or network connectivity doesn’t matter for split DNS; the two DNS servers never talk to one another, and each is unaware that the other even exists.