RE: [cobalt-users] Reverse Problem

["Rick" <rick@xxxxxxxxxxxx>]

Well...
my company has 1 entire class C 
I only have used some of the IP-addresses out of it 


-----Original Message-----
From: cobalt-users-admin@xxxxxxxxxxxxxxx
[mailto:cobalt-users-admin@xxxxxxxxxxxxxxx]On Behalf Of E.B. Dreger
Sent: Friday, April 26, 2002 7:16 AM
To: cobalt-users@xxxxxxxxxxxxxxx
Subject: RE: [cobalt-users] Reverse Problem


R> Date: Fri, 26 Apr 2002 06:30:17 +0800
R> From: Rick <rick@xxxxxxxxxxxx>

[ somewhat snipped ]


R> I didnt get what you meant
R> care to elaborate further ?

Not sure where in particular, so I'll elaborate on most all...


R> And, chances are it doesn't; only a /31 (!) can start on ...250,
R> and those are used _only_ for routing links.  But one needn't do

Gerald commented that he'd not seen a subnet whose start was
x.x.x.250.

	250 decimal = 11111010 binary

so x.x.x.250 means that the subnet could only be a /31, or a
subnet mask of 255.255.255.254.  This is used by some for router
links, but for nothing else.  i.e., he was correct that the IPs
you specified probably weren't aligned on a subnet routing
boundary, but that's irrelevant for DNS issues.


R> DNS for an entire subnet.  RFC2317 for more info.

	ftp://ftp.isi.edu/in-notes/rfc2317.txt

describes "Classless IN-ADDR.ARPA Delegation".  In particular,
note that one need not delegate DNS aligned along subnet
boundaries.



R> Note that I did a bit of "dig"ging, and the delegation looks...
R> well, a bit weird.  It appears that more has been delegated, and
R> 254 has not.  Multiple CNAMEs are a bad thing.

	dig @ns1.cwasia.net.sg 250.189.126.202.in-addr.arpa. ns
	dig @ns1.cwasia.net.sg 254.189.126.202.in-addr.arpa. ns

At this point, it might be easiest if you can share the zone
file(s), either on- or off-list.  Much faster to rip through
those than multiple dig/nslookup queries.


R> 254 has not.  Multiple CNAMEs are a bad thing.

	man named.conf

and search for "multiple-cnames".


R> Zone must match the CNAME used in delegation.  Otherwise your
R> zone file looked good.

With CNAME-based reverse delegation, someone essentially says
(watch out for long line):

	1.0.168.192.in-addr.arpa  IN CNAME  1.blah.0.168.192.in-addr.arpa.

You must then create zone "blah.0.168.192.in-addr.arpa" with an
IN PTR record for "1" in the "blah...." zone.  Note that said
zone needs "IN NS" record(s) to indicate who the authority is.


--
Eddy

Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@xxxxxxxxx>
To: blacklist@xxxxxxxxx
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist@xxxxxxxxx>, or you are likely to
be blocked.


_______________________________________________
cobalt-users mailing list
cobalt-users@xxxxxxxxxxxxxxx
To Subscribe or Unsubscribe, please go to:
http://list.cobalt.com/mailman/listinfo/cobalt-users