HTTP API for Updating DNS RecordsCisco Systems170 West Tasman DriveMailstop SJC-21/2San JoseCA95134USA+1 408 902-3341fluffy@cisco.comDynamic Network Services, Inc.tom@dyn-inc.comDynamic Network Services, Inc.jeremy@dyndns.comThis specification defines a simple HTTP based scheme for clients to
update DNS records.The draft is being discussed on the apps-discuss@ietf.org list.This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.There are many circumstances in which an application or device would
like to have an easy way to update DNS records. While a number of
support DNS based protocols exist for updating records, many of these mechanisms are not available in
today's scaled down applications and devices. However, many existing
application and devices do support the use of HTTP and HTTP over TLS to update DNS records. The
goal of this specification is to create a generic standard for which
applications and devices can update DNS records using HTTP over TLS.The need for this protocol exists from the use of DHCP and other
dynamic IP addressing systems, where a device receives updates to it IP
address, and further, there exists a need for the global DNS to be made
aware of such a change. Many residential NAT devices support this type
of operation today, but do it using hap-hazard and proprietary methods
.The approach described in the specification allows a client to make
HTTP over TLS requests to a server to update DNS records, using standard
and highly available encryption techniques for security, while providing
a generic a flexible interface for updating DNS recordsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.This section describes the semantics of requests to update DNS
records. The specification only covers how tell a DNS system what
updates are desired. How the DNS system deal with SOA records or DNSSEC
if not effected in any way by this specification.The client needs to be configured with the base URL for the server,
along with a username and password. The request is created by forming
an HTTPS POST request to a URL. The
HTTPS POST request is formed by starting with the configured base URL,
and then appending all the required parameters. The request MUST be
done using HTTPS to protect the password. The client MUST ensure the
TLS certificate of the server is appropriately signed.The HTTP request SHOULD contain a "User-Agent" header that clearly
identifies the version of the software making the request, as this
facilitates debugging.The request MUST include exactly one user, password, domain, and
type parameter as defined below. Other parameters are optional and can
occur at most once. The values of parameters MUST be appropriately
escaped as required to be part of a valid HTTP URL.Open Issue: there is some discussion going on around if it is
better to use HTTP basic auth or form style parameters. TODO Resolve
this.General ParametersParameter NameValueuserThe configured user name for the user making the request.passwordThe configured password for the user making the request base16
encoded as defined in .domainThe fully qualified domain name for the record to update.typeThe ASCII encoded version of they type of DNS record to
update.rdataThe value that should be stored in the DNS resource record.matchThe value that matches an existing resource record that is to be
updated by this request. A special value of "*" means that all
existing records are replaced by the new record in this request.ttlRequested time to live for the DNS records in seconds. If
omitted, this will be set to default chosen by the server.Some common values for the type parameter field are shown in the
following table.Type Parameters ValuesType NameValueADNS A record .AAAADNS AAAA record .CNAMEDNS CNAME record .NSDNS NS record .PTRDNS PTR record .SRVDNS SRV record .TXTDNS TXT record .HIPDNS HIP record .MXDNS MX record.SPFDNS SPF record.For many updates, where only one resource record is desired, the
match parameter is sent with a value of "*" indicating all existing
records are removed and replaced with the new one. 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. To add a
new record, no match value is sent, or the match value is empty, and
a new record is appended to the set. To update an existing record,
the match parameter is set to the value of the old record that needs
to be updated. If the record in the match parameter can not be
found, the request returns an 404 error.If the value of the parameter that would update a record is
empty, the record MUST be removed from DNS.HTTP response codes are used to indicate success and errors as
specified in the following table.Response CodesValueError Condition200No error, operation successful400The update parameters passed are invalid or would otherwise
result in an ambiguous update401Bad authentication credentials403Trying to update a record for which the given credentials are not
authorized.404No records were found that match the value in the match parameter
of the request.406A valid update was passed, however, it was not accepted for
reasons of update abuse, whereby excessive numbers of duplicate
updates have been sent.409A valid update was passed, however, no change was made as the
requested change was preexisting501The server does not support the specified operation503The server is too busy to service the request or is otherwise
unavailable and the client should wait at least 5 minutes before
trying to update againThe body of the response MAY have human readable text that allows a
network administrator to learn more about why the request failed.In the examples below, some of the URLs appear broken across multiple
lines. This is because of physical width limitations in this document;
such URLs need to be read as single URLs with no embedded white space.
All of the examples assume that a user called "me@example.net" with
password "no" is allowed to update records in the example.com domain.
The base URL for the DNS update service of
https://dns.example.org/dns/update is used in the examples.Each example shows the state of the DNS in a precondition before the
request, the requests performed using this specification, and then the
resulting state of the DNS in the postcondition.This example shows a basic update where all existing A record
values are replaced with a new entry.This example shows how to create entries where there are multiple
records.This example shows a simple removal of a record.This example shows how to append a record to a list of existing
records.This example is similar to the previous one, in that an entry is
being changed.This section is non normative. The WADL description for the examples is:This document makes no requests of IANA.The request includes a clear text password and MUST be done over
HTTPS or the password may be seen by an attacker and used to hijack the
services.If a user publishes the IP of their notebook computer, PDA, or smart
phone as the move, it is likely that the IP address can be correlated to
locations. By looking at the location over time for a specific user, it
may be further possible to correlate that to an actual person. These
attacks and implications to privacy are discussed in .Using HTTP Digest vs URL parameters.Way to set the resource record to the IP address that the server got
the request from.TODO - lots of work is needed here.RFC 2136 and the security for this provided by 3007, and the later
DNSSEC RFCs provide a robust system for updating DNS that supports
static shared secrets and asymmetric keys. Security working with
asymmetric keys not easy but doing with static keys is vulnerable to
offline attacks. Hard to do from Java script. Questions, any issues
punching through NATs that have DNS ALGs with this? Hard to integrate
with fine web security systems like openid. Trivial to implement this
most web environments.Questions about deployment success. When were things defined, what is
the market choosing? Does it work?Is the problem that we just need a simple open source library that
does Dynamic Update?Thanks to Frank Ellermann, Peter Koch, Stephane Bortzmeyer, Mark
Baker, Patrik Faltstrom, and Julian Reschke.Hypertext Transfer Protocol --
HTTP/1.1Department of Information and
Computer ScienceUniversity of California, IrvineIrvineCA92697-3425+1(949)824-1715fielding@ics.uci.eduWorld Wide Web
ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682jg@w3.orgCompaq Computer
CorporationWestern Research Laboratory250 University AvenuePalo AltoCA94305mogul@wrl.dec.comWorld Wide Web
ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682frystyk@w3.orgXerox CorporationMIT Laboratory for Computer Science, NE43-3563333 Coyote Hill RoadPalo AltoCA94034masinter@parc.xerox.comMicrosoft
Corporation1 Microsoft WayRedmondWA98052paulle@microsoft.comWorld Wide Web
ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682timbl@w3.orgThe Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used
for many tasks beyond its use for hypertext, such as name servers
and distributed object management systems, through extension of
its request methods, error codes and headers . A feature of HTTP
is the typing and negotiation of data representation, allowing
systems to be built independently of the data being
transferred.HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .Key words for use in RFCs to Indicate
Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keywordHTTP Over TLSThis memo describes how to use Transport Layer Security (TLS)
to secure Hypertext Transfer Protocol (HTTP) connections over the
Internet. This memo provides information for the Internet
community.The Base16, Base32, and Base64 Data EncodingsThis document describes the commonly used base 64, base 32, and
base 16 encoding schemes. It also discusses the use of line-feeds
in encoded data, use of padding in encoded data, use of
non-alphabet characters in encoded data, use of different encoding
alphabets, and canonical encodings. [STANDARDS TRACK]http://www.dyndns.com/developers/specs/syntax.htmlhttp://www.telnic.net/developers-resources.htmlhttp://articles.slicehost.com/assets/2008/5/27/Slicehost_API.pdflSliceHostHost Identity Protocol (HIP) Domain Name System (DNS)
ExtensionsThis document specifies a new resource record (RR) for the
Domain Name System (DNS), and how to use it with the Host Identity
Protocol (HIP). This RR allows a HIP node to store in the DNS its
Host Identity (HI, the public component of the node public-private
key pair), Host Identity Tag (HIT, a truncated hash of its public
key), and the Domain Names of its rendezvous servers (RVSs). This
memo defines an Experimental Protocol for the Internet
community.Using the Domain
Name System To Store Arbitrary String AttributesDigital Equipment Corporation550 King StreetLKG2-2/Z7LittletonMA01460-1289US+1 508 486 5922rosenbaum@lkg.dec.comWhile the Domain Name System (DNS),is generally used to store
predefined types of information (e.g., addresses of hosts), it is
possible to use it to store information that has not been
previously classified.This paper describes a simple means to associate arbitrary
string information (ASCII text) with attributes that have not been
defined by the DNS. It uses DNS TXT resource records to store the
information. It requires no change to current DNS
implementations.A DNS RR for specifying the location of
services (DNS SRV)Troll TechWaldemar Thranes gate 98BOsloN-0175NO+47 22 806390+47 22 806380arnt@troll.noInternet Software Consortium950 Charter StreetRedwood CityCA94063US+1 650 779 7001Microsoft CorporationOne Microsoft WayRedmondWA98052USlevone@microsoft.comThis document describes a DNS RR which specifies the location
of the server(s) for a specific protocol and domain.DNS Extensions to Support IP Version 6This document defines the changes that need to be made to the
Domain Name System (DNS) to support hosts running IP version 6
(IPv6). The changes include a resource record type to store an
IPv6 address, a domain to support lookups based on an IPv6
address, and updated definitions of existing query types that
return Internet addresses as part of additional section
processing. The extensions are designed to be compatible with
existing applications and, in particular, DNS implementations
themselves. [STANDARDS TRACK]Domain names
- implementation and specificationUSC/ISI4676 Admiralty WayMarina del ReyCA90291US+1 213 822 1511Secure Domain Name System (DNS) Dynamic UpdateThis document proposes a method for performing secure Domain
Name System (DNS) dynamic updates. [STANDARDS TRACK]Dynamic Updates in the Domain Name System
(DNS UPDATE)Internet Software ConsortiumStar Route Box 159AWoodsideCA 94062+1 415 747 0204paul@vix.comBellcore445 South StreetMorristownNJ 07960+1 201 829 4514set@thumper.bellcore.comCisco Systems170 West Tasman DriveSan JoseCA 95134-1706+1 914 528 0090yakov@cisco.comDigital Equipment Corp.110 Spitbrook Rd ZK3-3/U14NashuaNH 03062-2698+1 603 881 0400bound@zk3.dec.com
Applications
domain namedomain name systemThe Domain Name System was originally designed to support
queries of a statically configured database. While the data was
expected to change, the frequency of those changes was expected to
be fairly low, and all updates were made as external edits to a
zone's Master File.Using this specification of the UPDATE opcode, it is possible
to add or delete RRs or RRsets from a specified zone.
Prerequisites are specified separately from update operations, and
can specify a dependency upon either the previous existence or
nonexistence of an RRset, or the existence of a single RR.UPDATE is atomic, i.e., all prerequisites must be satisfied or
else no update operations will take place. There are no data
dependent error conditions defined after the prerequisites have
been met.Domain Name System (DNS) Security Extensions Mapping for the
Extensible Provisioning Protocol (EPP)This document describes an Extensible Provisioning Protocol
(EPP) extension mapping for the provisioning and management of
Domain Name System security extensions (DNSSEC) for domain names
stored in a shared central repository. Specified in XML, this
mapping extends the EPP domain name mapping to provide additional
features required for the provisioning of DNS security extensions.
[STANDARDS TRACK]Identity Trail: Covert Surveillance Using DNSWeb Application Description Language (WADL)