[asterisk-bugs] [JIRA] (ASTERISK-24836) DNS Overhaul: Write a Resolver Implementation
Asterisk Team (JIRA)
noreply at issues.asterisk.org
Wed Jul 27 10:26:05 CDT 2016
[ https://issues.asterisk.org/jira/browse/ASTERISK-24836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Asterisk Team updated ASTERISK-24836:
-------------------------------------
Target Release Version/s: 14.0.0
> DNS Overhaul: Write a Resolver Implementation
> ---------------------------------------------
>
> Key: ASTERISK-24836
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-24836
> Project: Asterisk
> Issue Type: New Feature
> Security Level: None
> Components: Core/General
> Affects Versions: SVN, 13.0.0
> Reporter: Matt Jordan
> Assignee: Joshua Colp
> Target Release: 14.0.0
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list