깡민쓰~IT Story

Azure 프라이빗 DNS는 가상 네트워크에 안정적이고 안전한 DNS 서비스를 제공합니다. Azure Private DNS는 사용자 지정 DNS 솔루션을 구성할 필요 없이 가상 네트워크의 도메인 이름을 관리하고 확인합니다. 프라이빗 DNS 영역을 사용하면 배포 중에 Azure에서 제공한 이름 대신 고유한 사용자 지정 도메인 이름을 사용할 수 있습니다. 사용자 지정 도메인 이름을 사용하면 조직의 요구 사항에 가장 적합하도록 가상 네트워크 아키텍처를 조정할 수 있습니다. 가상 네트워크와 연결된 가상 네트워크 내에서 VM(가상 머신)에 대한 이름을 확인할 수 있게 해줍니다. 또한 분할-수평 보기를 사용해 영역을 구성할 수도 있습니다. 그러면 프라이빗 DNS 영역과 공용 DNS 영역이 이름을 공유할 수 있습니다.

가상 네트워크에서 프라이빗 DNS 영역의 레코드를 확인하려면 가상 네트워크를 해당 영역과 연결해야 합니다. 연결된 가상 네트워크는 전체 액세스 권한을 가지며 프라이빗 영역에 게시된 모든 DNS 레코드를 확인할 수 있습니다. 가상 네트워크 링크에 대한 자동 등록을 사용하도록 설정할 수도 있습니다. 가상 네트워크 연결에 대한 자동 등록을 사용하도록 설정하면 해당 가상 네트워크의 가상 머신에 대한 DNS 레코드가 프라이빗 영역에 등록됩니다. 자동 등록을 사용할 수 있게 되면 Azure DNS는 가상 머신이 생성되거나, 해당 IP 주소를 변경하거나, 삭제될 때마다 영역 레코드를 업데이트합니다.

프라이빗 DNS 영역을 만들 때 Azure는 영역 데이터를 전역 리소스로 저장합니다. 즉 프라이빗 영역은 단일 VNet 또는 지역에 종속되지 않습니다. 동일한 프라이빗 영역을 다른 지역의 여러 VNet에 연결할 수 있습니다. 하나의 VNet에서 서비스가 중단된 경우 프라이빗 영역을 계속 사용할 수 있습니다. 자세한 내용은 Azure 프라이빗 DNS 영역 복원력을 참조하세요.

Azure 프라이빗 DNS는 다음과 같은 이점을 누릴 수 있습니다.

• 사용자 지정 DNS 솔루션이 필요 없음. 이전에는 많은 고객이 가상 네트워크에서 DNS 영역을 관리하기 위해 사용자 지정 DNS 솔루션을 만들었습니다. 이제 기본 Azure 인프라를 사용하여 DNS 영역을 관리할 수 있으므로 사용자 지정 DNS 솔루션을 만들고 관리해야 하는 부담이 사라졌습니다.
• 모든 공용 DNS 레코드 형식을 사용합니다. Azure DNS는 A, AAAA, CNAME, MX, PTR, SOA, SRV 및 TXT 레코드를 지원합니다.
• 자동 호스트 레코드 관리. Azure는 사용자 지정 DNS 레코드를 호스팅할 뿐 아니라 VM의 호스트 이름 레코드를 지정된 가상 네트워크에 자동으로 보존합니다. 이 시나리오에서는 사용자 지정 DNS 솔루션을 만들거나 애플리케이션을 수정할 필요 없이 사용하는 도메인 이름을 최적화할 수 있습니다.
• 가상 네트워크 간의 호스트 이름 확인. Azure에서 제공하는 호스트 이름과는 달리, 프라이빗 DNS 영역은 가상 네트워크 간에 공유할 수 있습니다. 이 기능은 가상 네트워크 피어링 같은 교차 네트워크 및 서비스 검색 시나리오를 단순화합니다.
• 친숙한 도구 및 사용자 환경. 이 서비스는 학습 곡선을 단축할 수 있도록 잘 설정된 Azure DNS 도구(Azure Portal, Azure PowerShell, Azure CLI, Azure Resource Manager 템플릿, REST API)를 사용합니다.
• 수평 분할 DNS 지원. Azure DNS를 사용하면 이름이 같고 가상 네트워크 내 그리고 공용 인터넷의 다른 답변을 확인하는 영역을 만들 수 있습니다. 분할 수평 DNS에 대한 일반적인 시나리오는 가상 네트워크 내에서 사용할 수 있는 전용 서비스 버전을 제공하는 것입니다.
• 모든 Azure 지역에서 사용 가능. Azure DNS 프라이빗 영역 기능은 Azure 퍼블릭 클라우드의 모든 Azure 지역에서 사용할 수 있습니다.

Azure 프라이빗 DNS는 다음과 같은 기능을 제공합니다.

• 자동 등록이 사용 설정된 프라이빗 영역에 연결된 가상 네트워크에서 가상 머신 자동 등록. 가상 머신이 개인 IP 주소를 가리키는 A 레코드로 프라이빗 영역에 등록됩니다. 자동 등록이 사용 설정된 가상 네트워크 연결에서 가상 머신이 삭제되면 Azure DNS는 연결된 프라이빗 영역에서 해당 DNS 레코드도 자동으로 제거합니다.
• 프라이빗 영역에 연결된 가상 네트워크 전체에서 정방향 DNS 확인이 지원됩니다. 가상 네트워크 간 DNS 확인의 경우 가상 네트워크가 서로 연결되는 명시적 종속성은 없습니다. 그러나 다른 시나리오(예: HTTP 트래픽)를 위해 가상 네트워크를 피어링할 수도 있습니다.
• DNS 역방향 조회는 가상 네트워크 범위 내에서 지원됩니다. 프라이빗 영역에 연결된 개인 IP에 대한 역방향 DNS 조회에서는 호스트/레코드 이름과 영역 이름이 접미사로 포함된 FQDN이 반환됩니다.

Azure 프라이빗 DNS의 제한 사항은 다음과 같습니다.

• VM DNS 레코드의 자동 등록이 활성화된 경우 특정 가상 네트워크를 하나의 프라이빗 영역에만 연결할 수 있습니다. 그러나 단일 DNS 영역에 여러 가상 네트워크를 연결할 수 있습니다.
• 역방향 DNS는 연결된 가상 네트워크의 개인 IP 공간에 대해서만 작동합니다.
• 연결된 가상 네트워크의 개인 IP 주소에 대한 역방향 DNS는 가상 머신의 기본 접미사로 internal.cloudapp.net을 반환합니다. 자동 등록이 사용하도록 설정된 프라이빗 영역에 연결된 가상 네트워크의 경우 개인 IP 주소에 대한 역방향 DNS는 두 개의 FQDN을 반환합니다. 하나는 기본적으로 접미사가 internal.cloudapp.net이고 다른 하나는 프라이빗 영역 접미사가 있습니다.
• 조건부 전달은 Azure DNS Private Resolver를 사용하여 지원됩니다. Azure와 온-프레미스 네트워크 간에 확인을 사용하려면 VM 및 역할 인스턴스에 대한 이름 확인을 참조하세요.

가격 책정 정보는 Azure DNS 가격 책정을 참조하세요.

• Azure PowerShell 또는 Azure CLI를 사용하여 Azure DNS에서 프라이빗 영역을 만드는 방법을 알아봅니다.
• Azure DNS에서 프라이빗 영역으로 실현할 수 있는 몇 가지 일반 프라이빗 영역 시나리오에 대해 읽어보세요.
• Azure DNS의 프라이빗 영역에 대한 일반적인 질문과 답변은 프라이빗 DNS FAQ를 참조하세요.
• DNS 영역 및 레코드 개요를 참조하여 DNS 영역 및 레코드에 대해 알아봅니다.
• Azure의 몇 가지 다른 주요 네트워킹 기능을 알아봅니다.
• 학습 모듈: Azure DNS 소개

Azure DNS Private Resolver는 VM 기반 DNS 서버를 배포하지 않고 온-프레미스 환경에서 Azure DNS 프라이빗 영역을 쿼리하거나 그 반대로 쿼리할 수 있는 새로운 서비스입니다.

Azure DNS Private Resolver에는 Azure Virtual Network가 필요합니다. 가상 네트워크 내에서 Azure DNS Private Resolver를 만들면 DNS 쿼리의 대상으로 사용할 수 있는 하나 이상의 인바운드 엔드포인트가 설정됩니다. 확인자의 아웃바운드 엔드포인트는 구성하는 DNS 전달 규칙 집합을 기반으로 하여 DNS 쿼리를 처리합니다. 규칙 집합에 연결된 네트워크에서 시작된 DNS 쿼리는 다른 DNS 서버에 보낼 수 있습니다.

Azure DNS Private Resolver를 사용하기 위해 VM(가상 머신)의 DNS 클라이언트 설정을 변경할 필요가 없습니다.

Azure DNS Private Resolver를 사용할 때의 DNS 쿼리 프로세스는 다음과 같이 요약됩니다.

1. 가상 네트워크의 클라이언트에서 DNS 쿼리를 실행합니다.
2. 이 가상 네트워크에 대한 DNS 서버가 사용자 지정되면 쿼리를 지정된 IP 주소로 전달합니다.
3. 기본(Azure 제공) DNS 서버가 가상 네트워크에 구성되어 있고 동일한 가상 네트워크에 연결된 프라이빗 DNS 영역이 있는 경우 이러한 영역을 참조합니다.
4. 쿼리가 가상 네트워크에 연결된 프라이빗 DNS 영역과 일치하지 않는 경우 DNS 전달 규칙 집합에 대한 가상 네트워크 링크를 참조합니다.
5. 규칙 집합 링크가 없는 경우 Azure DNS를 사용하여 쿼리를 확인합니다.
6. 규칙 집합 링크가 있는 경우 DNS 전달 규칙을 평가합니다.
7. 접미사가 일치하는 경우 쿼리를 지정된 주소로 전달합니다.
8. 여러 항목이 일치하는 경우 가장 긴 접미사를 사용합니다.
9. 일치하는 항목이 없는 경우 DNS 전달을 수행하지 않고 Azure DNS를 사용하여 쿼리를 확인합니다.

Azure DNS Private Resolver 아키텍처는 다음 그림에 요약되어 있습니다. Azure 가상 네트워크와 온-프레미스 네트워크 간의 DNS 확인에는 Azure ExpressRoute 또는 VPN이 필요합니다.

그림 1: Azure DNS Private Resolver 아키텍처

프라이빗 DNS 확인자를 만드는 방법에 대한 자세한 내용은 다음을 참조하세요.

• 빠른 시작: Azure Portal을 사용하여 Azure DNS Private Resolver 만들기
• 빠른 시작: Azure PowerShell을 사용하여 Azure DNS Private Resolver 만들기

Azure DNS Private Resolver에서 제공하는 이점은 다음과 같습니다.

• 완전 관리형: 기본 제공 고가용성, 영역 중복성
• 비용 절감: 운영 비용을 절감하고, 기존 IaaS 솔루션 가격의 일부로 실행합니다.
• 프라이빗 DNS 영역에 대한 프라이빗 액세스: 온-프레미스에서 조건부로 전달합니다.
• 확장성: 엔드포인트별 고성능
• DevOps 친숙한 기능: Terraform, ARM 또는 Bicep을 사용하여 파이프라인을 빌드합니다.

지역별 Azure 제품 - Azure DNS를 참조하세요.

Azure DNS Private Resolver는 확인자를 배포한 지역에서 고객 데이터를 이동하거나 저장하지 않습니다.

이 문서에서는 해결 프로그램 엔드포인트 및 규칙 집합에 대한 요약을 제공합니다. 엔드포인트 및 규칙 집합에 대한 자세한 내용은 Azure DNS Private Resolver 엔드포인트 및 규칙 집합을 참조하세요.

인바운드 엔드포인트를 사용하면 프라이빗 가상 네트워크 주소 공간의 일부인 IP 주소를 통해 온-프레미스 또는 다른 프라이빗 위치에서 이름을 확인할 수 있습니다. 온-프레미스에서 Azure 프라이빗 DNS 영역을 확인하려면 인바운드 엔드포인트의 IP 주소를 온-프레미스 DNS 조건부 전달자에 입력합니다. 온-프레미스 DNS 조건부 전달자는 가상 네트워크에 대한 네트워크 연결이 있어야 합니다.

인바운드 엔드포인트에는 프로비저닝된 VNet의 서브넷이 필요합니다. 서브넷은 Microsoft.Network/dnsResolvers에만 위임할 수 있으며 다른 서비스에는 사용할 수 없습니다. 인바운드 엔드포인트에서 받은 DNS 쿼리는 Azure로 들어갑니다. 자동 등록 또는 Private Link 사용 서비스를 사용하는 VM을 포함하여 프라이빗 DNS 영역이 있는 시나리오에서 이름을 확인할 수 있습니다.

아웃바운드 엔드포인트를 사용하면 이름 확인을 조건부로 Azure에서 온-프레미스, 다른 클라우드 공급자 또는 외부 DNS 서버로 전달할 수 있습니다. 이 엔드포인트에는 해당 서브넷에서 실행되는 다른 서비스가 없고 Microsoft.Network/dnsResolvers에만 위임할 수 있는 프로비전된 VNet의 전용 서브넷이 필요합니다. 아웃바운드 엔드포인트에 보낸 DNS 쿼리는 Azure에서 나갑니다.

가상 네트워크 링크는 DNS 전달 규칙 집합을 사용하여 아웃바운드 엔드포인트에 연결된 가상 네트워크에 대한 이름 확인을 사용하도록 설정합니다. 1:1 관계입니다.

DNS 전달 규칙 집합은 하나 이상의 아웃바운드 엔드포인트에 적용하거나 하나 이상의 가상 네트워크에 연결할 수 있는 DNS 전달 규칙(최대 1000개) 그룹입니다. 1:N 관계입니다. 규칙 집합은 특정 아웃바운드 엔드포인트와 연결됩니다. 자세한 내용은 DNS 전달 규칙 집합을 참조하세요.

DNS 전달 규칙에는 조건부 전달에 사용할 하나 이상의 대상 DNS 서버가 포함되며 다음으로 표시됩니다.

• 도메인 이름
• 대상 IP 주소
• 대상 포트 및 프로토콜(UDP 또는 TCP)

현재 Azure DNS Private Resolver에 적용되는 제한은 다음과 같습니다.

DNS 프라이빗 확인자1

1 포털이 업데이트될 때까지 Azure Portal에서 다른 한도가 적용될 수 있습니다. PowerShell을 사용하여 가장 최근 한도까지 요소를 프로비전합니다.

가상 네트워크와 관련된 제한 사항은 다음과 같습니다.

• 암호화가 사용하도록 설정된 VNet은 Azure DNS Private Resolver를 지원하지 않습니다.
• DNS 확인자는 DNS 확인자와 동일한 지역의 가상 네트워크만 참조할 수 있습니다.
• 가상 네트워크는 여러 DNS 확인자 간에 공유할 수 없습니다. 단일 가상 네트워크는 단일 DNS 확인자에서만 참조할 수 있습니다.

DNS 확인자에 사용되는 서브넷에 대한 제한 사항은 다음과 같습니다.

• 서브넷은 최소 /28 주소 공간 또는 최대 /24 주소 공간이어야 합니다. /28 서브넷은 현재 엔드포인트 한도를 수용하기에 충분합니다. /27에서 /24까지의 서브넷 크기는 이러한 한도가 변경되는 경우 유연성을 제공할 수 있습니다.
• 서브넷은 여러 DNS 확인자 엔드포인트 간에 공유할 수 없습니다. 단일 서브넷은 단일 DNS 확인자 엔드포인트에서만 사용할 수 있습니다.
• DNS 확인자 인바운드 엔드포인트에 대한 모든 IP 구성은 동일한 서브넷을 참조해야 합니다. 단일 DNS 확인자 인바운드 엔드포인트에 대한 IP 구성은 여러 서브넷을 포함할 수 없습니다.
• DNS 확인자 인바운드 엔드포인트에 사용되는 서브넷은 부모 DNS 확인자에서 참조하는 가상 네트워크 내에 있어야 합니다.
• 서브넷은 Microsoft.Network/dnsResolvers에만 위임할 수 있으며 다른 서비스에는 사용할 수 없습니다.

아웃바운드 엔드포인트에 대한 제한 사항은 다음과 같습니다.

• DNS 전달 규칙 집합과 그 아래의 가상 네트워크 링크가 삭제되지 않으면 아웃바운드 엔드포인트를 삭제할 수 없습니다.

• 규칙 집합은 최대 1000개의 규칙을 가질 수 있습니다.
• 규칙 집합의 교차 테넌트 연결은 지원되지 않습니다.

• IPv6 사용 서브넷은 지원되지 않습니다.
• DNS Private Resolver는 Azure ExpressRoute FastPath를 지원하지 않습니다.
• DNS Private Resolver는 Azure Lighthouse와 호환되지 않습니다.
  • Azure Lighthouse가 사용 중인지 확인하려면 Azure Portal에서 서비스 공급자를 검색하고 서비스 공급자 제품을 선택합니다.

• Azure PowerShell 또는 Azure Portal을 사용하여 Azure DNS Private Resolver를 만드는 방법을 알아봅니다.
• Azure DNS Private Resolver를 사용하여 Azure 및 온-프레미스 도메인을 확인하는 방법을 이해합니다.
• Azure DNS Private Resolver 엔드포인트 및 규칙 집합에 대해 알아봅니다.
• 프라이빗 해결 프로그램을 사용하여 DNS 장애 조치(failover) 설정 방법 알아보기
• 프라이빗 해결 프로그램을 사용하여 하이브리드 DNS를 구성하는 방법을 알아봅니다.
• Azure의 몇 가지 다른 주요 네트워킹 기능을 알아봅니다.
• 학습 모듈: Azure DNS 소개

So you’ve got some DNS Zones on your Domain Controllers and you’re building a test lab or another domain that you want to copy these to. Easy right – not so easy if they are AD integrated zones. This means the files for these zones are not stored in C:\Windows\System32\dns an normal, they are actually stored and replicated to all DCs inside AD.

I had a requirement to move an integrated forward lookup zone from one domain to another so I’m sharing what I did below.

Logon to your DC with the integrated zone and fireup our friend Powershell.

Get-DNSServerZone

You’ll see your zones listed out.

You’ll see here which zones are integrated and which are not.

The ZoneName column is key for the next bit, make a note of the ZoneName you want to export.

Export-DNSServerZone -Name <ZoneName from the above> -Filename <Yourzone.dns>

There’s no confirmation for this command, but this will export the zone to a file that can be resuable.

Open up C:\Windows\System32\dns in explorer.

You’ll see here you DNS zone file. Take a copy of this and place it somewhere.

Log in to your new DNS server where the zone will be imported.

Open up C:\Windows\System32\dns in explorer and copy the file you just exported into this folder.

Now open the DNZ Management Console.

Right click “Forward Lookup Zones” and select “New Zone”, Select “Next” to get started.

Select the zone type and remember to untick the “Store the zone in Active Directory” option.

I know, I know, we want it to be in AD; don’t worry. It will still be once we are done.

Select “Next”.

Populate the Zone Name and select “Next”.

Select “Use the existing file” and enter the name of the file you copied into “C:\Windows\System32\dns”, select “Next”.

Select “Next” on the dynamic update options. Note: The secure option will be available once we convert this zone to an AD integrated zone.

The zone should now appear fully populated in the DNS console. Now time to convert this zone back to an AD integrated zone.

Right click the zone and select “Properties”.

Select “Change” on the right of “Type”.

You might recognise this screen, Select “Store the zone in Active Directory” and click “OK”. Confirm you want to move the zone to AD.

You now have the option to change the dynamic updates to this zone, select as per your preference.

This wraps up the zone import, the whole process could be easily scripted with Powershell. Happy to take a crack at it if anyone is interested.

Now that I have outlined the building blocks of a Lync infrastructure, there are three more topics to understand if we want to have a working infrastructure:

• Firewall rules required to allow communications for Lync clients, Lync servers and for the aforementioned non-Lync servers with additional services we need
• DNS settings to make Lync services available both on the internal network and from the Internet
• Structure of the certificates. Lync is secure by design and digital certificates are mandatory for every Lync 2013 infrastructure

Firewall Rules Required for Lync Server 2013

A deep dive about firewall rules for Lync Server 2013 should include TechNet article Port Requirements http://technet.microsoft.com/en-us/library/gg398798.aspx and the Lync 2013 Protocol Workloads poster http://www.microsoft.com/en-us/download/details.aspx?id=39968 (i.e. to check the requirements for the different scenarios). However to make the topic easier to understand, I have tried to create an explanation based on some assumption.

• The first assumption I will make here is that your network has a segregated DMZ to make services available to the Internet in a secure manner. A couple of the possible solutions for such a deployment are
• Using two firewalls. Note: usually the technology used for the firewalls is not important. However if a SIP trunk is required in our scenario, it is important to have a SIP Application-level gateway (ALG).
• A three-legged firewall that will create a logical demilitarized zone

There is no difference in the result, from the functionality point of view, going for the first option or the second one. A single firewall would imply a single point of failure and higher security risk, because a single Internet-connected device will be exposed both on the DMZ and on the internal network. Having two different firewalls, a front (FW2) and a back firewall (FW1), as shown in figure 6.7, is more secure, especially if we are going to use two different platforms or solutions for security. In the aforementioned scenario, an exploitable security vulnerability on a single technology will not affect the second firewall

A layout including only firewalls and networks that will have an impact on our Lync deployment

Figure 6.7 layout including only firewalls and networks that will have an impact on our Lync deployment

• The second assumption will be that we will not deploy High Availability or load balancing systems (including Enterprise Edition pools of Lync Front Ends). Although you may require them in a real-world design, they add a configuration overhead that will not help understanding the fundamentals of Lync Server 2013 network traffic requirements
• The third assumption is that we will use NAT every time that a public IP is required. Exposing directly a server to the Internet usually is not the best security solution available
• Fourth assumption is that the Edge Server will use three addresses on the “external” network interface card to expose services to the Internet. The addresses are the ones we have already seen:

Edge_IPs

• Last assumption: no integration or connection with Office Communications Server 2007 deployments or clients is required

We will have to grant the following types of network traffic:

6.1 From servers in the DMZ to servers in the internal network

6.2 From servers in the DMZ to the external network

6.3 From the external network to servers in the DMZ

6.4 From servers in internal network to servers in DMZ

6.5 Network traffic related to Lync clients in the internal network

Note: the point 6.5 of the list is interesting only if you have firewalls (or end-point firewalls) separating the networks containing the Lync clients and the Lync servers.

6.1 Network Traffic from servers in The DMZ to Servers in the Internal Network

On the Back-End firewall, FW1,for traffic starting from the reverse proxy, the following ports will be required

On the Back-End firewall, FW1, for traffic starting from the Edge Server, the following ports will be required

6.2 Network Traffic from Servers in the DMZ to the External Network

On the Front firewall, FW2, from the Edge Server, the following ports will be required. It is helpful to remind you the fourth assumption: we have three different IPs on the external network interface of the Lync Edge Server: Access, Webconf and AV. The firewall rules for network traffic from the external network to the Edge will have to point to one of the three IPs, as explained in the following table.

6.3 Network Traffic from the External Network to Servers in the DMZ

On the Front firewall, FW2, traffic from the external network to the reverse proxy, the following ports will be required

On the Front-End firewall, FW2, traffic from the external network to the Edge Server, the following ports will be required

6.4 Network Traffic from Servers in the Internal Network to Servers in the DMZ

On the Back-End firewall, FW1, for traffic starting from the internal network, the following ports will be required

6.5 Network Traffic Related to Lync Clients in the Internal Network

The following rules are required on any end-point firewall and on any internal firewall that controls traffic coming from the Lync clients on the internal network.

Notes Related to the Firewall Rules Required for Lync Server 2013

Lync Server 2013 Edge Server requires DNS resolution and http access to revocation lists of certificates. Depending from your network design, the aforementioned services could be on the Internet or could be available using services on the internal network (like a proxy). The following rule is to be adapted to your network layout

Centralized Logging Service (a new feature in Lync Server 2013) requires additional ports on the back-end firewall (for more details see the TechNet article Using the Centralized Logging Service http://technet.microsoft.com/en-us/library/jj688101.aspx

Disclaimer: please consider the answer as an approximation that could miss some detail. I will try to make a more complete answer in a future post.

Ports required in Lync 2013 (must be reachable from your administrative workstation):
— Ports LDAP (TCP 389) and msft-gc (TCP 3268) on a global catalog/domain controller are always required

-For the Lync Server Control Panel (process is AdminUIHost.exe): HTTPS and TCP 49336 on the Lync server you are going to manage

-For the Lync Server Management Shell (process is powershell.exe): TCP 49336 on the Lync server you are going to manage

-For the Topology Builder to download Lync topology (process is Microsoft.Rtc.Management.TopologyBuilder.exe): TCP 49336 on the Lync server hosting the CMS database

-For the Topology Builder to publish Lync topology (process is Microsoft.Rtc.Management.TopologyBuilder.exe): in addition to the aforementioned ports, Microsoft Directory Services TCP/UDP 445 to a Domain Controller and to the Lync server hosting the CMS database

https://www.absoluteuc.org/part-2-draft-chapter-6-dns-certificate-firewall-requirements-lync-server-2013

http://www.cusoon.fr/sbc-and-sba-guide-ports/