Re: [Full-disclosure] Reverse dns

[Duo <duo@xxxxxxxxxxxxxxxxxx>]

RFC 2821.

It dosent, AFAIK, use any harsh requirements. But:

3.6 Domains

   Only resolvable, fully-qualified, domain names (FQDNs) are permitted
   when domain names are used in SMTP.  In other words, names that can
   be resolved to MX RRs or A RRs (as discussed in section 5) are
   permitted, as are CNAME RRs whose targets can be resolved, in turn,
   to MX or A RRs.  Local nicknames or unqualified names MUST NOT be
   used.

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.

There are situations where its encouraged, required, or discouraged and 
not wise. It's kind of hard to keep opinion out of it. Sendmail, as we all 
have encountered from time to time, can be a bit more alechemy than actual 
science. At least before the evolution of postfix.

You mention mail, but you also mention tcpdump. Again, id like to 
re-iterate, its difficult to give you an answer, without more detail as to 
what it is you are trying to accomlish.

Just my $0.02. =)

Duo.

On Thu, 10 Mar 2005, Paul Schmehl wrote:

> Is there an RFC *requirement* for reverse dns?
>
> I've been looking through the RFCs and I can't find it.  Some folks think 
> reverse dns should be completely disabled.  I know for sure that this will 
> break email, because many mail servers won't talk to a server that doesn't 
> reverse.  Tcpdump also doesn't like hosts that won't reverse.
>
> What I'm looking for is a standard (RFC) that states that enabling reverse 
> lookups is *required* or reverse lookups are *optional*.  If they're 
> optional, then reverse could be disabled for most hosts.
>
> I'm also looking for a list of things that *break* when you disable reverse 
> (e.g. mail).
>
> RULES FOR RESPONDING:
> 1) "Reverse is a good thing" is not an answer.  Neither is "Reverse is a bad 
> thing".
> 2) Opinions are not useful -  stick to facts only - chapter and verse please.
> 3) All replies to the list please - others will find this useful as well.
>
> Paul Schmehl (pauls@xxxxxxxxxxxx)
> Adjunct Information Security Officer
> The University of Texas at Dallas
> AVIEN Founding Member
> http://www.utdallas.edu
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://www.secunia.com/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://www.secunia.com/