Re: ISPs blocking SMTP connections from dynamic IP address space

• Previous message: Kevin Oberman: "Re: A-DATA flash drive: "Attempt to query device size failed""
• In reply to: Bruce Pea: "Re: ISPs blocking SMTP connections from dynamic IP address space"
• Next in thread: Lucas Holt: "Re: ISPs blocking SMTP connections from dynamic IP address space"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Thu, 7 Aug 2003 15:21:05 +0100
To: Bruce Pea <pea@andrewpea.com>

On Thu, Aug 07, 2003 at 07:49:44AM -0500, Bruce Pea wrote:
>
> Since we began blocking servers with no reverse DNS we've been amazed at
> how many mail servers are setup with no reverse DNS. We've had several
> instances where we've been asked by the party being blocked how to fix
> the problem. Since I'm not a DNS expert all I've been able to tell them
> is to fix their DNS entry so they show up when we do an nslookup on them,
> which isn't very helpful but is about all I know to say.
>
> It would be very useful if someone could explain or give instructions on
> how to fix this problem so we all could pass the info along to people who
> need to straighten out their DNS.

Hmmm... Setting up an inverse domain for a /24 or other subnet
delegated at an octet bounduary is hardly more difficult than setting
up a forward domain. Any text on DNS will explain how PTR records
work -- for instance the Linux DNS HOWTO available at
http://www.tldp.org/HOWTO/DNS-HOWTO.html and many other places --
Google for translations into other languages. Then there's the BIND
documentation at
http://www.nominum.com/content/documents/bind9arm.pdf, their FAQ at
http://www.isc.org/products/BIND/FAQ.html. The "DNS and BIND"
O'Reilly book is good value in this respect as well.

However, in summary: supposing you want to set up the inverse domain,
mapping IP addresses from 12.34.56.0/24 to host names, then you'll need the

    56.34.12.in-addr.arpa.

domain delegated to you by your ISP. In your zone file you'ld have
something like:

    ;; $ORIGIN 56.34.12.in-addr.arpa.
    $TTL 3600
    @ IN SOA ns0.example.com. hostmaster.example.com. (
                    2003080700 ; Serial
                    10800 ; Refresh (3H)
                    3600 ; Retry (1H)
                    604800 ; Expire (1W)
                    43200 ) ; Minimum (12H)
             NS ns0.example.com.
             NS ns1.example.com.
    ;
    0 PTR net.example.com
    1 PTR server-a.example.com.
    2 PTR server-b.example.com.
    [...]
    255 PTR broadcast.example.com.

and the corresponding entry in named.conf on the primary server would
be something like:

    zone "56.34.12.in-addr.arpa" {
        type master;
        file "p/56.34.12.in-addr.arpa";
        allow-query {
            any;
        };
        allow-transfer {
            secondaries;
        };
    };
    
> Does anyone have a document explaining such things handy they could
> share??

What is generally missing is a good explanation of how to do RFC 2317
style delegation for subnets not on octet bounduaries. In this CIDR
world we live in at the moment, that is more likely than not to be the
case. Even worse, many ISP are either unable or unwilling to provide
CIDR style delegation, in which case your correspondents will have to
get the ISP to indsert their data into the appropriate zone file.

If the ISP does do CIDR-style zone delegation, then there are 3
possible styles you could encounter.

i) Automatically -- the ISP generates the PTR RRs automatically from
the A records you create in your forward Zone files. This isn't
really a CIDR style delegation at all, but it has the same effect from
the customer's PoV.

ii) Delegation of individual addresses -- this will only happen for
the smallest subnets. Suppose you've been allocated 12.34.56.76/30
which gives you 2 usable IP numbers together with the network and
broadcast addresses. Then the ISP could simply put:

    76 NS ns0.example.com
           NS ns1.example.com
    77 NS ns0.example.com
           NS ns1.example.com
    78 NS ns0.example.com
           NS ns1.example.com
    79 NS ns0.example.com
           NS ns1.example.com

into the 56.34.12.in-addr.arpa. zone file as above, which delegates
each address separately to the example.com servers. You will have to
have a *separate* zone file (and corresponding entry in named.conf)
for each address containing RRs for just the '@' entry. eg for
12.34.56.78:

    ;; $ORIGIN 78.56.34.12.in-addr.arpa.
    $TTL 3600
    @ IN SOA ns0.example.com. hostmaster.example.com. (
                    2003080700 ; Serial
                    10800 ; Refresh (3H)
                    3600 ; Retry (1H)
                    604800 ; Expire (1W)
                    43200 ) ; Minimum (12H)
             NS ns0.example.com.
             NS ns1.example.com.
             PTR server-b.example.com.
    ;

This very rapidly becomes unwieldy for anything except the smallest
network blocks, and it's not that common.

iii) Reverse delegation by CNAME records -- this is as described in
RFC 2317. Suppose you have been delegated the 12.34.56.64/28 block,
giving you 14 usable addresses together with the network and broadcast
addresses.

In this case the ISP will set up a range of CNAME records in the
parent 56.34.12.in-addr.arpa. zone file:

    64 CNAME 64.64-79.56.34.12.in-addr.arpa.
    65 CNAME 65.64-79.56.34.12.in-addr.arpa.
    66 CNAME 66.64-79.56.34.12.in-addr.arpa.
    67 CNAME 67.64-79.56.34.12.in-addr.arpa.
    68 CNAME 68.64-79.56.34.12.in-addr.arpa.
    69 CNAME 69.64-79.56.34.12.in-addr.arpa.
    70 CNAME 70.64-79.56.34.12.in-addr.arpa.
    71 CNAME 71.64-79.56.34.12.in-addr.arpa.
    72 CNAME 72.64-79.56.34.12.in-addr.arpa.
    73 CNAME 73.64-79.56.34.12.in-addr.arpa.
    74 CNAME 74.64-79.56.34.12.in-addr.arpa.
    75 CNAME 75.64-79.56.34.12.in-addr.arpa.
    76 CNAME 76.64-79.56.34.12.in-addr.arpa.
    77 CNAME 77.64-79.56.34.12.in-addr.arpa.
    78 CNAME 78.64-79.56.34.12.in-addr.arpa.
    79 CNAME 79.64-79.56.34.12.in-addr.arpa.

Then they would delegate the 64-79.56.34.12.in-addr.arpa. zone to you:

    64-79 NS ns0.example.com.
           NS ns1.example.com.

Now you can create a zone file for the block:

    ;; $ORIGIN 64-79.56.34.12.in-addr.arpa.
    $TTL 3600
    @ IN SOA ns0.example.com. hostmaster.example.com. (
                    2003080700 ; Serial
                    10800 ; Refresh (3H)
                    3600 ; Retry (1H)
                    604800 ; Expire (1W)
                    43200 ) ; Minimum (12H)
             NS ns0.example.com.
             NS ns1.example.com.
    ;
    64 PTR net.example.com
    65 PTR server-a.example.com.
    66 PTR server-b.example.com.
    [...]
    79 PTR broadcast.example.com.

and the named.conf entry would look like:

    zone "64-79.56.34.12.in-addr.arpa" {
        type master;
        file "p/64-79.56.34.12.in-addr.arpa";
        allow-query {
            any;
        };
        allow-transfer {
            secondaries;
        };
    };

All DNS resolvers will cope with the extra layer of CNAME indirection
just fine.

        Cheers,

        Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey         Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK

• application/pgp-signature attachment: stored

• Previous message: Kevin Oberman: "Re: A-DATA flash drive: "Attempt to query device size failed""
• In reply to: Bruce Pea: "Re: ISPs blocking SMTP connections from dynamic IP address space"
• Next in thread: Lucas Holt: "Re: ISPs blocking SMTP connections from dynamic IP address space"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]