On Tue, Apr 3, 2012 at 7:51 AM, exim.ml@??? <exim.ml@???> wrote:
>> > The host concerned has a PTR record, it's a bit of a mess, but it's
>> > there:
>> > dig -x 205.134.224.208
>> >
>> > 208.224.134.205.in-addr.arpa. 17019 IN CNAME
>> > 208.128-255.224.134.205.in-addr.arpa.
>> > 208.128-255.224.134.205.in-addr.arpa. 65020 IN PTR
>> > whub28.webhostinghub.com.
>>
>> SOP for doing rDNS for non 8 bit boundaries.
> I'm sorry Todd, I don't understand that?
SOP means Standard Operating Practice, sorry if the acronym didn't
translate well.
When delegating reverse dns to a company, say for example our
64.14.201.0/24 assignment, the registrar can very simply point
201.14.64.in-addr.arpa to our nameservers because it's on an 8 bit
boundary. However, what if we only had 64.14.201.0/25
(64.14.201.0-64.14.201.127) and *you* had 64.14.201.128/25
(64.14.201.128-64.14.201.255). Those are not on an 8 bit boundary.
The registrar cannot give the entire 201.14.64.in-addr.arpa reverse
delegation to us, nor to you (because that would omit the other from
being able to do reverse dns). So you break it up by inserting an
extra octet using either START-END or START/NETMASK. Your buddy's
registrar uses the START-END method.
We also have 216.35.188.112/28, and our ISP delegates it to us with
START/NETMASK method:
119.188.35.216.in-addr.arpa. 3600 IN CNAME 119.112/28.188.35.216.in-addr.arpa.
112/28.188.35.216.in-addr.arpa. 3600 IN NS ns2.ivenue.com.
112/28.188.35.216.in-addr.arpa. 3600 IN NS ns1.ivenue.com.
;; Received 116 bytes from 209.1.222.247#53(dns04.savvis.net) in 1 ms
Then when your resolver chases that 112/28.188.35.216.in-addr.arpa
delegation, it gets the following result from our nameservers:
;; ANSWER SECTION:
119.188.35.216.in-addr.arpa. 2958 IN CNAME 119.112/28.188.35.216.in-addr.arpa.
119.112/28.188.35.216.in-addr.arpa. 8380 IN PTR smtp-webmail.ivenue.com.
...Todd
--
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. -- Martin Golding
