Re: Reverse Dns Question...is it really necessary or not? - TCP-IP

This is a discussion on Re: Reverse Dns Question...is it really necessary or not? - TCP-IP ; On 22 Jul 2004 22:25:27 -0400, Seth Breidbart, wrote: > >I never really understood why they did that. If they allow anonymous > >uploads, I suppose it might have been an attempt to reduce warez. But > >other than that, ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 28 of 28

Thread: Re: Reverse Dns Question...is it really necessary or not?

  1. Re: Reverse Dns Question...is it really necessary or not?

    On 22 Jul 2004 22:25:27 -0400, Seth Breidbart, wrote:

    > >I never really understood why they did that. If they allow anonymous
    > >uploads, I suppose it might have been an attempt to reduce warez. But
    > >other than that, what problem is it trying to solve?

    >
    > It was once legal to let people download the encryption-enabled
    > versions of programs only if they were in certain countries.
    > So, looking at rDNS and parsing the whois record was a reasonable
    > approximation for the server (enough to keep it from getting busted,
    > which is presumably what they actually cared about).


    ??? A rogue site that has been delegated rDNS ability can give
    itself any rDNS the owner damn well wants. If you really worry about
    the location of a downloader, query the IP address against ARIN.

    I ran into this stupidity a few years ago. I work for the Met
    Service in Canada, in a section dealing with custom data requests. We
    got a request from a researcher at a Canadian university for a bunch of
    data that was definitely too large to send as an email attachment. They
    had a scratch account for receiving uploads, and gave me a temporary
    password for ftp. Damn thing wouldn't work.

    After half a day, their IT people finally realized that the server
    required rDNS on the uploader. So I called one of our IT people, and
    pushed the file over the network to his machine, which had rDNS. He was
    able to push the the data file over to the researcher at the university.

    I back up my home machine twice a month (doesn't everybody?).
    Before CDs became dirt so cheap that I could use them for regular
    backups, I'd...
    1) make a backup, kept on the local machine
    2) copy the tar.bz file over to a backup home machine.

    I used either sshd or ftpd, and noticed that if I didn't have both
    machines defined in /etc/hosts on both machines, the initial connection
    would take approx 30 or 40 seconds, apparently waiting for some name
    lookup to time out. This happened even if I ssh'd or ftp'd to an IP
    address rather than a host name.

    --
    Walter Dnes; my email address is *ALMOST* like wzaltdnes@waltdnes.org
    Delete the "z" to get my real address. If that gets blocked, follow
    the instructions at the end of the 550 message.

  2. Re: Reverse Dns Question...is it really necessary or not?

    BM> IIRC, this really began when the US government prohibited companies
    BM> like Microsoft and Netscape from distributing strong encryption
    BM> to certain foreign countries.

    Did Netscape even exist when this prohibition was first created ?
    hint that the U.S. regulations
    long pre-date the formation of Netscape in 1994.

    BM> So they had to come up with a way to check whether people downloading
    BM> browsers were in the US or not. I don't know if their techniques
    BM> were ever publicized, but it appeared that part of it involved a
    BM> reverse DNS lookup, and then they checked the WHOIS record of
    BM> the domain in the response.

    .... which is strange, really, given that a straight check on the IP
    address range against a local database
    () would have been less
    prone to problems caused by network outages, and equally as (in)accurate.

    A far more prosaic explanation is that the use of address->name lookups
    was simply because people blithely applied TCP Wrappers to their TCP
    services and used domain names in their ACLs. See
    ,
    for example. Indeed, the author of RFC 1912 was touting these as
    "security" measures
    ()
    four years before writing that very document.

    Of course, the use of such non-secure "security" measures *was* there
    because the use of *real* security measures was heavily circumscribed by
    the encryption regulations that you refer to. One cannot berate people
    *then* for using the only avenues that the United State government left
    open for them. (The fact that the only available mechanisms for
    worldwide use weren't actually secure was the idea, after all.)
    However, the situation is quite different *now*, and there is no excuse
    for such foolishness.

  3. Re: Reverse Dns Question...is it really necessary or not?

    BM> I never really understood why they did that. If they allow
    BM> anonymous uploads, I suppose it might have been an attempt
    BM> to reduce warez. But other than that, what problem is it
    BM> trying to solve?

    gh> When I first started working with nameservers and domains
    gh> it was with SunOS 4.x, where one needed a modified shared library
    gh> to make it work. The SunOS resolver gethostbyaddr() routine would
    gh> always verify the supplied address. If it didn't verify it would,
    gh> I believe, write to syslog and not return the unverified result.

    Which merely changes Barry's point from "What justification do the FTP
    servers have for doing that?" to "What justification does the DNS Client
    library have for doing that?". It doesn't actually answer the question.

    gh> If one wants to believe the domain names in a log file, [...]

    .... then one is wanting the impossible, to be able to trust what is
    inherently untrustworthy. Proper logging should record the IP
    addresses. (The domain names that they map to can be recorded *as
    well*, but they should be secondary data, not primary. Mapping IP
    addresses to domain names is a mere convenience for human readability,
    and should never be confused with being either a necessary part of the
    procedure or a security measure. Moreover: logging that actually
    *discards* the IP address information, and solely logs the domain names
    that IP addresses map to, is misleading to the point of being dangerous.)

  4. Re: Reverse Dns Question...is it really necessary or not?

    KD> some misguided mail servers/admins use reverse lookups as a
    KD> kind of litmus test for spam (as if spammers couldn't come
    KD> up with their own reverse records, duh).

    CM> Right, but spambots don't.

    JdeBP> Rubbish. Hijacked third-party machines also often have address->name
    JdeBP> mappings, and for pretty much the same reason: The people whose
    JdeBP> machines have been hijacked also have deal with the numbskulls who
    JdeBP> employ these daft "security" mechanisms on their various TCP
    services.

    DCS> Of the spam that gets through the main filters here, more than half
    DCS> originates from IP addresses for which there is no rDNS.

    Unless you can demonstrate (a) that the addresses that you are looking
    at are in fact those of hijacked third-party machines, which is what we
    were discussing; (b) that your "main filters" aren't skewing the results
    by eliminating hijacked third-party machines that have address->name
    mappings but not eliminating those that do not, which (given the way
    that DULs tend to be built) is actually quite likely; and (c) that "less
    than half" contradicts my counter of "often" to a blanket claim of
    "don't"; then you haven't contradicted what I wrote.

    DCS> Blocking SMTP sessions from IP addresses lacking rDNS would
    DCS> clearly cut down on spam here; [...]

    .... and would yield to the same defective reasoning that has had us
    solving the wrong problem time and again for roughly a decade now.



  5. Re: Reverse Dns Question...is it really necessary or not?

    TOSA> IME, *only* trojanized spam-spewers lack any rDNS whatsoever.

    And, as two people have pointed out, you are making a conclusion about
    address->name lookups of the SMTP Relay client IP addresses based upon
    looking at something completely different and unrelated, namely the use
    of IP addresses in HELO verbs.

    TOSA> it appears to me that there is a zero chance of a false
    TOSA> positive to reject on a HELO that consists solely of an
    TOSA> IP address.



    "Domain literals" are useful, and it is harder than it would
    superficially appear (i.e. it's impossible) to decide what particular
    subset of IP addresses a SMTP Relay client might validly present as
    domain literals.

  6. Re: Reverse Dns Question...is it really necessary or not?

    TOSA> IME, *only* trojanized spam-spewers lack any rDNS whatsoever. Or,
    TOSA> more accurately, the only HELOs I see that contain merely an IP
    TOSA> are trojanized spam-spewers;

    PJ> HELO is distinct from DNS.

    c> *sigh*
    c>
    c> Jul 19 00:29:21 server sendmail[7921]: NOQUEUE: connect from
    [193.219.234.170]
    c> Jul 19 00:29:29 server sendmail[7922]: i6J5TNh07922:
    ruleset=check_rcpt, arg1=, relay=[193.219.234.170],
    reject=586 5.0.0 Message accepted for delivery
    c> Jul 19 00:29:29 server sendmail[7922]: i6J5TNh07922:
    from=, size=0, class=0, nrcpts=0, proto=SMTP,
    daemon=MTA, relay=[193.219.234.170]

    Was that supposed to be relevant to what Paul said ? It wasn't.


  7. Re: Reverse Dns Question...is it really necessary or not?

    In article ,
    Jonathan de Boyne Pollard wrote:

    > BM> I never really understood why they did that. If they allow
    > BM> anonymous uploads, I suppose it might have been an attempt
    > BM> to reduce warez. But other than that, what problem is it
    > BM> trying to solve?
    >
    > gh> When I first started working with nameservers and domains
    > gh> it was with SunOS 4.x, where one needed a modified shared library
    > gh> to make it work. The SunOS resolver gethostbyaddr() routine would
    > gh> always verify the supplied address. If it didn't verify it would,
    > gh> I believe, write to syslog and not return the unverified result.
    >
    > Which merely changes Barry's point from "What justification do the FTP
    > servers have for doing that?" to "What justification does the DNS Client
    > library have for doing that?". It doesn't actually answer the question.


    Actually, it's easier to understand this. The OS vendor thought that
    putting this in the standard library would be a good way to improve
    security across the board. Servers that performed access control by
    checking the client against an access list (e.g. hosts.equiv) that
    typically contains hostnames were proliferating, but most of these
    servers did not perform reverse DNS spoofing checks. Rather than fixing
    all the servers (not feasible in the case of third-party applications),
    they put the security check in the library function that they all called.

    IIRC, though, it didn't actually report an error, it merely logged a
    message to syslog (something like "gethostbyaddr: != ".

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***

  8. Re: Reverse Dns Question...is it really necessary or not?

    Barry Margolin wrote:

    (snip)

    >>gh> When I first started working with nameservers and domains
    >>gh> it was with SunOS 4.x, where one needed a modified shared library
    >>gh> to make it work. The SunOS resolver gethostbyaddr() routine would
    >>gh> always verify the supplied address. If it didn't verify it would,
    >>gh> I believe, write to syslog and not return the unverified result.


    >>Which merely changes Barry's point from "What justification do the FTP
    >>servers have for doing that?" to "What justification does the DNS Client
    >>library have for doing that?". It doesn't actually answer the question.


    > Actually, it's easier to understand this. The OS vendor thought that
    > putting this in the standard library would be a good way to improve
    > security across the board. Servers that performed access control by
    > checking the client against an access list (e.g. hosts.equiv) that
    > typically contains hostnames were proliferating, but most of these
    > servers did not perform reverse DNS spoofing checks. Rather than fixing
    > all the servers (not feasible in the case of third-party applications),
    > they put the security check in the library function that they all called.


    Well, also they were moving from /etc/hosts based or YP based
    private networks to more Internet connected machines. Though
    I think for a long time Sun assumed private networks not connected
    at all to the Internet.

    > IIRC, though, it didn't actually report an error, it merely logged a
    > message to syslog (something like "gethostbyaddr: != ".


    I thought in that case gethostbyaddr() didn't return any name.
    I don't know if it reported an error, other than that no name
    was returned.

    -- glen




+ Reply to Thread
Page 2 of 2 FirstFirst 1 2