Date: Thu, 7 Aug 2003 15:21:05 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Bruce Pea <pea@andrewpea.com> Cc: questions@freebsd.org Subject: Re: ISPs blocking SMTP connections from dynamic IP address space Message-ID: <20030807142105.GA35771@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <5836742.1060242584@[192.168.10.11]> References: <XFMail.030806131919.nicole@daemontech.com> <5836742.1060242584@[192.168.10.11]>
next in thread | previous in thread | raw e-mail | index | archive | help
--xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 07, 2003 at 07:49:44AM -0500, Bruce Pea wrote: >=20 > Since we began blocking servers with no reverse DNS we've been amazed at= =20 > how many mail servers are setup with no reverse DNS. We've had several=20 > instances where we've been asked by the party being blocked how to fix=20 > the problem. Since I'm not a DNS expert all I've been able to tell them= =20 > is to fix their DNS entry so they show up when we do an nslookup on them,= =20 > which isn't very helpful but is about all I know to say. >=20 > It would be very useful if someone could explain or give instructions on= =20 > how to fix this problem so we all could pass the info along to people who= =20 > 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.=20 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; }; }; =20 > Does anyone have a document explaining such things handy they could=20 > 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. =20 Cheers, Matthew --=20 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 --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/MmBRdtESqEQa7a0RAnEMAJ9DN1gdsUkxqNXza4u9IK19dN6XowCdHvTy kbNIew9wx3nLiqM3sRL/nOg= =siYL -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030807142105.GA35771>