[getdns-api] 0.268 srv_addresses not useful

[Phillip Hallam-Baker]

+1

Having been in the IETF twenty years I now spend quite a bit of my time
trying to fix problems that result from an issue I identified fifteen years
ago, made a proposal to fix it before it became a problem but had the
solution rejected on the grounds that people didn't see the need to fix the
problem before we came to it.

I proposed a HTTP authentication scheme that would have blocked phishing
back in 1993. But they thought it much more important that a Web Server be
able to use existing UNIX password files for authentication than to prevent
a MITM attack on password authentication and applied the same logic to HTML.


Since I am writing code I am going to be deciding what API features I
provide. My plan is to provide two separate levels of access:

Unrestricted access to all DNS data:

class DNSClient {
        public DNSResponse Query(DNSRequest Request) {
            }
        }

Depending on the resolution mode specified in the class specification, the
above call can be used to make a recursive call to a stub resolver (what an
application needs) or direct access to authoritative name servers (for
network admin tools, DNS proxies and Certificate Authorities validating
issue requests).

I don't think any application programmer should need to use that interface
though. The interface they should be using would be:


    public OmniSocket Connect (string remoteHostName, string
remoteServiceName) {
        }
  (plus the obvious convenience functions for Async handling, etc. etc.)

So you want to connect to http, then you use one of the following:

OmniSocket  socket = Connect ("example.com", "_http._tcp")
OmniSocket  socket = Connect ("example.com", 80)
OmniSocket  socket = Connect ("10.1.2.3", 80)
OmniSocket  socket = Connect ("10.1.2.3", 80)

The discovery library then gets the best available connection according to
the programmer defined trust etc. criteria and the quality of connection
achieved can be verified by properties exposed by OmniSocket.

Which discovery mechanism was used would depend on whether a protocol was a
grandfathered protocol that is already defined as using a well known port
or SRV discovery. But the objective would be to allow introduction of a new
DNS record that would provide a superset of SRV and URI capabilities and
also allow connection policy information to be specified.

If the application was a Web Service then the API would bump up another
level of abstraction and deliver a HTTP socket.


On Fri, Feb 1, 2013 at 10:01 AM, Andrew Sullivan <asullivan at dyn.com> wrote:

> On Thu, Jan 31, 2013 at 05:18:58PM -0500, Phil Pennock wrote:
> > srv_addresses_all is available, by some name, it's useful and my lack of
> > ability to see a use for the other is not a reason to block it, if
> > someone else wants it and the API designer is happy it fits into the
> > overall aesthetic.
>
> I think this is an important guiding principle in this work.  The
> history of things like getaddrinfo is plainly full of decisions that
> started from, "Can we think of a use someone actually needs for this?"
> and, if the answer was no, the functionality was left out.  In my
> opinion, this was a mistake, because it makes certain kinds of things
> simply too hard without being a DNS weenie.  (And, of course, it makes
> some things impossible.)
>
> Best,
>
> A
>
>
> --
> Andrew Sullivan
> Dyn, Inc.
> asullivan at dyn.com
> v: +1 603 663 0448
> _______________________________________________
> 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/20130201/421239e2/attachment-0001.html>