bugtraq - Re: Has anyone implemented "double forward DNS"?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Fri, 05 Sep 2008 11:11:23 +0200
From: Steven Bakker <steven.bakker@...-ix.net>
To: Ansgar -59cobalt- Wiechers <bugtraq@...netcobalt.net>
Cc: bugtraq@...urityfocus.com
Subject: Re: Has anyone implemented "double forward DNS"?

On Thu, 2008-09-04 at 15:34 +0200, Ansgar -59cobalt- Wiechers wrote:

> It was pointed out to me in private that, of course, you can have
> multiple PTR records mapping one address to different names. My bad.
> 
> However, since oftentimes (colocation scenarios for instance) forward
> and reverse zone have different maintainers, it's some hassle to keep
> the reverse zone in sync with the forward zone. Thus I have my doubts
> that proper reverse mappings for every name will become common practice
> anytime soon.

True, but there are other reasons why this is not such hot idea, as
outlined in the IETF draft "Considerations for the use of DNS Reverse
Mapping"[1]:

        3.2 Utility and effectiveness of some reverse mapping uses
        
                Especially in the absence of strong anti-spoofing
                mechanisms, like the DNS Security Extensions, a check
                for matching reverse DNS mapping should be regarded as
                an extremely weak form of authentication. Even
                moderately skilled attackers have available to them
                tools to spoof DNS responses.
                [...]


        3.3 The difficulty with blanket policies
                [...]
                It is possible for there to be multiple PTRs at a single
                reverse tree node.  In extreme cases, these multiple
                PTRs could cause a DNS response to exceed the UDP limit,
                and fall back to TCP or otherwise exceed the DNS
                protocol limits.  Such a case could be one where the
                advantages of reverse mapping are exceeded by the
                disadvantages of the additional burden.  This may be of
                particular significance for "mass virtual hosting"
                systems, where many hostnames are associated with a
                single IP.

Oh, and just as you (and I) until recently thought that there should be
only one PTR for any given address, there is undoubtedly still software
out there that expects <= 1 PTR, so no telling will break (though that
should not be an overriding concern if the security benefits of proper
reverse checking were large enough).

[1] http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06

Cheers,
Steven