On Thu, 2010-02-18 at 18:11 -0500, Jim Van Meggelen wrote: > I'm hoping to learn a bit more about DNS. > > I get it in theoretical terms, but the devil is in the details. > > Let's say I have my website atwww.mycompany.com > > The MX record points to my email provider somehow, and that seems to be > easy enough to set up. > > But how about having SIP calls to go to my PBX (which may or may not have > a hostname)? > > There are a few things that I can't quite get the hang of: > > 1. should I give my PBX a hostname such as pbx.mycompany.com?
Yes. > 2. should I make that a zone, and run a DNS server on my PBX? Definitely not. > 3. how do I getsip:[email protected] to go tosip:[email protected]? This is quite a complex question with several solutions. You are probably thinking about this in email terms. "Why is it I can I send mail to [email protected] and it ends up delivered to "user" on the server at mail.host.com?" Or even in web terms, "why does http://host.com an http://www.host.com go to the same place"? Lets start with the web first since it's the easiest to understand. Quite simply, it works because there are two DNS records that both point to the same ip address. It's that easy. For mail it's quite different. Mail servers use the MX (Mail Exchanger) record to figure out where to send mail. Basically, MX records let you query for a service (in this case mail) rather than a specific server. When you send mail to [email protected], the mail server can ask "who is responsible for mail on host.com?" and the reply is the MX record which might be something like mail.host.com. THEN a normal DNS lookup can happen which returns an IP address. Ok now to answer your question, "how do I get sip:[email protected] to go to sip:[email protected]?" There are two ways it could work. First, like the web example, just make mycompany.com and pbx.mycompany.com both point to the IP address of the pbx. But of course, this will break the web http://mycompany.com (unless your pbx and web server are on the same server... bad idea). The second way is to use something like MX records for SIP. These are known as SRV records and you can think about them like MX records on steroids. Just like MX, they allow you to query a DNS server to find out who is responsible for a service (SRV) rather than just looking up an IP address. If you do an DNS SRV lookup it lets you ask the question "who is responsible for SIP on mycompany.com?" and get the answer pbx.mycompany.com. All IP phones I've seen support SRV as a lookup mechanism. As a bonus, SRV allows you to specify load balancing and fail-over hosts. Truly the perfect solution for SIP. Actually, DNS SRV records could (should) replace all DNS lookups including MX and http (in fact that was the original intention) but that's unlikely to happen. It sure would solve a lot of headaches though.... --- Sidebar: www.host.com only works because "www" is so widely used that it's a "standard" just like ftp.host.com. Your web server could just as easily be called web.host.com or xyz.host.com but how would anyone ever know that? "www.host.com" is just a crude way of querying for a service and it only works as long as everyone follows the standard of naming their web servers "www". SRV is a much better solution but alas... --- > 4. should I just have the main DNS handle sip requests with the IP > address of my PBX, and forget about the zone/server pbx.mycompany.com? Yes. Dividing up your domain (zone) into sub zones is unnecessarily complex and solves nothing. > 5. should I be giving all my devices a hostname? do I allow those > hostnames to be handled by DNS? what about NAT and security? By devices do you mean phones? If so, that is completely optional. Remember the DNS mantra "hostnames are for humans." > I'm not looking for answers to all this in an email per se, but more > asking if somebody is willing to do a talk for us that might help > demystify all this? I'd love to do it but I'm not in TO. :( However, the O'Reilly book "DNS and BIND" is _the_ reference for this. -- John Lange http://www.johnlange.ca --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
