At Fri, 14 Mar 2008 04:45:00 +0100, Peter Koch <[EMAIL PROTECTED]> wrote:
> in accordance with the roadmap posted the other day, this is to initiate > a working group last call on > > "Considerations for the use of DNS Reverse Mapping" > draft-ietf-dnsop-reverse-mapping-considerations-06.txt > > ending Friday, 2008-04-04, 18:00 UTC. > > The document is aimed at a status of "BCP". > Please review the draft and send comments and/or statements of support or > non-support to the WG mailing list. We have taken names of volunteers, > but everyone is encouraged to review. There will be a five reviewer threshold > and _no_ default action. Here are my minor comments on the draft: 1. In Section 1.2 Starting from a given IPv4 address (possibly the result of a query for an A RR), the term "existing reverse data" means that a query for <reversed-ip4-address>.in-addr.arpa. type PTR results in a response other than Name Error. I don't think this definition is 100% appropriate. Consider the case where a PTR RR is not provided for <reversed-ip4-address>.in-addr.arpa but some other type of RR (e.g. TXT) is. Then the response to the PTR query won't be a Name Error, but it wouldn't be reasonable to consider it the existence of reverse data. I'd suggest revising this to: Starting from a given IPv4 address (possibly the result of a query for an A RR), the term "existing reverse data" means that a query for <reversed-ip4-address>.in-addr.arpa. type PTR results in a positive response (i.e,, one that contains a PTR RRset for the queried name in the answer section). Also about the IPv6 case: Starting from a given IPv6 address (possibly the result of a query for an AAAA RR), the term "existing reverse data" means that a query for <reversed-ip6-address>.ip6.arpa. type PTR results in a positive response. And for the definition of "missing reverse data": The term "missing reverse data" means that the query for existing reverse data results in a negative response (i.e., one that does not contain a PTR RRset for the queried name in the answer section, often with a non 0 response code). 2. In Section 2.1 (last line of page 4) attacker could acquire access either by by putting the target host should be attacker could acquire access either by putting the target host --- JINMEI, Tatuya Internet Systems Consortium, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
