DNS and DHCP planning for new 4.6 deployment

[Kurt Albershardt]

About to start testing 4.6 for deployment later this year. It will live behind a pfSense firewall which currently manages DHCP and local DNS for all internal hosts. My inclination would be to delegate sipx.domain.com to the new box and allow it to run DHCP for all voice-related devices, but continue to manage the other hosts via DHCP and DNS on pfSense.

Any reason to make the sipx machine(s) authoritative for the entire domain, and manage the non-voice parts there as well?

thanks~

[Tony Graziano]

Not exactly a straight answer... Pfsense can hand out the dhcp options the
same as sipx. I would consider DNS forwarding to the sup domain and do this
quite regularly. This way sipx is responsible only for its sip domain /DNS.

But that's me. I typically deploy sipx as a sudimain and keep things tidy
like that.l

Post by Kurt Albershardt
About to start testing 4.6 for deployment later this year. It will live
behind a pfSense firewall which currently manages DHCP and local DNS for
all internal hosts. My inclination would be to delegate sipx.domain.comto the new box and allow it to run DHCP for all voice-related devices, but
continue to manage the other hosts via DHCP and DNS on pfSense.
Any reason to make the sipx machine(s) authoritative for the entire
domain, and manage the non-voice parts there as well?
thanks~
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Tony Graziano]

Not exactly a straight answer... Pfsense can hand out the dhcp options the
same as sipx. I would consider DNS forwarding to the sup domain and do this
quite regularly. This way sipx is responsible only for its sip domain /DNS.

How I do it -- I typically deploy sipx as a subdomain and keep things tidy
like that. I point pfsense to sipx for the subdomain and point sipx back to
pfsense as it forward server if there are other domains/hosts internally it
needs to know about otherwise I just use public forwarders and keep sipx
oblivious to the inside stuff.

Post by Kurt Albershardt
About to start testing 4.6 for deployment later this year. It will live
behind a pfSense firewall which currently manages DHCP and local DNS for
all internal hosts. My inclination would be to delegate sipx.domain.comto the new box and allow it to run DHCP for all voice-related devices, but
continue to manage the other hosts via DHCP and DNS on pfSense.
Any reason to make the sipx machine(s) authoritative for the entire
domain, and manage the non-voice parts there as well?
thanks~
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Tony Graziano]

(this is also a way of saying pfsense cannot handle the record type sipx
needs, it needs a real dns server to be authoritative for it, not just an A
record)

Post by Tony Graziano
Not exactly a straight answer... Pfsense can hand out the dhcp options the
same as sipx. I would consider DNS forwarding to the sup domain and do this
quite regularly. This way sipx is responsible only for its sip domain /DNS.
How I do it -- I typically deploy sipx as a subdomain and keep things tidy
like that. I point pfsense to sipx for the subdomain and point sipx back to
pfsense as it forward server if there are other domains/hosts internally it
needs to know about otherwise I just use public forwarders and keep sipx
oblivious to the inside stuff.

Post by Kurt Albershardt
About to start testing 4.6 for deployment later this year. It will live
behind a pfSense firewall which currently manages DHCP and local DNS for
all internal hosts. My inclination would be to delegate sipx.domain.comto the new box and allow it to run DHCP for all voice-related devices, but
continue to manage the other hosts via DHCP and DNS on pfSense.
Any reason to make the sipx machine(s) authoritative for the entire
domain, and manage the non-voice parts there as well?
thanks~
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
sip: ***@voice.myitdepartment.net
Fax: [phone]
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

[Kurt Albershardt]

Thanks - I think we're on the same page here. There's an authoritative external NS which for the main (domain.com) zone, but the pfSense box handles internal users (split horizon.)

How much of the sipx-managed zone do I want to expose to the outside world?

(this is also a way of saying pfsense cannot handle the record type sipx needs, it needs a real dns server to be authoritative for it, not just an A record)
Not exactly a straight answer... Pfsense can hand out the dhcp options the same as sipx. I would consider DNS forwarding to the sup domain and do this quite regularly. This way sipx is responsible only for its sip domain /DNS.
How I do it -- I typically deploy sipx as a subdomain and keep things tidy like that. I point pfsense to sipx for the subdomain and point sipx back to pfsense as it forward server if there are other domains/hosts internally it needs to know about otherwise I just use public forwarders and keep sipx oblivious to the inside stuff.
About to start testing 4.6 for deployment later this year. It will live behind a pfSense firewall which currently manages DHCP and local DNS for all internal hosts. My inclination would be to delegate sipx.domain.com to the new box and allow it to run DHCP for all voice-related devices, but continue to manage the other hosts via DHCP and DNS on pfSense.
Any reason to make the sipx machine(s) authoritative for the entire domain, and manage the non-voice parts there as well?
thanks~

[Tony Graziano]

Sipxconfig if you need access remotely. Port 5080 if using trunking. Port
5060 and srv if supporting remote users. So "a" records if using web GUI.
Srv if supporting remote users. Make sure you rate limit port 5060 in the
firewall and consider adding pfblocker package too.

Post by Kurt Albershardt
Thanks - I think we're on the same page here. There's an authoritative
external NS which for the main (domain.com) zone, but the pfSense box
handles internal users (split horizon.)
How much of the sipx-managed zone do I want to expose to the outside world?
(this is also a way of saying pfsense cannot handle the record type sipx
needs, it needs a real dns server to be authoritative for it, not just an A
record)
On Sun, Jun 17, 2012 at 3:09 PM, Tony Graziano <

Post by Tony Graziano
Not exactly a straight answer... Pfsense can hand out the dhcp options
the same as sipx. I would consider DNS forwarding to the sup domain and do
this quite regularly. This way sipx is responsible only for its sip domain
/DNS.
How I do it -- I typically deploy sipx as a subdomain and keep things
tidy like that. I point pfsense to sipx for the subdomain and point sipx
back to pfsense as it forward server if there are other domains/hosts
internally it needs to know about otherwise I just use public forwarders
and keep sipx oblivious to the inside stuff.

Post by Kurt Albershardt
About to start testing 4.6 for deployment later this year. It will live
behind a pfSense firewall which currently manages DHCP and local DNS for
all internal hosts. My inclination would be to delegate sipx.domain.comto the new box and allow it to run DHCP for all voice-related devices, but
continue to manage the other hosts via DHCP and DNS on pfSense.
Any reason to make the sipx machine(s) authoritative for the entire
domain, and manage the non-voice parts there as well?
thanks~

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Tony Graziano]

Oh. And the srv for xmpp if you are supporting remote users or enabling
xmpp federation.

Post by Tony Graziano
Sipxconfig if you need access remotely. Port 5080 if using trunking. Port
5060 and srv if supporting remote users. So "a" records if using web GUI.
Srv if supporting remote users. Make sure you rate limit port 5060 in the
firewall and consider adding pfblocker package too.

Post by Kurt Albershardt
Thanks - I think we're on the same page here. There's an authoritative
external NS which for the main (domain.com) zone, but the pfSense box
handles internal users (split horizon.)
How much of the sipx-managed zone do I want to expose to the outside world?
(this is also a way of saying pfsense cannot handle the record type sipx
needs, it needs a real dns server to be authoritative for it, not just an A
record)
On Sun, Jun 17, 2012 at 3:09 PM, Tony Graziano <

Post by Tony Graziano
Not exactly a straight answer... Pfsense can hand out the dhcp options
the same as sipx. I would consider DNS forwarding to the sup domain and do
this quite regularly. This way sipx is responsible only for its sip domain
/DNS.
How I do it -- I typically deploy sipx as a subdomain and keep things
tidy like that. I point pfsense to sipx for the subdomain and point sipx
back to pfsense as it forward server if there are other domains/hosts
internally it needs to know about otherwise I just use public forwarders
and keep sipx oblivious to the inside stuff.

Post by Kurt Albershardt
About to start testing 4.6 for deployment later this year. It will
live behind a pfSense firewall which currently manages DHCP and local DNS
for all internal hosts. My inclination would be to delegate
sipx.domain.com to the new box and allow it to run DHCP for all
voice-related devices, but continue to manage the other hosts via DHCP and
DNS on pfSense.
Any reason to make the sipx machine(s) authoritative for the entire
domain, and manage the non-voice parts there as well?
thanks~

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/