draft-ietf-dhc-dns-pd-00.txt   draft-ietf-dhc-dns-pd-01.txt 
Network Working Group T. Lemon Network Working Group T. Lemon
Internet-Draft Nominum Internet-Draft Nominum
Intended status: Standards Track March 11, 2013 Intended status: Standards Track October 21, 2013
Expires: September 12, 2013 Expires: April 24, 2014
Populating the DNS Reverse Tree for DHCP Delegated Prefixes Populating the DNS Reverse Tree for DHCP Delegated Prefixes
draft-ietf-dhc-dns-pd-00.txt draft-ietf-dhc-dns-pd-01.txt
Abstract Abstract
This document describes three alternatives for populating the DNS This document describes three alternatives for populating the DNS
reverse tree for prefixes delegated using DHCP, and provides reverse tree for prefixes delegated using DHCP, and provides
mechanisms for implementing each alternative. mechanisms for implementing each alternative.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2013. This Internet-Draft will expire on April 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 12, line 17 skipping to change at page 12, line 17
... ...
10. Security Considerations 10. Security Considerations
Some ISPs may have concerns about allowing site-managed DNS Some ISPs may have concerns about allowing site-managed DNS
subdelegations for the reverse zone, but this concern is a policy subdelegations for the reverse zone, but this concern is a policy
issue, not a security issue. In the presence of properly agreed-to issue, not a security issue. In the presence of properly agreed-to
terms of service, population of a reverse tree by the end-user is terms of service, population of a reverse tree by the end-user is
simply a value-added service the ISP may or may not choose to simply a value-added service the ISP may or may not choose to
provide. Even in the absence of a legally binding ToS agreement, the provide. Even in the absence of a legally binding ToS agreement, the
worse an end-user could do would be to publish nasty words or bogus worst an end-user could do would be to publish nasty words or bogus
PTR records, neither of which is a security concern. PTR records, neither of which is a security concern.
If an implementation were to fail to follow the advice on validating If an implementation were to fail to follow the advice on validating
authoritative name servers supplied by the requesting router, it authoritative name servers supplied by the requesting router, it
would probably be possible for a coordinated set of requesting would probably be possible for a coordinated set of requesting
routers to perform a DDoS attack on a target by arranging for various routers to perform a DDoS attack on a target by arranging for various
entities on the network to query the reverse tree for one or more of entities on the network to query the reverse tree for one or more of
the IP addresses in the delegated prefix. However, this would the IP addresses in the delegated prefix. However, this would
require, first, that the implementation not follow the specification, require, first, that the implementation not follow the specification,
and second, a fairly complicated setup. In practice, there are and second, a fairly complicated setup. In practice, there are
 End of changes. 4 change blocks. 
5 lines changed or deleted 5 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/