full-disclosure - Reverse 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <DA6867447B83D0F626B2D097@utd49554.utdallas.edu>
From: pauls at utdallas.edu (Paul Schmehl)
Subject: Reverse dns

--On Thursday, March 10, 2005 10:39:38 AM -0600 Duo 
<duo@...italarcadia.net> wrote:
>
> Strictly speaking, this may or may not help you. It would help if you
> would describe the scenario/situation you are in. I could comment
> further, but without a bit more specific information, I dont feel I can
> comment properly.
>
I'd prefer not to give details.  I'll give you this much.  We're having a 
philosophical disagreement about the value of disallowing reverse dns for 
hosts on our network.  It's the ancient security by obscurity discussion.

My concern is that we should not disable dns when (or if) it's required. 
Obviously we would not disable it for the MX hosts, but I'm unclear what 
(if anything) the RFC requirements are.  Absent any requirements, there's 
not cogent argument for *not* doing it, with the aforementioned exceptions.

Hopefully that clarifies it a bit.

Some questions that come to mind - what, if anything, is the consequence of 
disabling reverse lookups for your NS servers?  For web servers?  For other 
services?  For workstations?  Etc., etc.

Paul Schmehl (pauls@...allas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu