25.02.2013 Views

TCP/IP Tutorial and Technical Overview - IBM Redbooks

TCP/IP Tutorial and Technical Overview - IBM Redbooks

TCP/IP Tutorial and Technical Overview - IBM Redbooks

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

456 <strong>TCP</strong>/<strong>IP</strong> <strong>Tutorial</strong> <strong>and</strong> <strong>Technical</strong> <strong>Overview</strong><br />

6 Name error. A name exists when it should not.<br />

7 RRset error. A resource record set exists when it should<br />

not.<br />

8 RRset error. A resource record set specified does not<br />

exist.<br />

9 Zone Authority error. The server is not authoritative for<br />

the zone specified.<br />

10 Zone error. A name specified in the Prerequisite or<br />

Update sections is not in the zone specified.<br />

ZO count The number of RRs in the Zone section.<br />

PR count The number of RRs in the Prerequisite section.<br />

UP count The number of RRs in the Update section.<br />

AD count The number of RRs in the Additional information section.<br />

Zone section This section is used to indicate the zone of the records that are<br />

to be updated. As all records to be updated must belong to the<br />

same zone, the zone section has a single entry specifying the<br />

zone name, zone type (which must be SOA), <strong>and</strong> zone class.<br />

Prerequisite section<br />

This section contains RRs or RRsets that either must, or must<br />

not, exist, depending on the type of update.<br />

Update section This section contains the RRs, RRsets, or both that are to be<br />

added to or deleted from the zone.<br />

Additional information section<br />

This section can be used to pass additional RRs that relate to<br />

the update operation in process.<br />

For further information about the UPDATE message format, refer to RFC 2136.<br />

12.2.2 Incremental zone transfers in DDNS<br />

RFC 1995 introduces the IXFR DNS message type, which allows incremental<br />

transfers of DNS zone data between primary <strong>and</strong> secondary DNS servers. In<br />

other words, when an update has been made to the zone data, only the change<br />

has to be copied to the other DNS servers that maintain a copy of the zone data,<br />

rather than the whole DNS database (as is the case with the AXFR DNS<br />

message type).<br />

The format of an IXFR query is exactly that of a normal DNS query, but with a<br />

query type of IXFR. The response’s answer section, however, is made up of<br />

difference sequences.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!