Subject: [dns-dir] FWD [Re: draft-jennings-app-dns-update-00]

From: Peter Koch <[email-masked]>
Date: Tue, 8 Jul 2008 08:24:49 +0200

FYI,

here's yet another DNS related proposal <draft-jennings-app-dns-update-00.txt>
that we might want to have 9someone have) a look at.

-Peter

----- Forwarded message from Peter Koch <[email-masked]> -----

From: Peter Koch <[email-masked]>
To: Cullen Jennings <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-jennings-app-dns-update-00
Date: Tue, 8 Jul 2008 07:58:28 +0200

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?

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
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

----- End forwarded message -----
_______________________________________________
dns-dir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-dir

---

From: Thomas Narten <[email-masked]>
Date: Tue, 08 Jul 2008 09:34:13 -0400

This one bears watching, if not close attention, because of the
"problem" it sets out to solve:

> 1.  Introduction
> 
>    There are many circumstances in which an application would like to
>    have an easy way to update DNS records.  The DynDNS service[5],
>    supported on many residential NATs, is one example:  it updates a DNS
>    record to point at the NAT after the NAT receives a dynamically
>    assigned IP address.  Another common use case is dynamically created
>    servers in elastic computing environments.  When new servers are
>    created, they often need to update DNS records.
> 
>    The approach described in this specification allows a client to make
>    a simple HTTP[1] request to a server.  The client is authenticated
>    using a shared secret.  The server is authenticated with TLS, which
>    provides both integrity for the transaction and confidentiality for
>    the shared secret.  The request contains information that instructs
>    the server to update a particular DNS record.  The specification is
>    limited to updating a simple subset of DNS records and does not
>    support more complex operations such as the multiple changes that
>    need to happen as an atomic transactions.

It also appears to have the following fatal flaw (you can't properly
identify individual RRs within an RRset by an offset):

> 3.2.1.  Entries with multiple records
> 
>    Sometimes it is desirable to have multiple records of the same type
>    for the same name.  For example, a domain may have multiple MX
>    records.  The index parameter provides a number value, call it i,
>    that can be used to indicate that the i'th record MUST be updated.
>    The first record has an index value of 1, not 0.  Two special values
>    are defined 0 and -1.
> 
>    The value 0 indicates that there should only be the single record and
>    all others MUST be removed.  If a request does not have any index
>    parameters, it is processed as if the index parameter were 0.
> 
>    The index value -1 indicates that, unless the exact value already
>    exists in an existing record, the index MUST be added to the list of
>    existing records.  When a record with an index value of -1 is updated
>    and the exact value already exists, a success response is returned,
>    exactly as if the value had not existed and had been appended.

That said, its an individual submission and may only reflect the views
of the author.

Thomas