> I think the history of discussion of this document shows that most
> people here agree with the following three statements:
>
> 1 DNS PTR records are entirely optional, and MUST NOT be assumed to
> exist. Software MUST NOT fail or incur delay as a result of the non-
> existance of PTR records.
I disagree with the second sentence. With a one word change,
I might agree with the first sentence, e.g. " DNS records are
entirely optional, and MUST NOT be assumed to exist. " In other
words, applications MUST support address literals.
> 2 Unauthenticated DNS MUST NOT be relied on for security or trust
> decisions. Even when DNSSEC is used to verify the authenticity of
> DNS records, matching reverse and forward records do not imply either
> improved security or trustworthiness over sites that either do not
> have reverse DNS or that do not have matching foward/reverse DNS.
I disagree with this statement. It is false today and will be
false when DNSSEC is used.
> 3 DNS records MUST NOT be used in logs instead of IP addresses.
i disagree with this statement. If one were to change the "MUST NOT"
to a SHOULD NOT, then this might be a reasonable suggestion.
> Logging only the PTR resource records instead of the IP address is
> vulnerable, since attackers may have used long names that will either
> become truncated by many logging systems, or require upto 255 bytes
> to store. Logging both IP address and DNS PTR records may be helpful
> but one must also consider that the 255 byte per record space
> requirement does not become a DOS attack on the logging system.
the example is a sad statement on the support of fully qualified
domain names in syslog and its cousins, regardless of DNS RR used.
A/AAAA/A6 lables are just as prone to length considerations as
PTR lables. Nothing inherently worse w/ PTR lables.
--bill
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
