Re: Can I point to an internet STD requiring PTR records? - TCP-IP

This is a discussion on Re: Can I point to an internet STD requiring PTR records? - TCP-IP ; In article , Chris Jewell wrote: > Can anyone point me to a "MUST" or even a "SHOULD" in a standards- > track RFC which calls for a PTR record for every publicly-visible IP? I've never heard of one. What ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: Can I point to an internet STD requiring PTR records?

  1. Re: Can I point to an internet STD requiring PTR records?

    In article ,
    Chris Jewell wrote:

    > Can anyone point me to a "MUST" or even a "SHOULD" in a standards-
    > track RFC which calls for a PTR record for every publicly-visible IP?


    I've never heard of one.

    What kind of problem are you having due to not having a PTR record? You
    mention that SMTP transactions are often refused, but there are many
    organizations and ISPs that block all IPs that they think are
    residential ISP customers, even if they have PTR records (in fact, they
    may infer that they're residential from hostname conventions). So
    adding PTR records is not likely to help with this.

    It used to be common to use PTR records to try to figure out where
    clients were located geographically. They'd do a WHOIS lookup of the
    domain name. I'm not sure how prevalent this is these days, though.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  2. Re: Can I point to an internet STD requiring PTR records?

    On 15 Jun 2007, in the Usenet newsgroup comp.protocols.tcp-ip, in article
    , Chris Jewell wrote:

    >Barry Margolin writes:


    >> Chris Jewell wrote:
    >>
    >>> Can anyone point me to a "MUST" or even a "SHOULD" in a standards-
    >>> track RFC which calls for a PTR record for every publicly-visible IP?

    >>
    >> I've never heard of one.


    RFC1035 doesn't have the word "MUST" anywhere in the document because
    the use of that keyword wasn't standardized until RFC2119 - but section
    3.3 may be interpreted as requiring it. RFC1480 also lacks the "MUST"
    word, but section 4.3.5 talks about requiring PTR records for the .us
    zone. RFC1519 section 7.2 last paragraph seems to imply the requirement.
    RFC1912 section 2.1 requires it, but is an INFORMATIONAL RFC. RFC2050
    section 5 talks about the responsibilities of maintaining rDNS, but it's
    a BCP. RFC2181 section 10.2 is probably your best bet. RFC2317 also
    touches indirectly on this.

    >> What kind of problem are you having due to not having a PTR record?

    >
    >None yet: we'll get connected Monday. I was preparing the system file
    >changes for our firewall after they told me what my IPs would be, and
    >it occurred to me to "dig -x" the new IPs. It's the first time in 15
    >years with this domain that we've used an ISP who wouldn't give us PTR
    >records to our hostnames, much less no PTRs records at all. (I know
    >that there are plenty of such ISPs, we just hadn't ever used one.)


    No PTR records??? Oh, that's going to bring problems.

    RFC2505 should be looked at for mail servers. Indeed many blocklists
    will include hosts _lacking_ a PTR record, while others also add hosts
    with "generic" PTR names (where the reverse name contains the IP address
    in some fashion, such as ip-123.45.67.89.example.com), or where the name
    returned is the in-addr.arpa name ("89.67.45.123.in-addr.arpa has
    hostname 89.67.45.123.in-addr.arpa" - no ****, Sherlock!). Some mail
    servers are also set to reject connections from hosts where the forwards
    and reverse name records don't match up. Spend some time scanning the
    Usenet newsgroup news.admin.net-abuse.blocklisting for more thrilling
    news.

    >> but there are many organizations and ISPs that block all IPs that
    >> they think are residential ISP customers, even if they have PTR
    >> records (in fact, they may infer that they're residential from
    >> hostname conventions).


    Many residential ISPs are _finally_ starting to block outbound
    connections to remote port 25 to try to cut back on the zombie spam,
    and there are blocklists that tabulate such residential address ranges.

    >> So adding PTR records is not likely to help with this.

    >
    >Quite true, and in fact I plan to point qmail's smtproutes file at the
    >ISP's mailserver.


    That should get around nearly all of the PTR issues - if their mail
    server won't accept mail from one of their own addresses because it lacks
    a PTR record, then there is some serious lack of clue which ought to
    suggest going elsewhere. Do check the blocklists about the status of
    your ISP's mail servers - some blocklists are not afraid to list an IP
    or IP range just because it happens to be some ISP's mail servers if
    those servers otherwise meet the listing criteria.

    Old guy

  3. Re: Can I point to an internet STD requiring PTR records?

    In article ,
    Chris Jewell wrote:
    > ... It's the first time in 15
    >years with this domain that we've used an ISP who wouldn't give us PTR
    >records to our hostnames, much less no PTRs records at all. (I know
    >that there are plenty of such ISPs, we just hadn't ever used one.)


    Are they willing to do IN-ADDR.ARPA delegation so that you can do it
    yourself?

    --
    -- Rod --
    rodd(at)polylogics(dot)com

  4. Re: Can I point to an internet STD requiring PTR records?

    In article ,
    Chris Jewell wrote:

    >> Are they willing to do IN-ADDR.ARPA delegation so that you can do it
    >> yourself?

    >
    >No. They haven't even had their upstream delegate in-addr.arpa for
    >the /24 to *them*, so they could not further delegate to me according to
    >RFC 2317. :-(


    Oops! Judging from that, it is premature to worry about spam filters
    rejecting mail from SMTP clients at IP addresses without reverse DNS
    names. Have you checked to see how many DNS blacklist entries your
    new IP addresses have already won? Organizations with such attitudes
    about minor, cheap details tend to attract and keep customers that
    cause their entire CIDR blocks to be listed in public DNSBLs and
    permanently-list-on-sight for bazillions of operators of private
    blacklists.

    Looking back though in the thread, it seems that I might be the first
    to mention what now appears to be the real problem. One should not
    expect to get real Internet serivce by paying less than the cost of
    real Internet service. What one gets for a lower price lower differs
    from real Internet service. Bogus reverse DNS values are among the
    most common differences between real Internet service and the imitations.


    Vernon Schryver vjs@rhyolite.com

+ Reply to Thread