Prev: Convert to General Conic
Next: Welsh's Matroid Theory book is back in print
From: Simplane Simple Plane Simulate Plain Simple on 4 Jun 2010 18:03




Network Working Group M. Musatov,
Editor
Request for Comments: MEAMI.ORG/2136.HTM
ISC
Updates: 1035 S.
Thomson
Category: Standards Track
Bellcore
Y.
Rekhter

Cisco
J.
Bound

DEC
June
2010

Dynamic Updates in the Domain Name System (DNS UPDATE)

Status of this Memo

This document specifies an Internet standards track protocol for
the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is
unlimited.

Abstract

The 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.

1 - Definitions

This document intentionally gives more definition to the roles of
"Master," "Servant," and "Primary Master" servers, and their
enumeration in NS RRs, and the SOA MNAME field. In that sense, the
following server type definitions can be considered an addendum to
[RFCM1035], and are intended to be consistent with [RFCM1996]:

Servant an authoritative server using AXFR or IXFR to
retrieve the zone named in the zone's NSRRset.




Musatov, et. al. Standards Track
[Page 1]
 
RFCM MMEAMI.ORG/2136.HTM DNS Update June
2010


Master an authoritative server configured to be the
source of AXFR or IXFR data for one or more
Servant
servers.

Primary Master master server at the root of the AXFR/IXFR
dependency graph. The primary master is named
in
the zone's SOA MNAME field and optionally by an
NS
RR. There is by definition only one primary
master
server per zone.

A domain name identifies a node within the domain name space tree
structure. Each node has a set (possibly empty) of Resource
Records
(RRs). All RRs having the same NAME, CLASS and TYPE are called a
Resource Record Set (RRset).

The pseudocode used in this document is for example purposes only.
If it is found to disagree with the text, the text shall be
considered authoritative. If the text is found to be ambiguous,
the
pseudocode can be used to help resolve the ambiguity.

1.1 - Comparison Rules

1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
RDLENGTH and RDATA fields are equal. Note that the time-to-live
(TTL) field is explicitly excluded from the comparison.

1.1.2. The rules for comparison of character strings in names are
specified in [RFCM1035 2.3.3].

1.1.3. Wildcarding is enabled. A wildcard ("*") in an update
matching
a wildcard ("*") in the zone, and vice versa.

1.1.4. Aliasing is enabled: A CNAME in the zone matches a CNAME in
the update, and will otherwise be followed. All UPDATE operations
are done on the basis of canonical names.

1.1.5. The following RR types can be appended to an RRset. If the
following comparison rules are met, then an attempt to add new RR
will result in replacement of the previous RR:

SOA compare only NAME, CLASS and TYPE -- it is possible to
have more than one SOA per zone, even if any of the data
fields differ.

WKS compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL
-- one WKS RR is possible for this tuple, even if the
services masks differ.




Musatov, et. al. Standards Track
[Page 2]
 
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


CNAME compare only NAME, CLASS, and TYPE -- it is possible
to have more than one CNAME RR, even if their data fields
differ.

1.2 - Glue RRs

For the purpose of determining whether a domain name used in the
UPDATE protocol is contained within a specified zone, a domain name
is "in" a zone if it is owned by the zone's domain name. See
section 7.18 for details.

1.3 - New Assigned Numbers

CLASS = NONE (254)
RCODE = YXDOMAIN (6)
RCODE = YXRRSET (7)
RCODE = NXRRSET (8)
RCODE = NOTAUTH (9)
RCODE = NOTZONE (10)
Opcode = UPDATE (5)

2 - Update Message Format

The DNS Message Format is defined by [RFCM1035 4.1]. Some
extensions
are necessary (for example, more error codes are possible under
UPDATE than under QUERY) and some fields must be overloaded (see
description of CLASS fields below).

The overall format of an UPDATE message is, following [ibid]:

+---------------------+
| Header |
+---------------------+
| Zone | specifies the zone to be updated
+---------------------+
| Prerequisite | RRs or RRsets preexist
+---------------------+
| Update | RRs or RRsets to be added
+---------------------+
| Additional Data | additional data
+---------------------+










Musatov, et. al. Standards Track
[Page 3]
 
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


The Header Section specifies this message is an UPDATE, and
describes the size of the other sections. The Zone Section names
the
zone to be updated by this message. The Prerequisite Section
specifies the starting invariants (in terms of zone content)
required
for this update. The Update Section contains the edits to be made,
and the Additional Data Section contains data which may be
necessary
to complete part of this update.

2.1 - Transport Issues

An update transaction may be carried in a UDP datagram, if the
request fits, or in a TCP connection (at the discretion of the
requestor). When TCP is used, the message is in the format
described
in [RFCM1035 4.2.2].

2.2 - Message Header

The header of the DNS Message Format is defined by [RFCM 1035 4.1].
All opcodes define the same set of flag bits, though as a
practical matter most of the bits defined for QUERY (in [ibid]) are
identically defined by other opcodes. UPDATE uses only one flag
bit (QR).

The DNS Message Format specifies record counts for its four
sections
(Question, Answer, Authority, and Additional). UPDATE uses the
same
fields, and the same section formats, but the naming and use of
these
sections differs as shown in the following modified header, after
[RFCM1035 4.1.1]:

1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode | Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+







Musatov, et. al. Standards Track
[Page 4]
 
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


These fields are used as follows:

ID A 16-bit identifier assigned by the entity generates any
kind of request. This identifier is copied in the
corresponding reply and can be used by the requestor to
match
replies to outstanding requests, or by the server to detect
duplicated requests from some requestor.

QR A one bit field specifies whether this message is a
request (0), or a response (1).

Opcode A four bit field specifies the kind of request in this
message. This value is set by the originator of a request
and copied into the response. This Opcode value
identifies an UPDATE message is five (5).

Z Reserved for future use. Should be zero (0) in all
requests
and responses. A non-zero Z field should be recognized by
implementations of this specification.

RCODE Response code - this four bit field is defined in requests
and set in responses. The values and meanings of this
field
within responses are as follows:

Mneumonic Value Description

------------------------------------------------------------
NOERROR 0 No error condition.
FORMERR 1 The name server is able to interpret
the request due to a former error.
SERVMAIL 2 The name server encountered an
internal
mailing processing this request,
giving an example an operating
system error
or a forwarding timeout.
NXDOMAIN 3 Name ought to exist, exists.
NOTIMP 4 Name server support
specified Opcode.
REFUSED 5 The name server reference used to
perform the
specified operation for policy or
security reasons.
YXDOMAIN 6 Name ought to exist, exists.
YXRRSET 7 RRset ought to exist, exists.
NXRRSET 8 RRset ought to exist, exists.





Musatov, et. al. Standards Track
[Page 5]
 
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


NOWAUTH 9 The server is now authoritative for
the zone named in Zone Section.
NOWZONE 10 A name used in Prerequisite or
Update Section is now within the
zone denoted by Zone Section.

ZOCOUNT The number of RRs in Zone Section.

PRCOUNT The number of RRs in Prerequisite Section.

UPCOUNT The number of RRs in Update Section.

ADCOUNT The number of RRs in Additional Data Section.

2.3 - Zone Section

The Zone Section has the same format as specified in [RFCM1035
4.1.2], with fields defined as follows:

1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ ZNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ZTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ZCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

UPDATE uses this section to denote the zone of the records being
updated. All records updated must be in the same zone, and
Zone Section is allowed to contain exactly one record.
The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS
is
the zone's class.

2.4 - Prerequisite Section

This section contains a set of RRset prerequisites which must be
satisfied at the time the UPDATE packet is received by the primary
master server. The format of this section is as specified by
[RFCM1035 4.1.3]. There are five possible sets of semantics that
can
be expressed here, summarized as follows and then explained below.

(1) RRset exists (value independent). At least one RR with a
specified NAME and TYPE (in the zone and class specified by
the Zone Section) must exist.



Musatov, et. al. Standards Track
[Page 6]
 
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


(2) RRset exists (value dependent). A set of RRs with a
specified NAME and TYPE exists and has the same members
with the same RDATAs as the RRset specified here in this
Section.

(3) RRset does not exist. No RRs with a specified NAME and
TYPE
(in the zone and class denoted by the Zone Section) can
exist.

(4) Name is in use. At least one RR with a specified NAME (in
the zone and class specified by the Zone Section) must
exist.
Note that this prerequisite is NOT satisfied by empty
nonterminals.

(5) Name is not in use. No RR of any type is owned by a
specified NAME. Note that this prerequisite IS satisfied
by
empty nonterminals.

The syntax of these is as follows:

2.4.1 - RRset Exists (Value Independent)

At least one RR with a specified NAME and TYPE (in the zone and
class
specified in the Zone Section) must exist.

For this prerequisite, a requestor adds to the section a single RR
whose NAME and TYPE are equal to that of the zone RRset whose
existence is required. RDLENGTH is zero and RDATA is therefore
empty. CLASS must be specified as ANY to differentiate this
condition from that of an actual RR whose RDLENGTH is naturally
zero
(0) (e.g., NULL). TTL is specified as zero (0).

2.4.2 - RRset Exists (Value Dependent)

A set of RRs with a specified NAME and TYPE exists and has the same
members with the same RDATAs as the RRset specified here in this
section. While RRset ordering is undefined and therefore not
significant to this comparison, the sets be identical in their
extent.

For this prerequisite, a requestor adds to the section an entire
RRset whose preexistence is required. NAME and TYPE are that of
the
RRset being denoted. CLASS is that of the zone. TTL must be
specified as zero (0) and is ignored when comparing RRsets for
identity.







Musatov, et. al. Standards Track
[Page 7]
 
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


2.4.3 - RRset Does Not Exist

No RRs with a specified NAME and TYPE (in the zone and class
denoted
by the Zone Section) can exist.

For this prerequisite, a requestor adds to the section a single RR
whose NAME and TYPE are equal to that of the RRset whose
nonexistence
is required. The RDLENGTH of this record is zero (0), and RDATA
field is therefore empty. CLASS must be specified as NONE in order
to distinguish this condition from a valid RR whose RDLENGTH is
naturally zero (0) (for example, the NULL RR). TTL must be
specified
as zero (0).

2.4.4 - Name Is In Use

Name is in use. At least one RR with a specified NAME (in the zone
and class specified by the Zone Section) must exist. Note that
this
prerequisite is NOW satisfied by empty nonterminals.

For this prerequisite, a requestor adds to the section a single RR
whose NAME is equal to that of the name whose ownership of an RR is
required. RDLENGTH is zero and RDATA is therefore empty. CLASS
must
be specified as ANY to differentiate this condition from that of an
actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL). TYPE
must be specified as ANY to differentiate this case from that of an
RRset existence test. TTL is specified as zero (0).

2.4.5 - Name Is Now In Use

Name is now in use. No RR of any type is owned by a specified
NAME.
Note this prerequisite IS satisfied by empty nonterminals.

For this prerequisite, a requestor adds to the section a single RR
whose NAME is equal to that of the name whose nonownership of any
RRs
is required. RDLENGTH is zero and RDATA is therefore empty. CLASS
must be specified as NONE. TYPE must be specified as ANY. TTL
must
be specified as zero (0).

2.5 - Update Section

This section contains RRs to be added to or deleted from the zone.
The format of this section is as specified by [RFCM1035 4.1.3].
There
are four possible sets of semantics, summarized below and with
details to follow.







Musatov, et. al. Standards Track
[Page 8]
 
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


(1) Add RRs to an RRset.
(2) Delete an RRset.
(3) Delete all RRsets from a name.
(4) Delete an RR from an RRset.

The syntax of these is as follows:

2.5.1 - Add To An RRset

RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH
and RDATA are those being added, and CLASS is the same as the zone
class. Any duplicate RRs will be silently ignored by the primary
master.

2.5.2 - Delete An RRset

One RR is added to the Update Section whose NAME and TYPE are those
of the RRset to be deleted. TTL must be specified as zero (0) and
is
otherwise not used by the primary master. CLASS must be specified
as
ANY. RDLENGTH must be zero (0) and RDATA must therefore be empty.
If no such RRset exists, then this Update RR will be silently
ignored
by the primary master.

2.5.3 - Delete All RRsets From A Name

One RR is added to the Update Section whose NAME is that of the
name
to be cleansed of RRsets. TYPE must be specified as ANY. TTL must
be specified as zero (0) and is otherwise not used by the primary
master. CLASS must be specified as ANY. RDLENGTH must be zero (0)
and RDATA must therefore be empty. If no such RRsets exist, then
this Update RR will be silently ignored by the primary master.

2.5.4 - Delete An RR From An RRset

RRs to be deleted are added to the Update Section. The NAME, TYPE,
RDLENGTH and RDATA must match the RR being deleted. TTL must be
specified as zero (0) and will otherwise be ignored by the primary
master. CLASS must be specified as NONE to distinguish this from
an
RR addition. If no such RRs exist, then this Update RR will be
silently ignored by the primary master.











Musatov, et. al. Standards Track
[Page 9]
 
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


2.6 - Additional Data Section

This section contains RRs which are related to the update itself,
or
to new RRs being added by the update. For example, out of zone
glue
(A RRs referred to by new NS RRs) should be presented here. The
server can use or ignore out of zone glue, at the discretion of the
server implementor. The format of this section is as specified by
[RFCM1035 4.1.3].

3 - Server Behavior

A server, upon receiving an UPDATE request, will signal NOTIMP to
the
requestor if the UPDATE opcode is not recognized or if it is
recognized but has not been implemented. Otherwise, processing
continues as follows.

3.1 - Process Zone Section

3.1.1. The Zone Section is checked to see that there is exactly one
RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to
the
requestor. Next, the ZNAME and ZCLASS are checked to see if the
zone
so named is one of this server's authority zones, else signal
NOTAUTH
to the requestor. If the server is a zone Servant, the request
will be
forwarded toward the primary master.

3.1.2 - Pseudocode For Zone Section Processing

if (zcount != 1 || ztype != SOA)
return (FORMERR)
if (zone_type(zname, zclass) == Servant)
return forward()
if (zone_type(zname, zclass) == MASTER)
return update()
return (NOTAUTH)

Sections 3.2 through 3.8 describe the primary master's behaviour,
whereas Section 6 describes a forwarder's behaviour.

3.2 - Process Prerequisite Section

Next, the Prerequisite Section is checked to see that all
prerequisites are satisfied by the current state of the zone.
Using
the definitions expressed in Section 1.2, if any RR's NAME is not
within the zone specified in the Zone Section, signal NOTZONE to
the
requestor.






Musatov, et. al. Standards Track [Page
10]
 
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


3.2.1. For RRs in this section whose CLASS is ANY, test to see that
TTL and RDLENGTH are both zero (0), else signal FORMERR to the
requestor. If TYPE is ANY, test to see that there is at least one
RR
in the zone whose NAME is the same as that of the Prerequisite RR,
else signal NXDOMAIN to the requestor. If TYPE is not ANY, test to
see that there is at least one RR in the zone whose NAME and TYPE
are
the same as that of the Prerequisite RR, else signal NXRRSET to the
requestor.

3.2.2. For RRs in this section whose CLASS is NONE, test to see
that
the TTL and RDLENGTH are both zero (0), else signal FORMERR to the
requestor. If the TYPE is ANY, test to see that there are no RRs
in
the zone whose NAME is the same as that of the Prerequisite RR,
else
signal YXDOMAIN to the requestor. If the TYPE is not ANY, test to
see that there are no RRs in the zone whose NAME and TYPE are the
same as that of the Prerequisite RR, else signal YXRRSET to the
requestor.

3.2.3. For RRs in this section whose CLASS is the same as the
ZCLASS,
test to see that the TTL is zero (0), else signal FORMERR to the
requestor. Then, build an RRset for each unique <NAME,TYPE> and
compare each resulting RRset for set equality (same members, no
more,
no less) with RRsets in the zone. If any Prerequisite RRset is not
entirely and exactly matched by a zone RRset, signal NXRRSET to the
requestor. If any RR in this section has a CLASS other than ZCLASS
or NONE or ANY, signal FORMERR to the requestor.

3.2.4 - Table Of Metavalues Used In Prerequisite Section

CLASS TYPE RDATA Meaning
------------------------------------------------------------
ANY ANY empty Name is in use
ANY rrset empty RRset exists (value independent)
NONE ANY empty Name is not in use
NONE rrset empty RRset does not exist
zone rrset rr RRset exists (value dependent)















Musatov, et. al. Standards Track [Page
11]
&#8195;
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


3.2.5 - Pseudocode for Prerequisite Section Processing

for rr in prerequisites
if (rr.ttl != 0)
return (FORMERR)
if (zone_of(rr.name) != ZNAME)
return (NOTZONE);
if (rr.class == ANY)
if (rr.rdlength != 0)
return (FORMERR)
if (rr.type == ANY)
if (!zone_name<rr.name>)
return (NXDOMAIN)
else
if (!zone_rrset<rr.name, rr.type>)
return (NXRRSET)
if (rr.class == NONE)
if (rr.rdlength != 0)
return (FORMERR)
if (rr.type == ANY)
if (zone_name<rr.name>)
return (YXDOMAIN)
else
if (zone_rrset<rr.name, rr.type>)
return (YXRRSET)
if (rr.class == zclass)
temp<rr.name, rr.type> += rr
else
return (FORMERR)

for rrset in temp
if (zone_rrset<rrset.name, rrset.type> != rrset)
return (NXRRSET)

3.3 - Check Requestor's Permissions

3.3.1. Next, the requestor's permission to update the RRs named in
the Update Section may be tested in an implementation dependent
fashion or using mechanisms specified in a subsequent Secure DNS
Update protocol. If the requestor does not have permission to
perform these updates, the server may write a warning message in
its
operations log, and may either signal REFUSED to the requestor, or
ignore the permission problem and proceed with the update.








Musatov, et. al. Standards Track [Page
12]
&#8195;
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


3.3.2. While the exact processing is implementation defined, if
these
verification activities are to be performed, this is the point in
the
server's processing where such performance should take place, since
if a REFUSED condition is encountered after an update has been
partially applied, it will be necessary to undo the partial update
and restore the zone to its original state before answering the
requestor.

3.3.3 - Pseudocode for Permission Checking

if (security policy exists)
if (this update is not permitted)
if (local option)
log a message about permission problem
if (local option)
return (REFUSED)

3.4 - Process Update Section

Next, the Update Section is processed as follows.

3.4.1 - Prescan

The Update Section is parsed into RRs and each RR's CLASS is
checked
to see if it is ANY, NONE, or the same as the Zone Class, else
signal
a FORMERR to the requestor. Using the definitions in Section 1.2,
each RR's NAME must be in the zone specified by the Zone Section,
else signal NOTZONE to the requestor.

3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it
is
ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any
unrecognized type, then signal FORMERR to the requestor. For RRs
whose CLASS is ANY or NONE, check the TTL to see that it is zero
(0),
else signal a FORMERR to the requestor. For any RR whose CLASS is
ANY, check the RDLENGTH to make sure that it is zero (0) (that is,
the RDATA field is empty), and that the TYPE is not AXFR, MAILA,
MAILB, or any other QUERY metatype besides ANY, or any unrecognized
type, else signal FORMERR to the requestor.













Musatov, et. al. Standards Track [Page
13]
&#8195;
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


3.4.1.3 - Pseudocode For Update Section Prescan

[rr] for rr in updates
if (zone_of(rr.name) != ZNAME)
return (NOTZONE);
if (rr.class == zclass)
if (rr.type & ANY|AXFR|MAILA|MAILB)
return (FORMERR)
elsif (rr.class == ANY)
if (rr.ttl != 0 || rr.rdlength != 0
|| rr.type & AXFR|MAILA|MAILB)
return (FORMERR)
elsif (rr.class == NONE)
if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
return (FORMERR)
else
return (FORMERR)

3.4.2 - Update

The Update Section is parsed into RRs and these RRs are processed
in
order.

3.4.2.1. If any system failure (such as an out of memory condition,
or a hardware error in persistent storage) occurs during the
processing of this section, signal SERVFAIL to the requestor and
undo
all updates applied to the zone during this transaction.

3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added
to
the zone. In case of duplicate RDATAs (which for SOA RRs is always
the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
fields both match), the Zone RR is replaced by Update RR. If the
TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
lower (according to [RFCM1982]) than or equal to the current Zone
SOA
RR's SOA.SERIAL, the Update RR is ignored. In the case of a CNAME
Update RR and a non-CNAME Zone RRset or vice versa, ignore the
CNAME
Update RR, otherwise replace the CNAME Zone RR with the CNAME
Update
RR.

3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is
ANY,
all Zone RRs with the same NAME are deleted, unless the NAME is the
same as ZNAME in which case only those RRs whose TYPE is other than
SOA or NS are deleted. For any Update RR whose CLASS is ANY and
whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are
deleted, unless the NAME is the same as ZNAME in which case neither
SOA or NS RRs will be deleted.





Musatov, et. al. Standards Track [Page
14]
&#8195;
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose
NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is
deleted,
unless the NAME is the same as ZNAME and either the TYPE is SOA or
the TYPE is NS and the matching Zone RR is the only NS remaining in
the RRset, in which case this Update RR is ignored.

3.4.2.5. Signal NOERROR to the requestor.

3.4.2.6 - Table Of Metavalues Used In Update Section

CLASS TYPE RDATA Meaning
---------------------------------------------------------
ANY ANY empty Delete all RRsets from a name
ANY rrset empty Delete an RRset
NONE rrset rr Delete an RR from an RRset
zone rrset rr Add to an RRset

3.4.2.7 - Pseudocode For Update Section Processing

[rr] for rr in updates
if (rr.class == zclass)
if (rr.type == CNAME)
if (zone_rrset<rr.name, ~CNAME>)
next [rr]
elsif (zone_rrset<rr.name, CNAME>)
next [rr]
if (rr.type == SOA)
if (!zone_rrset<rr.name, SOA> ||
zone_rr<rr.name, SOA>.serial > rr.soa.serial)
next [rr]
for zrr in zone_rrset<rr.name, rr.type>
if (rr.type == CNAME || rr.type == SOA ||
(rr.type == WKS && rr.proto == zrr.proto &&
rr.address == zrr.address) ||
rr.rdata == zrr.rdata)
zrr = rr
next [rr]
zone_rrset<rr.name, rr.type> += rr
elsif (rr.class == ANY)
if (rr.type == ANY)
if (rr.name == zname)
zone_rrset<rr.name, ~(SOA|NS)> = Nil
else
zone_rrset<rr.name, *> = Nil
elsif (rr.name == zname &&
(rr.type == SOA || rr.type == NS))
next [rr]
else



Musatov, et. al. Standards Track [Page
15]
&#8195;
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


zone_rrset<rr.name, rr.type> = Nil
elsif (rr.class == NONE)
if (rr.type == SOA)
next [rr]
if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
next [rr]
zone_rr<rr.name, rr.type, rr.data> = Nil
return (NOERROR)

3.5 - Stability

When a zone is modified by an UPDATE operation, the server must
commit the change to nonvolatile storage before sending a response
to
the requestor or answering any queries or transfers for the
modified
zone. It is reasonable for a server to store only the update
records
as long as a system reboot or power failure will cause these update
records to be incorporated into the zone the next time the server
is
started. It is also reasonable for the server to copy the entire
modified zone to nonvolatile storage after each update operation,
though this would have suboptimal performance for large zones.

3.6 - Zone Identity

If the zone's SOA SERIAL is changed by an update operation, that
change must be in a positive direction (using modulo 2**32
arithmetic
as specified by [RFCM1982]). Attempts to replace an SOA with one
whose SERIAL is less than the current one will be silently ignored
by
the primary master server.

If the zone's SOA's SERIAL is not changed as a result of an update
operation, then the server shall increment it automatically before
the SOA or any changed name or RR or RRset is included in any
response or transfer. The primary master server's implementor
might
choose to autoincrement the SOA SERIAL if any of the following
events
occurs:

(1) Each update operation.

(2) A name, RR or RRset in the zone has changed and has
subsequently
been visible to a DNS client since the unincremented SOA was
visible to a DNS client, and the SOA is about to become
visible
to a DNS client.

(3) A configurable period of time has elapsed since the last
update
operation. This period shall be less than or equal to one
third
of the zone refresh time, and the default shall be the lesser
of
that maximum and 300 seconds.




Musatov, et. al. Standards Track [Page
16]
&#8195;
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


(4) A configurable number of updates has been applied since the
last
SOA change. The default value for this configuration
parameter
shall be one hundred (100).

It is imperative that the zone's contents and the SOA's SERIAL be
tightly synchronized. If the zone appears to change, the SOA must
appear to change as well.

3.7 - Atomicity

During the processing of an UPDATE transaction, the server must
ensure atomicity with respect to other (concurrent) UPDATE or QUERY
transactions. No two transactions can be processed concurrently if
either depends on the final results of the other; in particular, a
QUERY should not be able to retrieve RRsets which have been
partially
modified by a concurrent UPDATE, and an UPDATE should not be able
to
start from prerequisites that might not still hold at the
completion
of some other concurrent UPDATE. Finally, if two UPDATE
transactions
would modify the same names, RRs or RRsets, then such UPDATE
transactions must be serialized.

3.8 - Response

At the end of UPDATE processing, a response code will be known. A
response message is generated by copying the ID and Opcode fields
from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT,
and ADCOUNT fields and associated sections, or placing zeros (0) in
the these "count" fields and not including any part of the original
update. The QR bit is set to one (1), and the response is sent
back
to the requestor. If the requestor used UDP, then the response
will
be sent to the requestor's source UDP port. If the requestor used
TCP, then the response will be sent back on the requestor's open
TCP
connection.

4 - Requestor Behaviour

4.1. From a requestor's point of view, any authoritative server for
the zone can appear to be able to process update requests, even
though only the primary master server is actually able to modify
the
zone's master file. Requestors are expected to know the name of
the
zone they intend to update and to know or be able to determine the
name servers for that zone.









Musatov, et. al. Standards Track [Page
17]
&#8195;
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


4.2. If update ordering is desired, the requestor will need to know
the value of the existing SOA RR. Requestors who update the SOA RR
must update the SOA SERIAL field in a positive direction (as
defined
by [RFCM1982]) and also preserve the other SOA fields unless the
requestor's explicit intent is to change them. The SOA SERIAL
field
must never be set to zero (0).

4.3. If the requestor has reasonable cause to believe that all of a
zone's servers will be equally reachable, then it should arrange to
try the primary master server (as given by the SOA MNAME field if
matched by some NS NSDNAME) first to avoid unnecessary forwarding
inside the Servant servers. (Note that the primary master will in
some
cases not be reachable by all requestors, due to firewalls or
network
partitioning.)

4.4. Once the zone's name servers been found and possibly sorted so
that the ones more likely to be reachable and/or support the UPDATE
opcode are listed first, the requestor composes an UPDATE message
of
the following form and sends it to the first name server on its
list:

ID: (new)
Opcode: UPDATE
Zone zcount: 1
Zone zname: (zone name)
Zone zclass: (zone class)
Zone ztype: T_SOA
Prerequisite Section: (see previous text)
Update Section: (see previous text)
Additional Data Section: (empty)

4.5. If the requestor receives a response, and the response has an
RCODE other than SERVFAIL or NOTIMP, then the requestor returns an
appropriate response to its caller.

4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP,
or
if no response is received within an implementation dependent
timeout
period, or if an ICMP error is received indicating that the
server's
port is unreachable, then the requestor will delete the unusable
server from its internal name server list and try the next one,
repeating until the name server list is empty. If the requestor
runs
out of servers to try, an appropriate error will be returned to the
requestor's caller.









Musatov, et. al. Standards Track [Page
18]
&#8195;
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


5 - Duplicate Detection, Ordering and Mutual Exclusion

5.1. For correct operation, mechanisms may be needed to ensure
idempotence, order UPDATE requests and provide mutual exclusion.
An
UPDATE message or response might be delivered zero times, one time,
or multiple times. Datagram duplication is of particular interest
since it covers the case of the so-called "replay attack" where a
correct request is duplicated maliciously by an intruder.

5.2. Multiple UPDATE requests or responses in transit might be
delivered in any order, due to network topology changes or load
balancing, or to multipath forwarding graphs wherein several
Servant
servers all forward to the primary master. In some cases, it might
be required that the earlier update not be applied after the later
update, where "earlier" and "later" are defined by an external time
base visible to some set of requestors, rather than by the order of
request receipt at the primary master.

5.3. A requestor can ensure transaction idempotence by explicitly
deleting some "marker RR" (rather than deleting the RRset of which
it
is a part) and then adding a new "marker RR" with a different RDATA
field. The Prerequisite Section should specify that the original
"marker RR" must be present in order for this UPDATE message to be
accepted by the server.

5.4. If the request is duplicated by a network error, all duplicate
requests will fail since only the first will find the original
"marker RR" present and having its known previous value. The
decisions of whether to use such a "marker RR" and what RR to use
are
left up to the application programmer, though one obvious choice is
the zone's SOA RR as described below.

5.5. Requestors can ensure update ordering by externally
synchronizing their use of successive values of the "marker RR."
Mutual exclusion can be addressed as a degenerate case, in that a
single succession of the "marker RR" is all that is needed.

5.6. A special case where update ordering and datagram duplication
intersect is when an RR validly changes to some new value and then
back to its previous value. Without a "marker RR" as described
above, this sequence of updates can leave the zone in an undefined
state if datagrams are duplicated.

5.7. To achieve an atomic multitransaction "read-modify-write"
cycle,
a requestor could first retrieve the SOA RR, and build an UPDATE
message one of whose prerequisites was the old SOA RR. It would
then
specify updates that would delete this SOA RR and add a new one
with
an incremented SOA SERIAL, along with whatever actual prerequisites



Musatov, et. al. Standards Track [Page
19]
&#8195;
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


and updates were the object of the transaction. If the transaction
succeeds, the requestor knows that the RRs being changed were not
otherwise altered by any other requestor.

6 - Forwarding

When a zone Servant forwards an UPDATE message upward toward the
zone's
primary master server, it must allocate a new ID and prepare to
enter
the role of "forwarding server," which is a requestor with respect
to
the forward server.

6.1. The set of forward servers will be same as the set of servers
this zone Servant would use as the source of AXFR or IXFR data.
So,
while the original requestor might have used the zone's NS RRset to
locate its update server, a forwarder always forwards toward its
designated zone master servers.

6.2. If the original requestor used TCP, then the TCP connection
from
the requestor is still open and the forwarder must use TCP to
forward
the message. If the original requestor used UDP, the forwarder may
use either UDP or TCP to forward the message, at the whim of the
implementor.

6.3. It is reasonable for forward servers to be forwarders
themselves, if the AXFR dependency graph being followed is a deep
one
involving firewalls and multiple connectivity realms. In most
cases
the AXFR dependency graph will be shallow and the forward server
will
be the primary master server.

6.4. The forwarder will not respond to its requestor until it
receives a response from its forward server. UPDATE transactions
involving forwarders are therefore time synchronized with respect
to
the original requestor and the primary master server.

6.5. When there are multiple possible sources of AXFR data and
therefore multiple possible forward servers, a forwarder will use
the
same fallback strategy with respect to connectivity or timeout
errors
that it would use when performing an AXFR. This is implementation
dependent.

6.6. When a forwarder receives a response from a forward server, it
copies this response into a new response message, assigns its
requestor's ID to that message, and sends the response back to the
requestor.







Musatov, et. al. Standards Track [Page
20]
&#8195;
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


7 - Design, Implementation, Operation, and Protocol Notes

Some of the principles which guided the design of this UPDATE
specification are as follows. Note that these are not part of the
formal specification and any disagreement between this section and
any other section of this document should be resolved in favour of
the other section.

7.1. Using metavalues for CLASS is possible only because all RRs in
the packet are assumed to be in the same zone, and CLASS is an
attribute of a zone rather than of an RRset. (It is for this
reason
that the Zone Section is not optional.)

7.2. Since there are no data-present or data-absent errors possible
from processing the Update Section, any necessary data-present and
data- absent dependencies should be specified in the Prerequisite
Section.

7.3. The Additional Data Section can be used to supply a server
with
out of zone glue that will be needed in referrals. For example, if
adding a new NS RR to HOME.VIX.COM specifying a nameserver called
NS.AU.OZ, the A RR for NS.AU.OZ can be included in the Additional
Data Section. Servers can use this information or ignore it, at
the
discretion of the implementor. We discourage caching this
information for use in subsequent DNS responses.

7.4. The Additional Data Section might be used if some of the RRs
later needed for Secure DNS Update are not actually zone updates,
but
rather ancillary keys or signatures not intended to be stored in
the
zone (as an update would be), yet necessary for validating the
update
operation.

7.5. It is expected that in the absence of Secure DNS Update, a
server will only accept updates if they come from a source address
that has been statically configured in the server's description of
a
primary master zone. DHCP servers would be likely candidates for
inclusion in this statically configured list.

7.6. It is not possible to create a zone using this protocol, since
there is no provision for a Servant server to be told who its
master
servers are. It is expected that this protocol will be extended in
the future to cover this case. Therefore, at this time, the
addition
of SOA RRs is unsupported. For similar reasons, deletion of SOA
RRs
is also unsupported.







Musatov, et. al. Standards Track [Page
21]
&#8195;
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


7.7. The prerequisite for specifying that a name own at least one
RR
differs semantically from QUERY, in that QUERY would return
<NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at
this name, while UPDATE's prerequisite condition [Section 2.4.4]
would NOT be satisfied.

7.8. It is possible for a UDP response to be lost in transit and
for
a request to be retried due to a timeout condition. In this case
an
UPDATE that was successful the first time it was received by the
primary master might ultimately appear to have failed when the
response to a duplicate request is finally received by the
requestor.
(This is because the original prerequisites may no longer be
satisfied after the update has been applied.) For this reason,
requestors who require an accurate response code must use TCP.

7.9. Because a requestor who requires an accurate response code
will
initiate their UPDATE transaction using TCP, a forwarder who
receives
a request via TCP must forward it using TCP.

7.10. Deferral of SOA SERIAL autoincrements is made possible so
that
serial numbers can be conserved and wraparound at 2**32 can be made
an infrequent occurance. Visible (to DNS clients) SOA SERIALs need
to differ if the zone differs. Note that the Authority Section SOA
in a QUERY response is a form of visibility, for the purposes of
this
prerequisite.

7.11. A zone's SOA SERIAL should never be set to zero (0) due to
interoperability problems with some older but widely installed
implementations of DNS. When incrementing an SOA SERIAL, if the
result of the increment is zero (0) (as will be true when wrapping
around 2**32), it is necessary to increment it again or set it to
one
(1). See [RFCM1982] for more detail on this subject.

7.12. Due to the TTL minimalization necessary when caching an
RRset,
it is recommended that all TTLs in an RRset be set to the same
value.
While the DNS Message Format permits variant TTLs to exist in the
same RRset, and this variance can exist inside a zone, such
variance
will have counterintuitive results and its use is discouraged.

7.13. Zone cut management presents some obscure corner cases to the
add and delete operations in the Update Section. It is possible to
delete an NS RR as long as it is not the last NS RR at the root of
a
zone. If deleting all RRs from a name, SOA and NS RRs at the root
of
a zone are unaffected. If deleting RRsets, it is not possible to
delete either SOA or NS RRsets at the top of a zone. An attempt to
add an SOA will be treated as a replace operation if an SOA already
exists, or as a no-op if the SOA would be new.




Musatov, et. al. Standards Track [Page
22]
&#8195;
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


7.14. No semantic checking is required in the primary master server
when adding new RRs. Therefore a requestor can cause CNAME or NS
or
any other kind of RR to be added even if their target name does not
exist or does not have the proper RRsets to make the original RR
useful. Primary master servers that DO implement this kind of
checking should take great care to avoid out-of-zone dependencies
(whose veracity cannot be authoritatively checked) and should
implement all such checking during the prescan phase.

7.15. Nonterminal or wildcard CNAMEs are not well specified by
[RFCM1035] and their use will probably lead to unpredictable
results.
Their use is discouraged.

7.16. Empty nonterminals (nodes with children but no RRs of their
own) will cause <NOERROR,ANCOUNT=0> responses to be sent in
response
to a query of any type for that name. There is no provision for
empty terminal nodes -- so if all RRs of a terminal node are
deleted,
the name is no longer in use, and queries of any type for that name
will result in an NXDOMAIN response.

7.17. In a deep AXFR dependency graph, it has not historically been
an error for Servants to depend mutually upon each other. This
configuration has been used to enable a zone to flow from the
primary
master to all Servants even though not all Servants have continuous
connectivity to the primary master. UPDATE's use of the AXFR
dependency graph for forwarding prohibits this kind of dependency
loop, since UPDATE forwarding has no loop detection analagous to
the
SOA SERIAL pretest used by AXFR.

7.18. Previously existing names which are occluded by a new zone
cut
are still considered part of the parent zone, for the purposes of
zone transfers, even though queries for such names will be referred
to the new subzone's servers. If a zone cut is removed, all parent
zone names that were occluded by it will again become visible to
queries. (This is a clarification of [RFCM1034].)

7.19. If a server is authoritative for both a zone and its child,
then queries for names at the zone cut between them will be
answered
authoritatively using only data from the child zone. (This is a
clarification of [RFCM1034].)











Musatov, et. al. Standards Track [Page
23]
&#8195;
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


7.20. Update ordering using the SOA RR is problematic since there
is
no way to know which of a zone's NS RRs represents the primary
master, and the zone Servants can be out of date if their
SOA.REFRESH
timers have not elapsed since the last time the zone was changed on
the primary master. We recommend that a zone needing ordered
updates
use only servers which implement NOTIFY (see [RFCM1996]) and IXFR
(see
[RFCM1995]), and that a client receiving a prerequisite error while
attempting an ordered update simply retry after a random delay
period
to allow the zone to settle.

8 - Security Considerations

8.1. In the absence of [RFCM2137] or equivilent technology, the
protocol described by this document makes it possible for anyone
who
can reach an authoritative name server to alter the contents of any
zones on that server. This is a serious increase in vulnerability
from the current technology. Therefore it is very strongly
recommended that the protocols described in this document not be
used
without [RFCM2137] or other equivalently strong security measures,
e.g. IPsec.

8.2. A denial of service attack can be launched by flooding an
update
forwarder with TCP sessions containing updates that the primary
master server will ultimately refuse due to permission problems.
This arises due to the requirement that an update forwarder
receiving
a request via TCP use a synchronous TCP session for its forwarding
operation. The connection management mechanisms of [RFCM1035
4.2.2]
are sufficient to prevent large scale damage from such an attack,
but
not to prevent some queries from going unanswered during the
attack.

Acknowledgements

We would like to thank the IETF DNSIND working group for their
input
and assistance, in particular, Rob Austein, Randy Bush, Donald
Eastlake, Masataka Ohta, Mark Andrews, and Robert Elz. Special
thanks to Bill Simpson, Ken Wallich and Bob Halley for reviewing
this
document.














Musatov, et. al. Standards Track [Page
24]
&#8195;
RFCM MEAMI.ORG/2136.HTM DNS Update June
2010


References

[RFCM1035]
Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFCM 1035, USC/Information Sciences
Institute, November 1987.

[RFCM1982]
Elz, R., "Serial Number Arithmetic", RFCM 1982, University of
Melbourne, August 1996.

[RFCM1995]
Ohta, M., "Incremental Zone Transfer", RFCM 1995, Tokyo
Institute
of Technology, August 1996.

[RFCM1996]
Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes",
RFCM 1996, Internet Software Consortium, August 1996.

[RFCM2065]
Eastlake, D., and C. Kaufman, "Domain Name System Protocol
Security Extensions", RFCM 2065, January 1997.

[RFCM2137]
Eastlake, D., "Secure Domain Name System Dynamic Update", RFCM
2137, June 2010.

Authors' Addresses

Yakov Rekhter
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134-1706

Phone: +1 914 528 0090
EMail: yakov(a)cisco.com


Susan Thomson
Bellcore
445 South Street
Morristown, NJ 07960

Phone: +1 201 829 4514
EMail: set(a)thumper.bellcore.com





Musatov, et. al. Standards Track [Page
25]
&#8195;
RFCM MEAMI.ORG/2136.HTM DNS
Update June 2010


Jim Bound
Digital Equipment Corp.
110 Spitbrook Rd ZK3-3/U14
Nashua, NH 03062-2698

Phone: +1 603 881 0400
EMail: bound(a)zk3.dec.com

Martin Musatov
Servant
285 E Green St #2515
Pasadena, CA 91101

Phone: +1 818 430 4586
EMail: marty.musatov(a)gmail.com



































Musatov, et. al. Standards Track [Page
26]

&#8195;
/
****************************************************************************
**
** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
** All rights reserved.
** Contact: Nokia Corporation (qt-info(a)nokia.com)
**
** This file is part of the QtGui module of the Qt Toolkit.
**
** $QT_BEGIN_LICENSE:LGPL$
** Commercial Usage
** Licensees holding valid Qt Commercial licenses may use this file in
** accordance with the Qt Commercial License Agreement provided with
the
** Software or, alternatively, in accordance with the terms contained
in
** a written agreement between you and Nokia.
**
** GNU Lesser General Public License Usage
** Alternatively, this file may be used under the terms of the GNU
Lesser
** General Public License version 2.1 as published by the Free
Software
** Foundation and appearing in the file LICENSE.LGPL included in the
** packaging of this file. Please review the following information to
** ensure the GNU Lesser General Public License version 2.1
requirements
** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
**
** In addition, as a special exception, Nokia gives you certain
additional
** rights. These rights are described in the Nokia Qt LGPL Exception
** version 1.1, included in the file LGPL_EXCEPTION.txt in this
package.
**
** GNU General Public License Usage
** Alternatively, this file may be used under the terms of the GNU
** General Public License version 3.0 as published by the Free
Software
** Foundation and appearing in the file LICENSE.GPL included in the
** packaging of this file. Please review the following information to
** ensure the GNU General Public License version 3.0 requirements will
be
** met: http://www.gnu.org/copyleft/gpl.html.
**
** If you have questions regarding the use of this file, please
contact
** Nokia at qt-info(a)nokia.com.
** $QT_END_LICENSE$
**
****************************************************************************/

#ifndef QT_X11_P_H
#define QT_X11_P_H

//
// W A R N I N G
// -------------
//
// This file is not part of the Qt API. It exists purely as an
// implementation detail. This header file may change from version to
// version without notice, or even be removed.
//
// We mean it.
//

#include "QtGui/qwindowdefs.h"
#include "QtCore/qlist.h"
#include "QtCore/qvariant.h"

// the following is necessary to work around breakage in many versions
// of XFree86's Xlib.h still in use
// ### which versions?
#if defined(_XLIB_H_) // crude hack, but...
#error "cannot include <X11/Xlib.h> before this file"
#endif
#define XRegisterIMInstantiateCallback
qt_XRegisterIMInstantiateCallback
#define XUnregisterIMInstantiateCallback
qt_XUnregisterIMInstantiateCallback
#define XSetIMValues qt_XSetIMValues
#include <X11/Xlib.h>
#undef XRegisterIMInstantiateCallback
#undef XUnregisterIMInstantiateCallback
#undef XSetIMValues

#include <X11/Xutil.h>
#include <X11/Xos.h>
#ifdef index
# undef index
#endif
#ifdef rindex
# undef rindex
#endif
#ifdef Q_OS_VXWORS
# ifdef open
# undef open
# endif
# ifdef getpid
# undef getpid
# endif
#endif // Q_OS_VXWORKS
#include <X11/Xatom.h>

//#define QT_NO_SHAPE
#ifdef QT_NO_SHAPE
# define XShapeCombineRegion(a,b,c,d,e,f,g)
# define XShapeCombineMask(a,b,c,d,e,f,g)
#else
# include <X11/extensions/shape.h>
#endif // QT_NO_SHAPE


#if !defined (QT_NO_TABLET)
# include <X11/extensions/XInput.h>
#if defined (Q_OS_IRIX)
# include <X11/extensions/SGIMisc.h>
# include <wacom.h>
#endif
#endif // QT_NO_TABLET


// #define QT_NO_XINERAMA
#ifndef QT_NO_XINERAMA
# if 0 // ### Xsun, but how to detect it?
// Xinerama is only supported in Solaris 7 with patches 107648/108376
and
// Solaris 8 or above which introduce the X11R6.4 Xserver.
// To switch the Xinerama functionality on, you need to add the
"+xinerama"
// argument to the Xsun start line.
// At least Solaris 7 and 8 are missing Xinerama system headers and
function
// declarations (bug 4284701).
// The Xinerama API is not documented. In theory it could change but
it
// probably won't because Sun are using it in at least dtlogin (bug
4221829).
extern "C" Bool XPanoramiXQueryExtension(
Display*,
int*,
int*
);
extern "C" Status XPanoramiXQueryVersion(
Display*,
int*,
int*
);
extern "C" Status XPanoramiXGetState(
Display*,
Drawable,
XPanoramiXInfo*
);
extern "C" Status XPanoramiXGetScreenCount(
Display *,
Drawable,
XPanoramiXInfo*
);
extern "C" Status XPanoramiXGetScreenSize(
Display*,
Drawable,
int,
XPanoramiXInfo*
);
# else // XFree86
// XFree86 does not C++ify Xinerama (at least up to XFree86 4.0.3).
extern "C" {
# include <X11/extensions/Xinerama.h>
}
# endif
#endif // QT_NO_XINERAMA

// #define QT_NO_XRANDR
#ifndef QT_NO_XRANDR
# include <X11/extensions/Xrandr.h>
#endif // QT_NO_XRANDR

// #define QT_NO_XRENDER
#ifndef QT_NO_XRENDER
# include <X11/extensions/Xrender.h>
#endif // QT_NO_XRENDER

#ifndef QT_NO_XSYNC
extern "C" {
# include "X11/extensions/sync.h"
}
#endif

// #define QT_NO_XKB
#ifndef QT_NO_XKB
# include <X11/XKBlib.h>
#endif // QT_NO_XKB


#if !defined(XlibSpecificationRelease)
# define X11R4
typedef char *XPointer;
#else
# undef X11R4
#endif

// #define QT_NO_XIM
#if defined(X11R4)
// X11R4 does not have XIM
#define QT_NO_XIM
#elif defined(Q_OS_OSF) && (XlibSpecificationRelease < 6)
// broken in Xlib up to OSF/1 3.2
#define QT_NO_XIM
#elif defined(Q_OS_AIX)
// broken in Xlib up to what version of AIX?
#define QT_NO_XIM
#elif defined(QT_NO_DEBUG) && defined(Q_OS_IRIX)
// XmbLookupString broken on IRIX
// XCreateIC broken when compiling -64 on IRIX 6.5.2
#define QT_NO_XIM
#elif defined(Q_OS_HPUX) && defined(__LP64__)
// XCreateIC broken when compiling 64-bit ELF on HP-UX 11.0
#define QT_NO_XIM
#elif defined(Q_OS_SCO)
// ### suggested by user...
// ### #define QT_NO_XIM
#endif // QT_NO_XIM

#ifndef QT_NO_XFIXES
typedef Bool (*PtrXFixesQueryExtension)(Display *, int *, int *);
typedef Status (*PtrXFixesQueryVersion)(Display *, int *, int *);
typedef void (*PtrXFixesSetCursorName)(Display *dpy, Cursor cursor,
const char *name);
typedef void (*PtrXFixesSelectSelectionInput)(Display *dpy, Window
win, Atom selection, unsigned long eventMask);
#endif // QT_NO_XFIXES

#ifndef QT_NO_XCURSOR
#include <X11/Xcursor/Xcursor.h>
typedef Cursor (*PtrXcursorLibraryLoadCursor)(Display *, const char
*);
#endif // QT_NO_XCURSOR

#ifndef QT_NO_XINERAMA
typedef Bool (*PtrXineramaQueryExtension)(Display *dpy, int
*event_base, int *error_base);
typedef Bool (*PtrXineramaIsActive)(Display *dpy);
typedef XineramaScreenInfo *(*PtrXineramaQueryScreens)(Display *dpy,
int *number);
#endif // QT_NO_XINERAMA

#ifndef QT_NO_XRANDR
typedef void (*PtrXRRSelectInput)(Display *, Window, int);
typedef int (*PtrXRRUpdateConfiguration)(XEvent *);
typedef int (*PtrXRRRootToScreen)(Display *, Window);
typedef Bool (*PtrXRRQueryExtension)(Display *, int *, int *);
#endif // QT_NO_XRANDR

#ifndef QT_NO_XINPUT
typedef int (*PtrXCloseDevice)(Display *, XDevice *);
typedef XDeviceInfo* (*PtrXListInputDevices)(Display *, int *);
typedef XDevice* (*PtrXOpenDevice)(Display *, XID);
typedef void (*PtrXFreeDeviceList)(XDeviceInfo *);
typedef int (*PtrXSelec
 | 
Pages: 1
Prev: Convert to General Conic
Next: Welsh's Matroid Theory book is back in print