Why should I worry about reverse DNS (rDNS)?
Reverse DNS (rDNS) consists of mapping IP addresses into hostnames. While most Internet applications do not require rDNS to work, there are several reasons why defining rDNS in your network is highly desirable:
publishing rDNS allows people to associate quickly and easily your IP address with your domain name, and therefore it makes easier to report abuse from your IP address space to your abuse desk
publishing information about dynamically assigned IPs greatly helps other networks to distinguish the nature of different mail sources in your network (mail servers vs infected end user machines), and to block SMTP connections from dynamic addresses (if they wish to do so) without guessing and risking to inadvertently block mail servers
publishing proper rDNS for statically assigned IPs - and in particular for those corresponding to proper mail servers - greatly reduces the likelihood that other networks will block those servers by mistake, thinking that their IP belongs to residential dynamic space
moreover, some networks are refusing mail from IP addresses without rDNS defined
on the client side, there are security benefits in running applications such as ssh from an IP with rDNS assigned
How do I get rDNS working?
You need to get a delegation of the reverse DNS zone, and then configure the zone. If your network is, say, 1.2.0.0/16, "getting a delegation" means having a NS record for 2.1.in-addr.arpa pointing to your nameservers, while "configuring the zone" means inserting the right information in the corresponding zone file in your nameservers.
Getting a delegation
You get a rDNS delegation from the same entity that gave you the IP addresses: it may be the ISP you are taking connectivity from, or the regional Internet registry of your area.
Regional Internet Registries (RIR) have formal procedures for assigning rDNS delegations: follow the links pertinent to your registry.
AFRINIC: How To, Policy for reverse delegation
APNIC: Resource guide, Guide to reverse zones, Troubleshooting
ARIN: Policies, Guidelines (in-addr.arpa nameservers must be indicated in the SWIP templates)
LACNIC: Guide, FAQ
RIPE: General information and How To.
Configure the zone
For general information about defining a reverse zone in your nameservers, see for instance the APNIC guide or the RIPE pages linked above.
Note that you do not need to insert all the individual records by hand. If you are using Bind, once you have defined a naming convention for a portion of your space you can use the powerful $GENERATE directive (described in the Bind 9 manual) to define several records with a single line. For instance, you can write in the 2.1.in-addr.arpa zone file:
$ORIGIN 2.1.in-addr.arpa.
$GENERATE 1-254 $.3 PTR adsl-1-2-3-$.dynamic.yourdomain.net.
which is equivalent to 254 lines
1.3.2.1.in-addr.arpa. PTR adsl-1-2-3-1.dynamic.yourdomain.net.
...
254.3.2.1.in-addr.arpa. PTR adsl-1-2-3-254.dynamic.yourdomain.net.
Do not forget to check that matching forward A records are defined in the zone of yourdomain.net. This is very important because it "validates" the rDNS information. You can define them with another $GENERATE directive, like
$ORIGIN dynamic.yourdomain.net.
$GENERATE 1-254 adsl-1-2-3-$ A 1.2.3.$
which is equivalent to 254 lines
adsl-1-2-3-1.dynamic.yourdomain.net. A 1.2.3.1
...
adsl-1-2-3-254.dynamic.yourdomain.net. A 1.2.3.254
دیتاسنتر آسیاتک - ضعف کمبود دانش
نوشته اصلی توسط Woshka
هنوز به مشکلات فنی جدی تر نرسیدید آن وقت هست که دان تایم ها شروع میشود.
