Subject: draft-jennings-app-dns-update-00

From: Cullen Jennings <[email-masked]>
Date: Sun, 6 Jul 2008 21:12:24 -0700

The draft proposes a HTTP based API to update DNS records similar to  
the system at dyndns.org. Be pleased to get peoples thoughts but I'm  
going to be slow responding due until after the Dublin meeting.

Thanks, Cullen

Begin forwarded message:

> From: [email-masked]
> Date: July 6, 2008 7:45:01 PM PDT (CA)
> To: [email-masked]
> Subject: I-D Action:draft-jennings-app-dns-update-00.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : HTTP API for Updating DNS Records
> 	Author(s)       : C. Jennings
> 	Filename        : draft-jennings-app-dns-update-00.txt
> 	Pages           : 9
> 	Date            : 2008-07-06
>
> This specification defines a simple HTTP based scheme for clients to
> update DNS records.
>
> The draft is being discussed on the [email-masked] list.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jennings-app-dns-update-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 8 Jul 2008 01:43:07 +0200

Cullen Jennings wrote:

> a HTTP based API to update DNS records similar to the system at
> dyndns.org.  Be pleased to get peoples thoughts

Interesting.  I've implemented a simple dyndns update client, the
main trick is to get this right in hardware, and then stick to it
for some *decades* (sic!).  Discuss it also with the dyndns folks.

In the record parameters I miss MX and SPF among others.  I'm not
sure about "MUST https", how about SHOULD ?  Dyndns allows more
than one "host".  You have that as domain, clearly you don't want
to limit it to hosts, but allowing more than one might be good.

In the examples ITYM one "?" to start the query part with the 1st
name=value pair, but later the conventional separator is "&", not
"?".  

Apart from 0 and -1, do those indices actually work with DNS ?
What a client sees as second record might not be the second
record in a RR set from a server's POV.

Example 4.2 actually defines two MX records, it doesn't "update"
them.  If the index is supposed to be either -1, 0, or n+1 (for
n existing records) this might work.  But then index=1 has the
same effect as index=0, and n+1 has the same effect as index=-1,
so something is still odd with those indices.

How about s/index/action/ and:
action=0 kill all, optionally create new first
action=1 keep all, add new record

If action=1 matches an existing record it's a noop, no harm done.

A very interesting part in the dyndns protocol is that clients
MUST NOT update anything unless it has changed.  They go as far 
as demanding to maintain persistent state (surviving a reboot).

They also allow to omit the IP, taking the IP of the query as
default (when update clients cannot figure out what the public
IP is).

 Frank

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Jul 2008 22:26:56 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: Sunday, July 06, 2008 9:12 PM
> To: [email-masked]
> Subject: draft-jennings-app-dns-update-00
> 
> 

It seems the GET method is inappropriate because you're causing a side-effect
(updating of the DNS), <http://www.w3.org/DesignIssues/Axioms.html#state>.

-d

---

From: Peter Koch <[email-masked]>
Date: Tue, 8 Jul 2008 07:58:28 +0200

> the system at dyndns.org. Be pleased to get peoples thoughts but I'm  

a cursory review raises these questions from a DNS protocol and operational
perspective:

1) We do have Dynamic Updates and EPP as "provisioning" protocols.
   Which deficiencies is this approach trying to address in particular?

2) The list of RR types is pretty arbitrary. Some RR type independence in
   the spirit of RFC 3597 would be urgently needed, making error "501"
   not occur.

3) How is the SOA serial increment initiated?

4) Interaction with DNSSEC needs to be described

5) What kind of intra-RRSet ordering is assumed in section 3?

6) Why would a user be allowed to add/modify/delete arbitrary RRSets?

NITS:
   o SRV RRs require domain names as targets , not IP addresses
   o The reference to RFC 1464 ngling - which is OK, since 1464 has no
     practical relevance
   o The draft is aiming at Standards Track, but references the Experimental
     RFC 5205 in a way that should be normative

-Peter

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 8 Jul 2008 08:36:58 +0200

Dan Wing wrote:
 
> It seems the GET method is inappropriate because
> you're causing a side-effect (updating of the DNS)

This needs some words about caching, doesn't it ?  
I forgot that when I asked why it has "MUST https".

 Frank

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 8 Jul 2008 09:49:51 +0200

On Sun, Jul 06, 2008 at 09:12:24PM -0700,
 Cullen Jennings <[email-masked]> wrote 
 a message of 85 lines which said:

> The draft proposes a HTTP based API to update DNS records similar to the 
> system at dyndns.org. 

This is yet another "DNS modification" API. You may also consider
".tel":

http://www.telnic.net/developers-landing2.html

And others such as Slicehost:

http://articles.slicehost.com/2008/5/13/slicemanager-api-documentation
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "Mark Baker" <[email-masked]>
Date: Tue, 8 Jul 2008 12:41:44 -0400

> (updating of the DNS), <http://www.w3.org/DesignIssues/Axioms.html#state>.

Yes, most definitely.  GET should be used when you want to retrieve
records, not change them.  PUT seems the right  method to use for
updating existing records, while POST seems appropriate for adding new
records.

Kudos for not running out and inventing a whole new DNS-specific
update protocol though.

Mark.
-- 
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Coactus; Web-inspired integration strategies http://www.coactus.com
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 8 Jul 2008 18:47:34 +0200

On Tue, Jul 08, 2008 at 12:41:44PM -0400,
 Mark Baker <[email-masked]> wrote 
 a message of 34 lines which said:

> PUT seems the right method to use for updating existing records,
> while POST seems appropriate for adding new records.

That's not what RFC 2616 says.

   The fundamental difference between the POST and PUT requests is
   reflected in the different meaning of the Request-URI. The URI in a
   POST request identifies the resource that will handle the enclosed
   entity.
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "Mark Baker" <[email-masked]>
Date: Tue, 8 Jul 2008 13:00:25 -0400

>   POST request identifies the resource that will handle the enclosed

I don't see how that contradicts what I said.

Mark.

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 9 Jul 2008 10:19:52 +0200

>   Which deficiencies is this approach trying to address in particular?

Specifically I see need for explicit text on why Dynamic Updates is  
"not good enough".

    Patrik

---

From: Simon Leinen <[email-masked]>
Date: Wed, 09 Jul 2008 12:18:30 +0200

> Kudos for not running out and inventing a whole new DNS-specific

That would have been "REinventing" - see RFC 2136, "Dynamic Updates in
the Domain Name System", P. Vixie (Ed.), April 1997.
-- 
Simon.
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Jul 2008 17:56:44 -0700

On Jul 7, 2008, at 10:26 PM, Dan Wing (dwing) wrote:

> (updating of the DNS), <http://www.w3.org/DesignIssues/Axioms.html#state 
> >.
>
> -d

Yep, agree - a few people have pointed this out to me. 
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Jul 2008 18:30:01 -0700

Peter - many thanks - appreciate your comments and would like to talk  
to you more about this

>    Which deficiencies is this approach trying to address in  

Clearly this is the fundamental question in trying to decide what to  
do with this draft. This approach is very simplistic with less  
features than other but approaches. However, an simple HTTP approach  
seems to be one that an is gaining a fair amount of adoption in actual  
deployments.
>    the spirit of RFC 3597 would be urgently needed, making error "501"
I can easily imagine a parameter with the record type and a second  
parameter with the value.  Interesting the implementors of the servers  
don't seem to be keen on that - hard to tell why but some part of it  
is they don't want to negotiate capabilities. No matter what happened,  
saying all record types need to be supported is very unlikely to be  
implemented and at the same time the draft needs to define some  
minimum set needs to specified.

> 3) How is the SOA serial increment initiated?
I was sort of hoping the draft did not have to get into this. Ideas on  
what you think is needed?
> 4) Interaction with DNSSEC needs to be described
Not sure what to say. If the records are signed or not seem somewhat  
separable topic than  this.
> 5) What kind of intra-RRSet ordering is assumed in section 3?
good point - I suspect that there should be no assumptions about the  
order used here and what might actually end up in DNS
> 6) Why would a user be allowed to add/modify/delete arbitrary RRSets?
The whole security model is very simplistic, a given user is  
authorized (or not authorized) to update anything in a domain.   
Suggestions?
>    o SRV RRs require domain names as targets , not IP addresses
oops
>      RFC 5205 in a way that should be normative
hmm - probably not real important one way or the other but why do you  
think this should be a normative reference? I'm just passing a string  
which happens to cary some data that

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 11 Jul 2008 09:01:30 +0200

On 9 jul 2008, at 03.30, Cullen Jennings wrote:

> seems to be one that an is gaining a fair amount of adoption in  
> actual deployments.

I would like to know more what you imply with "simple", and urge you  
to add that research in the draft.

I.e. "why not use DNS dynamic update" section would make sense.

    Patrik

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 15 Jul 2008 19:40:23 -0700

> Specifically I see need for explicit text on why Dynamic Updates is  

Agree this section is needed. I'm not planning to do anything with  
this draft before (or at) Dublin but if I revise the draft, I will add  
a section about when it is appropriate and see if anything intelligent  
can be put there.