...
It is very important that network administrators understand DNS. Wikipedia has a great reference to help get more comfortable with DNS. Even if you think you know everything about it, a refresher is always good.
There is a standalone xecsuser:document on setting up Microsoft DNS Services for use with sipXecs
...
A typical DNS zone file looks as follows:
| Code Block |
|---|
; WARNING: Zone file configuration is a sipX automatically generated file. ; ; Contents may be overwritten unless you set the named.conf DNS_MODE. ; $TTL 1800 @ IN SOA @ IN SOA ns1.ezuce.com. root.ezuce.com. ( 2010090201 ; serial# 1800 ; refresh, seconds 1800 ; retry, seconds 1800 ; expire, seconds 1800 ) ; minimum TTL, seconds \\ 1800 ; refresh, seconds 1800 ; retry, seconds 1800 ; expire, seconds 1800 ) ; minimum TTL, seconds ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; DNS Servers for 'ezuce.com' ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; DNSNS Serversrecord for 'ezuce.com' ; server: openuc.ezuce.com ; ezuce.com. IN NS openuc.ezuce.com. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; \\; Call ;Routing NSfor recordSIP fordomain 'ezuce.com' ;; server: openuc.ezuce.com ; ezuce.com. IN NS openuc.ezuce.com. \\ ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; CallNAPTR Routingrecord for SIP domainTCP 'ezuce.com' ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; \\ ; NAPTR record for SIP TCP ezuce.com ; priority: 2 weight: 0 ; protocol: ; priority: 2 weight: 0 ; protocol: "SIP+D2T" regex: "" uri: _sip._tcp.ezuce.com ; ezuce.com. IN NAPTR 2 0 "s" "SIP+D2T" regex: "" uri: \_sip._tcp.ezuce.com. ; NAPTR record for SIP UDP ezuce.com. IN NAPTR ; priority: 2 weight: 0 ; protocol: "SIP+D2U" regex: "" uri: _sip._udp.ezuce.com ; ezuce.com. IN NAPTR 2 0 "s" "SIP+D2TD2U" "" \_sip._tcpudp.ezuce.com. \\ ; NAPTRSRV record for domain SIP UDPTCP ezuce.com ; ; priority: 1 2 weight: 0 ; protocol: "SIP+D2U" regex: "" uri: \port: 5060 server: openuc.ezuce.com ; _sip._udptcp.ezuce.com. IN ; SRV 1 0 5060 openuc.ezuce.com. IN NAPTR 2 0 "s" "SIP+D2U" "" \ ; SRV record for domain SIP UDP ezuce.com ; priority: 1 weight: 0 port: 5060 server: openuc.ezuce.com ; _sip._udp.ezuce.com. \\IN ; SRV record for domain SIP TCP1 ezuce.com0 5060 ; openuc.ezuce.com. ; SRV record for service SIP TCP rr.openuc.ezuce.com ; priority: 1 weight: 0 port: 5060 5070 server: openuc.ezuce.com ; \_sip._tcp.rr.openuc.ezuce.com. IN SRV 1 0 5060 SRV 1 0 5070 openuc.ezuce.com. \\ ; SRV record for domainXMPP SIPSERVER UDPTCP ezuce.com ; ; priority: 1 weight: 0 port: 5269 5060 server: openuc.ezuce.com ; \_sipxmpp-server._udptcp.ezuce.com. IN SRV 1 0 5060 SRV 1 0 5269 openuc.ezuce.com. \\ ; SRV record for serviceXMPP SIPCLIENT TCP rr.openuc.ezuce.com ; ; priority: 1 weight: 0 port: 5222 5070 server: openuc.ezuce.com ; \_sipxmpp-client._tcp.rr.openuc.ezuce.com. IN SRV 1 0 5070 SRV 1 0 5222 openuc.ezuce.com. \\ ; SRV record for XMPP SERVER CHAT ROOM TCP ezuce.com ; priority ; priority: 1 weight: 0 port: 5269 5222 server: openuc.ezuce.com ; \_xmpp-server._tcp.ezuce.com. IN SRV 1 0 5269 openuc.ezuce.com. \\ ; SRV record for XMPP CLIENT TCP ezuce.com ; priority: 1 weight: 0 port: 5222 server: openuc.ezuce.com ; \_xmpp-client._tcp NOTE: the XMPP client port is used here as this is the port used ; by openfire to service multi-user chat requests. ; _xmpp-server._tcp.conference.ezuce.com. IN SRV 1 0 5222 SRV 1 0 5222 openuc.ezuce.com. \\ ; SRV record for XMPP SERVERCLIENT CHAT ROOM TCP ezuce.com ; ; priority: 1 weight: 0 port: 5222 server: openuc.ezuce.com ; NOTE: the XMPP client port is used here as this is the port used ; by openfire to service multi-user chat requests. ; \_xmpp-server._tcp.conference.ezuce.com. IN SRV 1 0 5222 openuc.ezuce.com. \\ ; SRV record for XMPP CLIENT CHAT ROOM TCP ezuce.com ; priority: 1 weight: 0 port: 5222 server: openuc.ezuce.com ; \_xmpp-client._tcp.conference.ezuce.com. IN SRV 1 0 5222 openuc.ezuce.com. \\ ; _xmpp-client._tcp.conference.ezuce.com. IN SRV 1 0 5222 openuc.ezuce.com. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; IP Addresses ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; IPA record Addressesfor openuc.ezuce.com ; openuc.ezuce.com. IN A 192.168.5.2 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; \\ ; A record for openuc.ezuce.com ; openuc.ezuce.com. IN A 192.168.5.2 \\ ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; \\ |
Required DNS Records for a Multiple Server Environment
The following are the required records for a multiple server sipXecs system.
A DNS Domain that is equivalent to the SIP domain
A-Record (host record) for each of the servers
SRV records for the SIP communications (port 5060 tcp & udp) with priority and weight for each of the servers.
SRV record for the resource record (port 5070 tcp) for each of the servers. This record is used for replication services to locate other servers for replication.
SRV record for XMPP client connections (port 5222 tcp) for the IM server
SRV record for XMPP server connections (port 5269 tcp) for the IM server
SRV record for XMPP client connections to XMPP conference (port 5222) for the IM server
SRV record for XMPP servers connections to XMPP conference (port 5222) for the IM server
Example DNS Zone file
A typical DNS zone file for a multiple server configuration looks as follows (additional records for a multiple server installation are in red):
| Code Block |
|---|
; WARNING: Zone file configuration is a sipX automatically generated file. ; Contents may be overwritten unless you set the named.conf DNS_MODE. ; $TTL 1800 @ IN SOA ns1.ezuce.com. root.ezuce.com. ( 2010090201 ; serial# 1800 ; refresh, seconds 1800 ; retry, seconds 1800 ; expire, seconds 1800 ) ; minimum TTL, seconds \\ |
Required DNS Records for a Multiple Server Environment
The following are the required records for a multiple server sipXecs system.
A DNS Domain that is equivalent to the SIP domain
A-Record (host record) for each of the servers
SRV records for the SIP communications (port 5060 tcp & udp) with priority and weight for each of the servers.
SRV record for the resource record (port 5070 tcp) for each of the servers. This record is used for replication services to locate other servers for replication.
SRV record for XMPP client connections (port 5222 tcp) for the IM server
SRV record for XMPP server connections (port 5269 tcp) for the IM server
SRV record for XMPP client connections to XMPP conference (port 5222) for the IM server
SRV record for XMPP servers connections to XMPP conference (port 5222) for the IM server
Example DNS Zone file
A typical DNS zone file for a multiple server configuration looks as follows:
| Code Block |
|---|
; WARNING: Zone file configuration is a sipX automatically generated file. ; Contents may be overwritten unless you set the named.conf DNS_MODE. ; $TTL 1800 @ IN SOA ns1.ezuce.com. root.ezuce.com. ( 2010090201 ; serial# 1800 ; refresh, seconds 1800 ; retry, seconds 1800 ; expire, seconds 1800 ) ; minimum TTL, seconds ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; DNS Servers for 'ezuce.com' ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; \\ ; NS record for ezuce.com ; server: openuc.ezuce.com ; ezuce.com. IN NS IN NS openuc.ezuce.com. \\ ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Call Routing for SIP domain 'ezuce.com' ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; \\ ; NAPTR record for SIP TCP ezuce.com ; ; priority: 2 weight: 0 ; ; protocol: "SIP+D2T" regex: "" uri: \_sip._tcp.ezuce.com ; ezuce.com. IN NAPTR IN NAPTR 2 0 "s" "SIP+D2T" "" \_sip._tcp.ezuce.com. \\ ; NAPTR record for SIP UDP ezuce.com ; ; priority: 2 weight: 0 ; ; protocol: "SIP+D2U" regex: "" uri: \_sip._udp.ezuce.com ; ezuce.com. IN NAPTR IN NAPTR 2 0 "s" "SIP+D2U" "" \_sip._udp.ezuce.com. \\ ; SRV record for domain SIP TCP ezuce.com ; ; priority: 1 weight: 0 port: 5060 server: openuc.ezuce.com ; \_sip._tcp.ezuce.com. IN SRV SRV 1 0 5060 openuc.ezuce.com. \_sip._tcp.ezuce.com. IN SRV SRV 1 0 5060 openuc2.ezuce.com. \\ ; SRV record for domain SIP UDP ezuce.com ; ; priority: 1 weight: 0 port: 5060 server: openuc.ezuce.com ; \_sip._udp.ezuce.com. IN SRV SRV 1 0 5060 openuc.ezuce.com. \_sip._udp.ezuce.com. IN SRV SRV 1 0 5060 openuc2.ezuce.com. \\ ; SRV record for service SIP TCP rr.openuc.ezuce.com ; ; priority: 1 weight: 0 port: 5070 server: openuc.ezuce.com ; \_sip._tcp.rr.openuc.ezuce.com. IN SRV 1 SRV 1 0 5070 openuc.ezuce.com. \_sip._tcp.rr.openuc.ezuce.com. IN SRV SRV 2 100 5070 openuc2.ezuce.com. \\ \_sip._tcp.rr.openuc2.ezuce.com. IN SRV 1 SRV 1 0 5070 openuc2.ezuce.com. \_sip._tcp.rr.openuc2.ezuce.com. IN SRV SRV 2 100 5070 openuc.ezuce.com. \\ \\ ; SRV record for XMPP SERVER TCP ezuce.com ; ; priority: 1 weight: 0 port: 5269 server: openuc.ezuce.com ; \_xmpp-server._tcp.ezuce.com. IN SRV 1 0 5269 SRV 1 0 5269 openuc.ezuce.com. \\ ; SRV record for XMPP CLIENT TCP ezuce.com ; ; priority: 1 weight: 0 port: 5222 server: openuc.ezuce.com ; \_xmpp-client._tcp.ezuce.com. IN SRV 1 SRV 1 0 5222 openuc.ezuce.com. \\ ; SRV record for XMPP SERVER CHAT ROOM TCP ezuce.com ; priority ; priority: 1 weight: 0 port: 5222 server: openuc.ezuce.com ; ; NOTE: the XMPP client port is used here as this is the port used ; ; by openfire to service multi-user chat requests. ; \_xmpp-server._tcp.conference.ezuce.com. IN SRV 1 SRV 1 0 5222 openuc.ezuce.com. \\ ; SRV record for XMPP CLIENT CHAT ROOM TCP ezuce.com ; ; priority: 1 weight: 0 port: 5222 server: openuc.ezuce.com ; \_xmpp-client._tcp.conference.ezuce.com. IN SRV 1 SRV 1 0 5222 openuc.ezuce.com. \\ ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; IP Addresses ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; \\ ; A record for openuc.ezuce.com ; openuc.ezuce.com. IN A 192.168.5.2 openuc2.ezuce.com. IN A 192.168.5.3 \\ ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; \\ |
Scenario 1 – sipXecs PBX on the Data Network
Ok, so most companies aren't hiding under rocks and they are already using DNS internally on their networks. Like many, the internal network DNS domain name may not be the same as their Internet facing domain. Consider the following network scenario:
With our fictitious company, the internal computer network has an existing DNS domain of example.corp which is being used by Active Directory. DHCP and DNS are being handled by the file server at 192.168.10.10. The simplest approach to integrating sipXecs into this network is to leave DNS and DHCP on the file server and add the required SRV records and DHCP options to it.
There are a few problems with this scenario:
- The operation of your phone system is dependent on DNS working. If DNS or your File Server has problems, your phone system is also down.
- Mobile users that need to roam to different networks outside of the organization will not be able to resolve the example.corp domain from the internet.
- Users outside of your organization can not call your system via a SIP URL (sip:ext@example.com).
Problems 2 and 3 can be worked around, but problem 1 is the bigger issue. Making sure that you have a robust DNS configuration is important to your computer network and your phone network.
| Note | ||
|---|---|---|
| ||
In this scenario DNS and DHCP should be configured properly BEFORE installing sipXecs. |
Configure DNS
There are four DNS records that need to be configured for sipXecs to function properly. They are:
- A Record for sipXecs PBX host name
- SRV Record for SIP UDP Signaling Traffic
- SRV Record for SIP TCP Signaling Traffic
- SRV Record for sipXecs PBX Resource locating (Resource Record)
Add a new host record for the PBX (in the above example it would be something like sipxecs.example.corp) pointing to the IP address of the PBX.
Add SRV records for _sip._udp.example.corp, _sip._tcp.example.corp and _sip._tcp.rr.sipxecs.example.corp all pointing to sipxecs.example.corp (if you are doing this in a Microsoft Windows environment, see document mentioned in beginning of this whitepaper).
In a bind (Linux DNS) configuration file these records would look something like this:
| Code Block |
|---|
_sip._tcp.example.corp. IN SRV 1 0 5060 sipxecs.example.corp. _sip._udp.example.corp. IN SRV 1 0 5060 sipxecs.example.corp. _sip._tcp.rr.sipxecs.example.corp. IN SRV 1 0 5070 sipxecs.example.corp. sipxecs.example.corp. ;;; ; A record for openuc.ezuce.com ; openuc.ezuce.com. IN A 192.168.5.2 openuc2.ezuce.com. IN A 192.168.5.3 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; |
Scenario 1 – sipXecs PBX on the Data Network
Ok, so most companies aren't hiding under rocks and they are already using DNS internally on their networks. Like many, the internal network DNS domain name may not be the same as their Internet facing domain. Consider the following network scenario:
With our fictitious company, the internal computer network has an existing DNS domain of example.corp which is being used by Active Directory. DHCP and DNS are being handled by the file server at 192.168.10.10. The simplest approach to integrating sipXecs into this network is to leave DNS and DHCP on the file server and add the required SRV records and DHCP options to it.
There are a few problems with this scenario:
- The operation of your phone system is dependent on DNS working. If DNS or your File Server has problems, your phone system is also down.
- Mobile users that need to roam to different networks outside of the organization will not be able to resolve the example.corp domain from the internet.
- Users outside of your organization can not call your system via a SIP URL (sip:ext@example.com).
Problems 2 and 3 can be worked around, but problem 1 is the bigger issue. Making sure that you have a robust DNS configuration is important to your computer network and your phone network.
| Note | ||
|---|---|---|
| ||
In this scenario DNS and DHCP should be configured properly BEFORE installing sipXecs. |
Configure DNS
There are four DNS records that need to be configured for sipXecs to function properly. They are:
- A Record for sipXecs PBX host name
- SRV Record for SIP UDP Signaling Traffic
- SRV Record for SIP TCP Signaling Traffic
- SRV Record for sipXecs PBX Resource locating (Resource Record)
Add a new host record for the PBX (in the above example it would be something like sipxecs.example.corp) pointing to the IP address of the PBX.
Add SRV records for _sip._udp.example.corp, _sip._tcp.example.corp and _sip._tcp.rr.sipxecs.example.corp all pointing to sipxecs.example.corp (if you are doing this in a Microsoft Windows environment, see document mentioned in beginning of this whitepaper).
In a bind (Linux DNS) configuration file these records would look something like this:
| Code Block |
|---|
_sip._tcp.example.corp. IN SRV 1 0 5060 sipxecs.example.corp.
_sip._udp.example.corp. IN SRV 1 0 5060 sipxecs.example.corp.
_sip._tcp.rr.sipxecs.example.corp. IN SRV 1 0 5070 sipxecs.example.corp.
sipxecs.example.corp. IN A 192.168.10.2 |
Configure DHCP
DHCP is used by phones and PC's alike in this scenario to get IP addresses as well as other information needed about the network to operate properly.
In addition to an IP address, to operate properly phones need a Default Gateway (DHCP option 3), DNS Domain Name (DHCP option 15), DNS Server IP address (DHCP option 6) and a TFTP server address (DHCP option 66). If you are using a different provisioning method you're on your own here.
A typical DHCP configuration file from a Linux system would look like:
| Code Block |
|---|
subnet 192.168.10.0 netmask 255.255.255.0 { range 192.168.10.20 172.168.10.254; #IP Range default-lease-time 21600; max-lease-time 43200; option routers 192.168.10.1; # Default gateway option subnet-mask 255.255.255.0; # Subnet mask option domain-name "example.corp"; #DNS Domain Name option domain-name-servers 192.168.10.10; #DNS Server IP option time-offset 18000; # Eastern Standard Time option tftp-server-name "sipxecs.example.corp"; #phone provisioning option ntp-servers 192.168.10.10; IN#get Atime from file server 192.168.10.2 |
Configure DHCP
DHCP is used by phones and PC's alike in this scenario to get IP addresses as well as other information needed about the network to operate properly.
In addition to an IP address, to operate properly phones need a Default Gateway (DHCP option 3), DNS Domain Name (DHCP option 15), DNS Server IP address (DHCP option 6) and a TFTP server address (DHCP option 66). If you are using a different provisioning method you're on your own here.
A typical DHCP configuration file from a Linux system would look like:
| Code Block |
|---|
subnet 192.168.10.0 netmask 255.255.255.0 { range 192.168.10.20 172.168.10.254; #IP Range default-lease-time 21600; max-lease-time 43200; option routers 192.168.10.1; # Default gateway option subnet-mask 255.255.255.0; # Subnet mask option domain-name "example.corp"; #DNS Domain Name option domain-name-servers 192.168.10.10; #DNS Server IP} |
Testing
It is important to test your configuration and verify that it is operating as it should before you install your sipXecs system. Refer to the testing section above.
Boot a computer and make sure it receives an IP address just as a phone would. Check that it is receiving the proper DNS domain name (on a Windows machine you can use ipconfig /all from the command prompt to verify this).
Make sure the computer can Ping the PBX by its host name and us NSLOOKUP to verify that the SRV records are working as they should.
Once DNS and DHCP are working properly you are ready to install your sipXecs system.
Remote Users
Assuming now that your sipXecs system is up and running correctly, the next challenge with DNS is configuring it so that remote users can connect to your PBX. If those users are connecting via a VPN tunnel or wide area network, simply configure DNS on the far end to have the same DNS records and DHCP records we setup above.
If users are connecting from the Internet they are never going to be able to resolve example.corp because it isn't a valid DNS domain name. Your organization more than likely has something like example.com that is registered with an organization like Network Solutions and hosted either there or at another DNS hosting provider. The following host record and SRV records must be configured at your DNS hosting provider:
| Code Block |
|---|
_sip._tcp.example.com. IN SRV 1 0 5060 sipxecs.example.com. _sip._udp.example.com. IN SRV 1 0 5060 sipxecs.example.com. sipxecs.example.com. optionIN time-offsetA 18000; # Eastern Standard Time option tftp-server-name "sipxecs.example.corp"; #phone provisioning option ntp-servers 192.168.10.10; #get time from file server } |
Testing
It is important to test your configuration and verify that it is operating as it should before you install your sipXecs system. Refer to the testing section above.
Boot a computer and make sure it receives an IP address just as a phone would. Check that it is receiving the proper DNS domain name (on a Windows machine you can use ipconfig /all from the command prompt to verify this).
Make sure the computer can Ping the PBX by its host name and us NSLOOKUP to verify that the SRV records are working as they should.
Once DNS and DHCP are working properly you are ready to install your sipXecs system.
Remote Users
Assuming now that your sipXecs system is up and running correctly, the next challenge with DNS is configuring it so that remote users can connect to your PBX. If those users are connecting via a VPN tunnel or wide area network, simply configure DNS on the far end to have the same DNS records and DHCP records we setup above.
If users are connecting from the Internet they are never going to be able to resolve example.corp because it isn't a valid DNS domain name. Your organization more than likely has something like example.com that is registered with an organization like Network Solutions and hosted either there or at another DNS hosting provider. The following host record and SRV records must be configured at your DNS hosting provider:
| Code Block |
|---|
_sip._tcp.example.com.127.1.1.43 # Change to outside IP of your FW |
Configure your firewall to allow and NAT ports 5060 udp, 5060 tcp and ports 30000 - 31000 udp from 127.1.1.43 (again, this would be changed to YOUR external IP address) to 192.168.10.2 (this would be changed to the internal IP address of YOUR PBX).
Just as you tested your internal DNS, make sure you test the external DNS from outside your network.
One last step needs to be completed. sipXecs allows for domain name aliases (System Menu -> Domains). Add a domain alias for example.com. An alias allows the sipXecs system to respond to requests made to domains other than the domain it is setup with. It thus should be possible to setup your mobile users differently than your fixed position hard phone users and do a translation of example.com to example.corp.
Dynamic DNS
Wondering what about the case where the external IP address may change like with a Cable Modem or DSL connection? Usually the only way you will be able to deal with SRV records is by owning your own domain. Drop $20 a year with a hosting provider like GoDaddy.com or similar (just make sure they let you have SRV records) and get yourself a domain name.
Once you have an domain name, get setup with DynDNS or one of the other dynamic DNS providers (I use DynDNS because it works with Vyatta firewall). If you don't have a firewall that does dynamic DNS updates, you can usually run software on an internal machine that helps the dynamic DNS provider figure out your external IP address.
The dynamic DNS provider will let you determine your own host name and tag it to one of their domain names. For instance, examplecorp.dyndns.net might be a host name you could specify. We can then point to this dynamic DNS name from our own domain.
For pointing a host name at another host name we'll use a CNAME record (canonical name). So, externally the DNS would have a CNAME record setup pointing to the dynamic DNS name:
| Code Block |
|---|
sipxecs IN SRV 1 0 5060CNAME sipxecsexamplecorp.example.com.dyndns.net |
And then the SRV records would be setup also pointing to the dynamic DNS name as follows:
| Code Block |
|---|
_sip._udp.example.com. IN SRV 1 0 5060 sipxecs.example.com.
sipxecs.example.com. IN A 127.1.1.43 # Change to outside IP of your FW
|
Configure your firewall to allow and NAT ports 5060 udp, 5060 tcp and ports 30000 - 31000 udp from 127.1.1.43 (again, this would be changed to YOUR external IP address) to 192.168.10.2 (this would be changed to the internal IP address of YOUR PBX).
Just as you tested your internal DNS, make sure you test the external DNS from outside your network.
One last step needs to be completed. sipXecs allows for domain name aliases (System Menu -> Domains). Add a domain alias for example.com. An alias allows the sipXecs system to respond to requests made to domains other than the domain it is setup with. It thus should be possible to setup your mobile users differently than your fixed position hard phone users and do a translation of example.com to example.corp.
Dynamic DNS
Wondering what about the case where the external IP address may change like with a Cable Modem or DSL connection? Usually the only way you will be able to deal with SRV records is by owning your own domain. Drop $20 a year with a hosting provider like GoDaddy.com or similar (just make sure they let you have SRV records) and get yourself a domain name.
Once you have an domain name, get setup with DynDNS or one of the other dynamic DNS providers (I use DynDNS because it works with Vyatta firewall). If you don't have a firewall that does dynamic DNS updates, you can usually run software on an internal machine that helps the dynamic DNS provider figure out your external IP address.
The dynamic DNS provider will let you determine your own host name and tag it to one of their domain names. For instance, examplecorp.dyndns.net might be a host name you could specify. We can then point to this dynamic DNS name from our own domain.
For pointing a host name at another host name we'll use a CNAME record (canonical name). So, externally the DNS would have a CNAME record setup pointing to the dynamic DNS name:
| Code Block |
|---|
sipxecs CNAME examplecorp.dyndns.net |
And then the SRV records would be setup also pointing to the dynamic DNS name as follows:
| Code Block |
|---|
_sip._udp.example.com 86400 IN SRV 10 100 5060 examplecorp.dyndns.net _sip._tcp.example.com 86400 IN SRV 10 100 5060 examplecorp.dyndns.net .example.com 86400 IN SRV 10 100 5060 examplecorp.dyndns.net _sip._tcp.example.com 86400 IN SRV 10 100 5060 examplecorp.dyndns.net |
Notes on DNS & SRV Records with Polycom Phones
A flaw in Polycom's SRV record use has been identified. Polycom phones don't honor the DNS SRV weight, but they do honor the priority. What this means is that they don't resort the list of records when they get it from DNS. Most DNS servers by default produce the SRV records in cyclical order. This means that for a 3 server cluster there are 3 combinations that the records will show up.
A suggested work-around for this problem is to use the bind (9.6 & later) command rrset-order.
| Code Block |
|---|
rrset-order { type SRV order random; };
|
Documentation for rrset-order here: http://www.zytrax.com/books/dns/ch7/queries.html
rrset-order
rrset-order { order_spec ; [ order_spec ; ... ]
rrset-order defines the order in which multiple records of the same type are returned. This works for any record type in which the records are similar not just A or AAAA RRs and covers results in the ANSWER SECTION and the ADDITIONAL SECTION. The default is cyclic (round-robin).The full specification of rrset-order is shown below. An 'order_spec' is defined as:
class class_name ][ type type_name ][ name "domain_name"] order ordering;
Where 'class_name' is the record class, for example, IN (default is 'any'), type is the Resource Record type (if none specified defaults to 'any'), domain_name limits the statement to a specific domain suffix and defaults to root (all domains), order is a key word and ordering may take one of the following values:fixed - records are returned in the order they are defined in the zone file
random - records are returned in a random order
cyclic - records are returned in a round-robin fashion
Note: For reasons best known to the ISC (BIND's author) the fixed value is now (BIND 9.6+) only available if the configure option --with-fixed-rrset is used in the build. Neither BSD nor Debian standard packages use this option. This is likely to be true for Fedora and other RPMs but has not been verified (use named -V to check). For practical purposes only cyclic and random are the available choices.Examples
Defines that all equal records for all domains will be returned in random order.
Code Block rrset-order {order random;};Defines that all equal MX records for example.com will be returned in random order all others in cyclic order.
Code Block rrset-order {type MX name "example.com" order random; order cyclic};This statement may be used in a view or a global options clause.
Advanced DNS configuration
...