This particular document isn't meant to be a tutorial on how to create DNS zones or add records to them. It is meant to help the reader understand the issues surrounding DNS configurations for sipXecs and how to leverage DNS in different scenarios. DNS configuration seems to be the most difficult concept for users new to the system to grasp.
DNS setup can be tricky for a system setup where a user needs to be able to roam from inside the office to outside and then maybe even be on a VPN connection. To make this all work seamlessly, the PBX must be able to be referenced the same way no matter where the end-user is located.
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.
...
An A record is a typical host name pointer to an IP address. So, sipx.xyzcompany.com might be an A record that points to 127.1.1.43. In this example, sipx is the host name, xyzcompany.com is the domain name and sipx.xyzcompany.com is referred to as the fully qualified domain name (fqdn). We use A records because it's easier to remember computer names than a series of numbers (for most people anyway). Most Asterisk configurations the author has seen run with an A record setup for the PBX.
SRV records (service records) are used by newer Internet protocols to locate a type of service that might be available for a domain. MX records (mail exchange) work similarly to SRV records but are used specifically for mail. SRV records can be used for any number of services. A SIP service record will look like _sip._udp.xyzcompany.com. In this example a SIP device can query DNS for domain xyzcompany.com and find an IP address or host name for SIP services running on the UDP protocol. Similarly, _sip._tcp.xyzcompany.com would return an IP address or host name for SIP services running on the TCP protocol. So, a phone registering to the xyzcompany.com domain would lookup _sip._udp.xyzcompany.com and have the host name sipx.xyzcompany.com returned. Why not just cut to the chase and use the A record? You'll see why in a bit.
sipXecs PBX configurations are typically setup with SRV records (strongly recommended). SRV records are the method utilized to locate the sipXecs PBX in a clustered environment.
...
As described above, A Records are simply name pointers to IP addresses. While A record naming is not typically recommended for sipXecs installations, A records can be utilized to locate the pbx. On a clean sipXecs system (before you add any users), under system administration, go into the System menu and select the Domain menu item. Change the domain name to the fully qualified domain name that you would like to use, click 'Apply' and then reboot.
Make sure your new A record is in your internal DNS server pointing to the internal IP address of the sipXecs pbx.
Internally DNS zone file for the xyzcompany.com domain would have an A record setup pointing to the IP of the PBX: sipx A
| Code Block |
|---|
sipx A 192.168.10.2 |
Have your ISP (or if you can do it yourself with a self-managed DNS hosting provider) add an A record for your pbx pointing at the external IP address of your firewall/SBC.
Externally, DNS would have an A record setup pointing to the external IP which is mapped to the internal IP of the PBX:
sipx A 127.1.1.43
Testing A Record Configuration
| Code Block |
|---|
sipx A 127.1.1.43 |
Testing A Record Configuration
Verify that it all works properly by pinging the PBX by name from both inside the firewall and from outside the firewall using the same DNS domain name. For example:
| Code Block |
|---|
ping sipx.xyzcompany.com |
Should return something like:
| Code Block |
|---|
Pinging sipx.xyzcompany.com [192.168.10.2] with 32 bytes of data: |
...
Reply from 192.168.10.2: bytes=32 time=1ms TTL=64 |
...
Reply from 192.168.10.2: bytes=32 time=1ms TTL=64 |
...
Reply from 192.168.10.2: bytes=32 time=1ms TTL=64 |
...
Reply from 192.168.10.2: bytes=32 time=1ms TTL=64 |
...
Ping statistics for 192.168.10.2: |
...
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), |
...
Approximate round trip times in milli-seconds: |
...
Minimum = 1ms, Maximum = 1ms, Average = 1ms |
From the Internet the results should be similar but the IP address will be the external IP address of the firewall/SBC (assuming of course that you are allowing ICMP traffic).
SRV Records
So, why are SRV records typically used by sipXecs? Well, they allow us to be contacted with the same address used to deliver e-mail and SRV records allow for server redundancy and load balancing.
| Note |
|---|
This section is missing some information. Perhaps someone could complete it? |
Take for example the top salesperson for XYZ Company, Joe User. Joe's phone extension is 512 and he has an email address of joe.user@xyzcompany.com. SRV records allow Joe User to be contacted at [] and if an alias is put on his user account he can also be called by phone at []. If xyzcompany.com were using A records for their sipXecs installation, Joe's phone number and alias would have be [] and [] respectively (unless of course the addresses are transformed by the SBC, but then we get into the whole problem of inside the network and outside the network).
SRV records also allow the administrator to have redundant and load balanced SBC computers (sipXecs also uses this method for locating PBX's in a clustered/high availability configuration). SRV records hold the following information:
Service: the symbolic name of the desired service.
- Protocol: this is usually either TCP or UDP.
- Domain name: the domain for which this record is valid.
- TTL: standard DNS time to live field.
- Class: standard DNS class field (this is always IN).
- Priority: the priority of the target host.
- Weight: A relative weight for records with the same priority.
- Port: the TCP or UDP port on which the service is to be found.
- Target: the hostname of the machine providing the service.
An example SRV record might look like this in a DNS zone file:
| Code Block |
|---|
_sip._udp.example.com 86400 IN SRV 0 5 5060 sipx.xyzcompany.com. |
This SRV record points to a server named sipx.xyzcompany.com listening on UDP port 5060 for SIP protocol connections. The priority given here is 0, and the weight is 5.
The priority field is similar to an MX record's priority value. Clients always use the SRV record with the lowest priority value first, and only fall back to other records if the connection with this record's host fails. Thus a service may have a designated "fallback" server, which will only be used if the primary server fails. Only another SRV record, with a priority field value higher than the primary server's record, is needed.
...
In the following example, both the priority and weight fields are used to provide a combination of load balancing and backup service.
| Code Block |
|---|
_sip._udp.example.com 86400 IN SRV 10 60 5060 sipx1.xyzcompany.com. |
...
_sip._udp.example.com 86400 IN SRV 10 20 5060 sipx2.xyzcompany.com. |
...
_sip._udp.example.com 86400 IN SRV 10 20 5060 sipx3.xyzcompany.com. |
...
_sip._udp.example.com 86400 IN SRV 20 0 5060 sipx4.xyzcompany.com. |
The first three records share a priority 10, so the weight field's value will be used by clients to determine which host to contact. The sum of all three values is 100, so sipx1.xyzcompany.com will be used 60% of the time. The other two hosts, sipx2 and sipx3, will be used for 20% of requests each. If sipx1.xyzcompany.com is unavailable, these two remaining machines will share the load equally, since they will each be selected 50% of the time.
If all three hosts with priority 10 are unavailable, the record with the next highest priority value will be chosen, which is sipx4.xyzcompany.com. This might be a machine in another physical location, presumably not vulnerable to anything that would cause the first three hosts to become unavailable.
Let's look at what these records look like on the internal DNS server and then on the external DNS server. We'll just concentrate on a single SBC and not a redundant configuration.
So, internally DNS zone file for the xyzcompany.com domain would have an A record setup pointing to the IP of the PBX:
sipx A 192.168.10.2
...
| Code Block |
|---|
sipx A 192.168.10.2 |
And then the SRV records would be setup as follows:
| Code Block |
|---|
...
_sip._udp.xyzcompany. |
...
_sip._tcp.xyzcompany.com 86400 IN SRV 10 100 5060 sipx.xyzcompany.com
Externally, DNS would have an A record setup pointing to the external IP of the PBX (which would have a 1:1 NAT mapping to the internal IP address of the PBX and be firewalled appropriately):
sipx A 127.1.1.43
And then the SRV records would be setup exactly as they were internally (note, if you are using OpenSBC it only needs the UDP record):
_sip._udp.xyzcompany.com 86400 IN SRV 10 100 5060 sipx.xyzcompany.com
_sip._tcp.xyzcompany.com 86400 IN SRV 10 100 5060 sipx.xyzcompany.com
com 86400 IN SRV 10 100 5060 sipx.xyzcompany.com
_sip._tcp.xyzcompany.com 86400 IN SRV 10 100 5060 sipx.xyzcompany.com |
Externally, DNS would have an A record setup pointing to the external IP of the PBX (which would have a 1:1 NAT mapping to the internal IP address of the PBX and be firewalled appropriately):
| Code Block |
|---|
sipx A 127.1.1.43 |
And then the SRV records would be setup exactly as they were internally (note, if you are using OpenSBC it only needs the UDP record):
| Code Block |
|---|
_sip._udp.xyzcompany.com 86400 IN SRV 10 100 5060 sipx.xyzcompany.com
_sip._tcp.xyzcompany.com 86400 IN SRV 10 100 5060 sipx.xyzcompany.com |
Testing SRV Configuration
...
At the command line enter:
| Code Block |
|---|
dig --t SRV _sip._udp.xyzcompany.com |
The following will be displayed:
| Code Block |
|---|
; <<>> DiG 9.3.4-P1 <<>> -t SRV _sip._udp.xyzcompany.com |
...
;; global options: |
...
printcmd |
...
;; Got answer: |
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48387 |
...
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 |
...
;; QUESTION SECTION: |
...
;_sip._udp.xyzcompany.com. |
...
IN SRV ;; ANSWER SECTION: |
...
_sip._udp.xyzcompany.com. |
...
0 IN SRV 0 0 5060 sipx.xyzcompany.com. |
...
;; Query time: 3 msec |
...
;; SERVER: 172.16.1.254#53(172.16.1.254) |
...
;; WHEN: Sat |
...
Jan 3 15:46:12 2009 |
...
;; MSG |
...
SIZE rcvd: 81 |
From the ANSWER: 1 in the returned information and the sipx.xyzcompany.com in the ANSWER SECTION: we know that the SRV record is working properly.
From a Windows workstation the nslookup command can be used:
At the command prompt enter:
| Code Block |
|---|
nslookup |
| Code Block |
|---|
Default Server: |
...
UnKnown |
...
Address: |
...
172.16.1.254 |
...
> set (enter this)
...
> set querytype=SRV > _sip._udp |
...
Server: UnKnown
...
.xyzcompany.com Server: UnKnown Address: 172.16.1.254 |
...
_sip._udp.xyzcompany. |
...
com SRV service |
...
priority = 0
weight = 0
port = 5060
...
location: priority = 0 weight = 0 port = 5060 svr hostname = sipx.xyzcompany.com |
Scenario 1 – sipXecs PBX on the Data Network
...