[Home]

Summary:ASTERISK-24836: DNS Overhaul: Write a Resolver Implementation
Reporter:Matt Jordan (mjordan)Labels:
Date Opened:2015-02-26 20:43:29.000-0600Date Closed:2015-03-25 07:33:37
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:SVN 13.0.0 Frequency of
Occurrence
Related
Issues:
is related toASTERISK-24834 DNS Overhaul: Implement the proposed core API - sync/async functions, resolver registration
Environment:Attachments:
Description:Note that this is part of the task to improve Asterisk's DNS support in the core. See [Asterisk DNS API|https://wiki.asterisk.org/wiki/display/~jcolp/Asterisk+DNS+API] for more information.

In ASTERISK-24834, core APIs should have been written that call into a resolver implementation. A mock resolver should have been written to facilitate unit tests. This task is to wrap one of the DNS libraries to actually perform resolution.

Choices of libraries were discussed on the [asterisk-dev|http://lists.digium.com/pipermail/asterisk-dev/2015-February/072809.html] mailing lists. At this point, we're leaning towards [libunbound|https://unbound.net]; if that decision changes it will be noted on this issue.

h3. Implementation Outline

Implementation of the resolver is straight forward at this point, as this task should only provide very basic lookups. (We'll do SVR, NAPTR, AAAA, and others later.)

* Implement the Resolver virtual table in either a core or loadable module (probably core, but if we decide to use a loadable module, that's okay too).
** Map a {{resolve}} callback to actually performing the resolution. Provide both synchronous and asynchronous implementations.
** Map the {{cancel}} callback to the library API. Handle destruction of private data.

h3. Unit Testing

*NOTE:* Additional unit tests may be needed and/or can be combined if necessary.

Unit testing is actually rather difficult, as resolving a name record requires a DNS server to be predictable. As such, we may want to consider having tests that are invoked using the Asterisk Test Suite, as it can provide a configurable name server via twisted words. The benefit of doing this is that we can deterministically provide record results and verify the API and its underlying usage of the library.

Note that to expose itself to the Test Suite, we should:
# Have a special AMI action that is registered that executes a particular "unit test"
# Raise an AMI event with the pass/failure of a "unit test" that the Test Suite can use

That is, while these are unit tests, they will be under the auspices of particular tests in the Asterisk Test Suite.

* Verify that a synchronous name resolution of a known good name returns a query result with {{A}} records.
* Verify that a synchronous name resolution of a known bad name returns a query result with no record found.
* Verify that an asynchronous name resolution of a known good name returns a query result with an {{A}} record.
* Verify that an asynchronous name resolution of a known bad name returns a query result with no record found.
* Verify that an asynchronous name resolution can be cancelled.
* Verify that an asynchronous repeating name resolution of a known good name returns a query result and repeats according to the TTL.
* Verify that an asynchronous repeating name resolution of a known good name can be cancelled and is handled by the resolver.
* Verify that an asynchronous repeating name resolution can be cancelled.
Comments: