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

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

On Jul 7, 2008, at 10:58 PM, Peter Koch wrote:

> On Sun, Jul 06, 2008 at 09:12:24PM -0700, Cullen Jennings wrote:
> >
> > 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
>
> 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?
>

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.
>
>
> 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.
>
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?
>
>
> NITS:
>    o SRV RRs require domain names as targets , not IP addresses
>
oops
>
>    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
>
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
>
>
> -Peter

_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss