DNS spoofing and reverse DNS records

Re: DNS spoofing and reverse DNS records

From:

Date:

Time:

>>>We have taken over responsibility for primary DNS for our domain from our
>>>service provider. (They now act as secondary) However they still seem to
>>>think that *they* are responsible for maintaining reverse DNS records for
>>>our domain. (The reason we took over responsibility was their inability to
>>>correctly maintain, amongst other things, the reverse DNS records!)
>>>a.) Is this seeming inconsistency correct?
>>
>>This is pretty normal - your reverse zone is entirely separate from your
>>domain zone(s). If you want responsibility for your reverse records, you'll
>>have to tell them that.
>>
>>I've taken a look at the situation, and they can't easily delegate the
>>whole class C subnet to you anyway; they don't own the surrounding class B.
>>From this, I take it that they haven't given you the entire class C, but
>>just a portion of it.
>
>I asked for a full class C address and as far as I am aware that is what
>they have given me. (1-255) Is there anyway to reliably determin if they
>haven't? I've done a name scan (1-255) which returns nothing unexpected.
>However when I tried pinging .255 I get a response but this host does not
>belong to us.

255 is the broadcast address. Don't use it for an IP address. You have
1-254 at your disposal.

>If they have given me an entire class C and if they don't own the
>surrounding class B what are the potential problems? BTW, who does own the
>surrounding class B? And should we be discussing this in an open forum?

I don't see why this should need to be kept private. There is nothing being
discussed that isn't public information.

As it turns out, I was mistaken about them not owning the surrounding class
B subnet. They do, I simply saw ripe.net and failed to see easynet.co.uk.
Since they own the class B, easynet.co.uk should be easily able (and
willing) to delegate the class C to you.

You can find out who owns any given subnet by tracing the delegation from
the root servers. What follows are the responses to several DNS queries
that I've made to trace the delegation of your reverse zone. The numbers in
the second field are TTLs, and can be ignored.

212.in-addr.arpa. 518400 NS ns.apnic.net.
212.in-addr.arpa. 518400 NS munnari.oz.au.
212.in-addr.arpa. 518400 NS sunic.sunet.se.
212.in-addr.arpa. 518400 NS ns2.nic.fr.
212.in-addr.arpa. 518400 NS auth03.ns.uu.net.
212.in-addr.arpa. 518400 NS ns.eu.net.
212.in-addr.arpa. 518400 NS ns.ripe.net.

212.212.in-addr.arpa. 86400 NS ns.ripe.net.
212.212.in-addr.arpa. 86400 NS ns1.easynet.co.uk.
212.212.in-addr.arpa. 86400 NS ns0.easynet.co.uk.

12.212.212.in-addr.arpa. 86400 NS ns0.easynet.co.uk.
12.212.212.in-addr.arpa. 86400 NS ns1.easynet.co.uk.

>>If this is true, you'll have to deal with a classless subnet delegation in
>>order to get your reverse zone away from them. Read RFC 2317 (and, if
>>necessary, have your ISP read it, too). If you can understand it, great,
>>but if you have questions about it, I can probably answer them.
>>
>><ftp://NIC.MERIT.EDU/internet/documents/rfc/rfc2317.txt>
>
>Thanks. Yes, I have tried reading it. ARRG! I broadly see what their trying
>to deal with but the practise and detail needs more study! For the moment
>I'll stay with what I believe to be true above.

On my 3rd reading, the RFC became entirely clear to me. Of course, I'm
already somewhat fluent in techno-babble.

Anyway, since you have an entire class C, you don't need to worry about
this RFC; it doesn't apply to your situation.
____________________________________________________________________
Chris Buxton Men & Mice
cbuxton@menandmice.com http://www.menandmice.com

Sales:
888/4-DPOINT

Support:
858/452-3696