Subject: What do apps developers need from DNS?

From: Andrew Sullivan <[email-masked]>
Date: Tue, 3 Mar 2009 11:58:32 -0500

Dear colleagues,

I'm one of the co-chairs of the DNSEXT working group.  I've lately
been wondering, "What do applications want?" and I thought it would be
better to ask some people than to speculate blindly.  

The DNS appears to be an important protocol for applications, but
those of us who are charged with maintaining the protocol are
sometimes confronted with what seems like two opposite pieces of
evidence.  On the one hand, we hear a lot about how difficult it is to
get DNS data to applications and how impossible it is to introduce a
new RRTYPE (not because of the assignment procedures -- which are now
pretty streamlined -- but because of the deployment problems).  On the
other hand, we keep seeing the application of the DNS to new problems,
sometimes with the use of a TXT record (and the attendant problems)
and sometimes with the use of new RRTYPEs.  We want to understand what
the issues are that application writers have with the DNS -- what are
the problems, why does everyone like TXT records so much, and how
could DNS work better for you?  Now is a particularly good time to
produce a wish list, because it is possible that some APIs will be
built in order to make DNSSEC data more easily available.  If you have
other things you want to reach down and grab at the same time, this
would be a good time to ask.  (That said, I'm not an OS manufacturer,
so I can't promise that any particular desire will be met.)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 18:07:16 +0100

> better to ask some people than to speculate blindly.

Having a standard API to retrieve arbitrary DNS data would be immensely
useful.  I recall multiple efforts in this area (the getrrinfo API,
etc), but either nothing has been standardized or were never widely
implemented.

If that doesn't happen, at least an interface to retrieve DNS SRV
records would be useful to standardize.  getsrvinfo?

Right now some of my applications use res_query() and contains a DNS
parser to get at SRV records.  This feels quite backwards.

I had some hopes that interfaces could be built using standard URL
interfaces (hence RFC 4501) that returned MIME tagged data (hence RFC
4027) although this hasn't happened.  Maybe what is missing is a patch
to implement this in, e.g., Curl...

/Simon

---

From: Dave Cridland <[email-masked]>
Date: Tue, 03 Mar 2009 17:37:35 +0000

> better to ask some people than to speculate blindly.

As Simon says, DNS is low-level, and apps implmentors don't really  
like getting our hands that dirty.

As things stand, not only do we have to kick bits about, but we have  
different ways of kicking bits about in each flavour OS.

Standard APIs would go a long way to solve this - it'd be fine if  
these were high-level APIs easily shimmed on top of existing OS DNS  
magic.

FWIW, I'd love to see more deployment of NAPTR, for instance, and  
such an API could support that along with SRV.

Just the SRV would get immediate and happy usage, though, by XMPP and  
RadioDNS and ...

Dave.

> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Stig Venaas <[email-masked]>
Date: Wed, 04 Mar 2009 09:49:20 +0100

Dave Cridland wrote:
[...]
> FWIW, I'd love to see more deployment of NAPTR, for instance, and such 
> an API could support that along with SRV.

I've been writing a couple of applications with code for looking up SRV
and I've been wishing there were some standard API. I would definitely
like to see that. NAPTR would be good also.

Stig

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 4 Mar 2009 10:00:29 +0100

On Tue, Mar 03, 2009 at 06:07:16PM +0100,
 Simon Josefsson <[email-masked]> wrote 
 a message of 29 lines which said:

> useful.

On the other hand, most applications should not deal with DNS directly
(because it would tie them to a specific directory, preventing future
evolutions to things like LDAP or local files). I'm glad that apps use
getaddrinfo(), not res_query().

> records would be useful to standardize.  getsrvinfo?

May be starting from an existing library and deciding its API is the
de facto standard? I suggest Ruli <http://www.nongnu.org/ruli/>.

> parser to get at SRV records.  This feels quite backwards.

Why not using Ruli (or another existing library)?

> interfaces (hence RFC 4501) that returned MIME tagged data (hence
> RFC 4027) although this hasn't happened.  Maybe what is missing is a
> patch to implement this in, e.g., Curl...

Very good idea, IMHO.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 04 Mar 2009 10:15:37 +0100

Another shameless plug: ldns might do what you want, see
http://www.nlnetlabs.nl/projects/ldns/

	jaap

---

From: Patrik Wallstrom <[email-masked]>
Date: Wed, 4 Mar 2009 10:27:35 +0100

> http://www.nlnetlabs.nl/projects/ldns/

Please also take a look on how DNS with DNSSEC is implemented in DKIM- 
milter.
http://sourceforge.net/mailarchive/forum.php?thread_name=20081022115814.R21752%40protagonist.smi.sendmail.com&forum_name=dkim-milter-discuss
( http://shorl.com/fapruhuvisoby )

It is using libunbound also from NLNet Labs, as part of Unbound.

-- 
patrik_wallstrom->foodfight->[email-masked]>+46-733173956

---

From: Keith Moore <[email-masked]>
Date: Wed, 04 Mar 2009 14:01:54 -0500

I'll add mine to the list of people wanting a standard API that isn't
limited to address lookups.

IMHO, the API needs to be able to handle asynchronous queries rather
than simply waiting for a response.

The API needs to be DNS ONLY.  No /etc/hosts, NIS, netinfo, LLMNR, or
Microsoft lookups - at least, not unless explcitly indicated by the app.

on a more ambitious level...

1. Speaking of LLMNR, there is a real need to resolve the tussle between
local lookups (say on an ad hoc network or one that is disconnected from
its DNS server) and DNS lookups.  (and no, putting LLMNR on a separate
port did not solve the problem).  IMHO it should be possible for each
host to be the master of its own domain, so to speak, so that it
maintains the authoritative copy of the RRs for its domain, and any
other servers that are advertised via NS records are secondaries.  Then
there should be no difference between LLMNR-style lookups and DNS
lookups that follow an NS chain from the root - other than needing
DNSSEC authentication before trusting the former.  (note that the host
doesn't actually need to provide its own DNS server for ordinary
queries, though it might want to do so for LLMNR).

I think this actually is possible with existing protocols but IMHO this
ought to become the normal mode of operation.  Especially with so many
mobile hosts these days.

Right now we have the situation where things like consumer grade routers
want to impose their own DNS proxies/caches so that they can implement
local names - and in doing so they inevitably break things because e.g.
they don't do caching correctly.

This would also help resolve the problem that DNS is often out of sync
with reality because different people maintain the DNS servers than
maintain the hosts.  E.g. if applications could create their own
SRV/NAPTR RRs then those RRs would be much more likely to accurately
reflect reality.  Right now SRV records are just another way for the app
to break.

2. DNS is extraordinarly easy to misconfigure.  I'm not sure that the
protocols need changing to fix this problem, so much as having better
administrative interfaces, and administrative interfaces that are
well-defined across implementations.  For instance, separately
specifying the NS record, kind of DNS updating, server names/addresses
for the peers, and authentication credentials is a pain in the wazoo; to
say nothing of the steps required to copy that information to the peer,
tickle the DNS servers to get them to recognize the configuration
change, and test the new configuration to make sure it works.  It's not
rocket science, but even for one who understands it, it's easy to forget
a step or to do something wrong.   People who don't do this every day
are especially prone to making such errors.

Keith

---

From: Leif Johansson <[email-masked]>
Date: Sun, 8 Mar 2009 16:23:38 +0100

> better to ask some people than to speculate blindly.

It is also important to ask what can application developers expect from 
deployers wrt DNS. I've seen several schemes fail even though they
used DNS "the right way" (TM) because getting anything past the local
DNS weenie proved impossible except where the local DNS weenie 
had interest and clue.

Why is this? Possibly DNS isn't regarded as providing _direct_ business 
value so it is difficult to motivate changes to DNS infrastructure to 
support applications (beyond getaddrinfo). Possibly the risk of making
changes to DNS (deploying an application which changes the usage
pattern of the enterprise DNS *is* a risk) given its central role is viewed 
as always too high a risk.

If DNS is going to support applications beyond getaddrinfo then APIs
are certainly important but equally important is to get major DNS 
implementors to subscribe to the notion that DNS has a role to play
beyond getaddrinfo. They will then offer products that allow even the
most clueless of DNS weenie to stick  NAPTR records for ENUM or 
key records for DKIM in their zone without (undue) hesitation.

	Cheers Leif