[asterisk-dev] DNS Support in Asterisk

[Matthew Jordan]

On Thu, Feb 12, 2015 at 10:31 AM, Bruce Ferrell <bferrell at baywinds.org>
wrote:

>
> I agree... DNSSEC... big deal.  DNS cache?  what?!  Let the system do that
> and keep the bloat out of asterisk
>
>
>
> On 02/12/2015 07:37 AM, Olle E. Johansson wrote:
> > There is one version of c-ares in resiprocate as well.
> >
> > C-ares has been in use for a long time and is in use every single day
> for you as part of
> > most curl installs. I am not sure there is much to do there.
> >
> > Libunbound adds a lot if that is what we want.
> >
> > Why is a cache a good thing? You surely have a caching resolver running
> > on your system, right?
> >
> > DNSsec is a huge deal - and the foundation for a lot of security things
> coming up.
> > Someone wrote an IETF draft about that and SIP.
> >
> > https://tools.ietf.org/html/draft-johansson-sipcore-dane-sip-00
> >
> > I got a patch sent to me that implements that in Asterisk with unbound,
> > but haven't gotten time to go through it and test it.
> >
> > /O
> >
> > On 12 Feb 2015, at 16:25, Brad Watkins <marquis42 at gmail.com> wrote:
> >
> >> Looking at this, I'm inclined to say that libunbound is the better of
> >> the two options in spite of it being somewhat more difficult to
> >> consume DNS records than it would be with c-ares.  In my estimation a
> >> (seemingly?) more-active community and the inclusion of a cache are
> >> more important.  DNSSEC isn't a huge deal, at least not for me at this
> >> time, but is a nice bonus as well.
> >>
> >> - Brad
> >>
> >> On Thu, Feb 12, 2015 at 10:01 AM, Joshua Colp <jcolp at digium.com> wrote:
> >>> Greetings all,
> >>>
> >>> I've extended the sections of my wiki page for c-ares[1] and
> libunbound[2]
> >>> to include further information about documentation, general usage
> >>> experience, and other aspects. Personally I lean towards libunbound
> because
> >>> it was straight forward to experiment with, supports DNSSEC, and has a
> >>> cache.
> >>>
> >>> Cheers,
> >>>
> >>> [1]
> >>>
> https://wiki.asterisk.org/wiki/display/~jcolp/DNS+Support+in+Asterisk#DNSSupportinAsterisk-c-ares
> >>> [2]
> >>>
> https://wiki.asterisk.org/wiki/display/~jcolp/DNS+Support+in+Asterisk#DNSSupportinAsterisk-libunbound
> >>>
>

After reading through the posts to this list, looking at Josh's analysis on
the aforementioned wiki pages, and looking at the libraries themselves, I'm
inclined to think that both of these are good libraries, would be perfectly
acceptable to use in Asterisk, and would be better than our current
functionality.

There are certainly some finer points for one over the other. In the
interest of moving forward, I'm going to propose that we choose libunbound
for the following reasons:
(1) It does support DNSSEC already, which would obviously be nice to have
available.
(2) Examples on the website are quite nice, which makes it a bit easier to
implement and get going. A hard part of this project is going to be
actually using the library in Asterisk, and the more time and energy we can
throw at that as opposed to getting the shim between Asterisk and the
library working, the better.

Keep in mind that Josh's proposed API (
https://wiki.asterisk.org/wiki/display/~jcolp/Asterisk+DNS+API) allows for
a resolver library to be changed behind the facade that the rest of
Asterisk will use - so if libunbound proves to be a poor choice, we are not
stuck with it.

Despite my motion for a resolution, if anyone has any objections, please
feel free to reply. I don't want to cut off discussion by any means, but I
think we're getting close to a point where we could start the
implementation of this, and knowing which resolver we're going to use will
be important in the next few weeks.

Thanks -

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150226/e25b4a72/attachment-0001.html>