[getdns-api] 0.268 srv_addresses not useful

[Phillip Hallam-Baker]

I think that the DNS interface is the wrong place to put the SRV management
logic. I would much rather that the DNS API provides just an interface to
retrieve DNS records and there be a second API that provides the high level
service resolution logic.

The reason for this is that we have multiple DNS records that can be used
to resolve services: A, AAAA, SRV, NAPTR, URI and there is another that I
am bout to submit, WK which is an attempt to provide unification.


Each of those six records is intended to support service discovery. They do
it in different ways, but they are all essentially trying to do the same
thing.

Rather than have an API that sits mid-way between DNS and discovery, I
would prefer to have an API for each end. In particular I would like the
Discovery API to hide all the details of how the discovery is processed and
simply return a socket (or other connection) to the specified endpoint.

That way the API allows us to define a new DNS record and applications will
start making use of it as soon as they start using the new version of the
support library.

It can also add in support for features such as processing DANE records or
whatever else you might want it to do.

On Thu, Jan 31, 2013 at 2:52 PM, Phil Pennock
<getdns-api-phil at spodhuis.org>wrote:

> On 2013-01-31 at 10:37 -0800, Paul Hoffman wrote:
> > That was not the intention; the intention was to use the RFC 2782
> > default logic. And it looks like I did it badly. Thanks for catching
> > this!
>
> Welcome.  At least some good came out of my writing that DNS wrapper
> library for handling SRV lookups.  :)
>
> -Phil
> _______________________________________________
> getdns-api mailing list
> getdns-api at vpnc.org
>



-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vpnc.org/pipermail/getdns-api/attachments/20130131/69df6783/attachment.html>