"DNS Zone Transfer Protocol (AXFR)", Andreas Gustafsson, 5-Feb-08. ( bytes)

The Domain Name System standard facilities for maintaining coherent servers for a zone consist of three elements. The Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035. The Incremental Zone Transfer (IXFR) is defined in RFC 1995. A mechanism for prompt notification of zone changes (NOTIFY) is defined in RFC 1996. The base definition of these facilities, that of the AXFR, has proven insufficient in detail, resulting in no implementation complying with it. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of the AXFR, new in the sense that is it recording an accurate definition of an interoperable AXFR mechanism.

"Clarifications and Implementation Notes for DNSSECbis", Samuel Weiler, Rob Austein, 18-Nov-07. ( bytes)

This document is a collection of minor technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as an interim repository of DNSSECbis errata.

"Domain Name System (DNS) IANA Considerations", Donald Eastlake 3rd, 9-Aug-07. ( bytes)

Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes.

"Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", Jelte Jansen, 11-Apr-08. ( bytes)

This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).

"Update to DNAME Redirection in the DNS", Scott Rose, Wouter Wijngaards, 2-May-08. ( bytes)

The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is an update of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision.

"Measures for making DNS more resilient against forged answers", Bert Hubert, Remco van Mook, 24-Mar-08. ( bytes)

The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder. Even a cryptographically secured DNS benefits from having the ability to discard bogus answers quickly, as this potentially saves large amounts of computation. By describing certain behaviour that has previously not been standardised, this document sets out how to make the DNS more resilient against accepting incorrect answers. This document updates RFC 1034.

"Revised extension mechanisms for DNS (EDNS0)", Paul Vixie, 17-Mar-08. ( bytes)

The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow.1 - Introduction

"The Modern DNS Implementation Guide", George Michaelson, 20-Jan-08. ( bytes)

A structured catalogue of relevant DNS RFCs is presented with references to the specific normative sections which should be followed in a modern DNS implementation. This document is to be used as guide for DNS implementors, for testing and compliance of DNS software, and to help guide DNS standards' advancement.

Return to Internet-Draft directory.

Return to IETF home page.