"DNS Zone Transfer Protocol (AXFR)", Edward Lewis, 14-Jul-08. ( bytes)
The Domain Name System standard mechanisms for maintaining coherent servers for a zone consist of three elements. One mechanism is the Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035. The definition of AXFR, has proven insufficient in detail, forcing implementations intended to be compliant to make assumptions, impeding interoperability. 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.
"Evaluating DNSSEC Transition Mechanisms", Roy Arends, Peter Koch, Jakob Schlyter, 14-Jul-08. ( bytes)
This document collects and summarizes different proposals for alternative and additional strategies for authenticated denial in DNS responses, evaluates these proposals and gives a recommendation for a way forward. It is a snapshot of the DNSEXT working group discussion of June 2004.
"Clarifications and Implementation Notes for DNSSECbis", Samuel Weiler, David Blacka, 14-Jul-08. ( 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, 14-Jul-08. ( 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, 29-Jul-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, 16-Jul-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 a revision 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 Mook, 14-Aug-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 responses 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 responses. 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
"Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records", Francis Dupont, 30-Jun-08. ( bytes)
The main goal of this document is to deprecate the use of HMAC-MD5 as an algorithm for the TSIG (secret key transaction authentication) resource record in the DNS (domain name system).

IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

Return to Internet-Draft directory.

Return to IETF home page.