[asterisk-dev] [Code Review] 4437: dns: Define a core DNS API with examples.

[Ashley Sanders]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4437/#review14556
-----------------------------------------------------------


These are my findings regarding the first few sections of the document. On the technical-side, I have only made one small observation. All other observations are related to phrasing or a request for more information. At this time, I am still reviewing the API and examples sections.


As a general observation, I suggest stating somewhere in this document the RFCs we are supporting with the API. I have seen other DNS server implementations do something similar on their project's home and/or wiki pages.


Overview

"The Asterisk DNS API is designed as a thin wrapper over resolver implementations." By resolver implementations, plural, do you mean the DNS server will serve as a thin wrapper around implementations of a full-service resolver and a stub resolver?

So that your intentions are clearly conveyed from the start, I suggest that both occurrences of the phrase "some dns types" (last sentence in the overview) should be replaced with the concrete dns lookup/request/record types that this implementation will support.


Threading

Perhaps consider rephrasing this section to something like:

"The API provides a guarantee that it is safe to initiate and cancel queries from any thread. It does NOT, however, provide a guarantee that the ordering of queries shall be preserved. In other words, if you execute multiple queries individually, you will not necessarily receive callbacks in the order the queries were originally executed. This API only guarantees that an individual DNS result and records are safe to retrieve within the scope of the respective asynchronous callback."

Also, I think, if we receive a 'cancel' query, that should trump any other queries currently in the queue. Imho, it wouldn't make much sense to make a user wait for the queue to empty before executing the cancel (assuming the cancel query was last in line).


Query

I think we should provide more information here about the way we intend to implement the mechanics of queries under the hood: 

>From wikipedia (http://en.wikipedia.org/wiki/Domain_Name_System#DNS_resolvers):
"A DNS query may be either a non-recursive query or a recursive query:

A non-recursive query is one in which the DNS server provides a record for a domain for which it is authoritative itself, or it provides a partial result without querying other servers.
A recursive query is one for which the DNS server will fully answer the query (or give an error) by querying other name servers as needed. DNS servers are not required to support recursive queries."


Result
As a consumer of the API, I would want to know specifically the kind(s) of information about the DNS query contained in the result. Also, does this return an error if it is impossible to get an answer for the query?


Record - Here is where I would go into more detail the types of records we support



- Ashley Sanders


On Feb. 22, 2015, 6:25 p.m., Joshua Colp wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4437/
> -----------------------------------------------------------
> 
> (Updated Feb. 22, 2015, 6:25 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> A wiki page is present at:
> 
> https://wiki.asterisk.org/wiki/display/~jcolp/Asterisk+DNS+API
> 
> Which details a new DNS API for Asterisk. This exists as a thin wrapper over other resolver libraries. The core part provides a common interface and some additional features, such as NAPTR/SRV parsing and recurring lookups. Examples are provided which cover the common use cases for the API.
> 
> Some stuff to think about:
> 
> 1. Does this encompass everything we think a low level API should?
> 2. Are there any higher level APIs that would be useful to have?
> 3. Is the usage intuitive and easy?
> 4. Are there other examples which would help?
> 5. Do we want resolvers to be actual modules or keep them in-core?
> 6. Anything else you think of
> 
> Have at it!
> 
> 
> Diffs
> -----
> 
> 
> Diff: https://reviewboard.asterisk.org/r/4437/diff/
> 
> 
> Testing
> -------
> 
> I've logically run through the API and examples to ensure they provide what is needed for the future, to make them as easy as possible to use, and to ensure higher level APIs can be created.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150226/e3557873/attachment.html>