RFC 1912, Sec 2.1:
" Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all. Also, PTR records must point back to a valid A record, not a alias defined by a CNAME. It is highly recommended that you use some software which automates this checking, or generate your DNS data from a database which automatically creates consistent data."
I have yet to hear a convincing argument why this RFC should be ignored. I have seen many problems when this is ignored.
What about when you're setting up ARPA entries referring to CIDR allocations? as in ... 1.8.5.10.in-addr.arpa. 86400 IN CNAME 1.0/24.8.5.10.in-addr.arpa. Somethings got to give there. I know that you could say well, just put the hostname instead of the target listed above, but the above is often used to delegate ARPA for subnets to downstreams... Karyn
RGDS GARY -------------------------------------------------------------- ------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676
Hi Karyn, rfc2317 (which defines classless reverse) doesn't break it (although it is not explicit on this point) - rfc1912 only requires that the FQHN returned from a PTR record matches an A record. Going the other way - finding the PTR record itself via a CNAME - is not a violation. As an aside, rfc2137 unfortunately *does* allow the final delegate to pollute external resolvers with incorrect SOA records for the octet-boundary parent zone. That's just a typical DNS hazard, of course. -[ Joshua Goodall ]----------------------------------------------- -[ IP Systems Architect ]---------------- Cook, Geek, Lover ------ -[ joshuag@interxion.com ]--------------- joshua@roughtrade.net -- On Fri, 18 Aug 2000, Karyn Ulriksen wrote:
What about when you're setting up ARPA entries referring to CIDR allocations?
as in ...
1.8.5.10.in-addr.arpa. 86400 IN CNAME 1.0/24.8.5.10.in-addr.arpa.
Somethings got to give there. I know that you could say well, just put the hostname instead of the target listed above, but the above is often used to delegate ARPA for subnets to downstreams...
Karyn
RGDS GARY -------------------------------------------------------------- ------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676
[ On Friday, August 18, 2000 at 12:54:30 (-0700), Karyn Ulriksen wrote: ]
Subject: RE: lame delegations
What about when you're setting up ARPA entries referring to CIDR allocations?
as in ...
1.8.5.10.in-addr.arpa. 86400 IN CNAME 1.0/24.8.5.10.in-addr.arpa.
Somethings got to give there. I know that you could say well, just put the hostname instead of the target listed above, but the above is often used to delegate ARPA for subnets to downstreams...
That's not an issue. What RFC-1912 omits from its descriription is the fact that CNAME processing may occur during the retrieval of a PTR, as clarified in RFC-2181: 10.2. PTR records Confusion about canonical names has lead to a belief that a PTR record should have exactly one RR in its RRSet. This is incorrect, the relevant section of RFC1034 (section 3.6.2) indicates that the value of a PTR record should be a canonical name. That is, it should not be an alias. There is no implication in that section that only one PTR record is permitted for a name. No such restriction should be inferred. Note that while the value of a PTR record must not be an alias, there is no requirement that the process of resolving a PTR record not encounter any aliases. The label that is being looked up for a PTR value might have a CNAME record. That is, it might be an alias. The value of that CNAME RR, if not another alias, which it should not be, will give the location where the PTR record is found. That record gives the result of the PTR type lookup. This final result, the value of the PTR RR, is the label which must not be an alias. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
participants (3)
-
Joshua Goodall -
Karyn Ulriksen -
woods＠weird.com