 |  |
>Subject: Re: Classless reverse delegation to NT
Re: Classless reverse delegation to NT
From: Peter Lalor
Date: Tuesday, July 25, 2000
Time: 10:02:53 am
>From: "Men & Mice Support" <cbuxton@menandmice.com>
>Date: Thu, 20 Jul 2000 17:17:33 -0700
>
>At 2:34 PM -0700 7/20/00, Peter Lalor wrote:
> >We're attempting to delegate a classless reverse domain to an NT
>>server and having some trouble. It seems trivial from QDNS's point
>>of view: we've created the secondary entry for 128/25.186.184.208,
>>but the NT admin is having some trouble actually creating the zone.
>>He gets:
>>
>>REVERSE19A.DB:53: data "253.186.184.208.IN-ADDR.ARPA" outside zone
>>"128/25.186.184.208.IN-ADDR.ARPA" (ignored)
>>or
>>
>>REVERSE19A.DB:26: data "128/25.133.186.184.208.IN-ADDR.ARPA" outside
>>zone "128/25.186.184.208.IN-ADDR.ARPA" (ignored)
>>
>>As this is the first time I've attempted to delegate a classless
>>reverse, I'm on shaky ground. Could someone explain (again) how
>>things look from the perspective of the NT box?
>>
>>I believe the NT software is Freeware BIND 4.9.7.
>
>Your end of things is more than just creating a secondary entry.
Aww! I should have known that anything with it's roots in Unix
couldn't possibly be simple or logical. ;-)
>You
>currently have PTR records in the range you mentioned:
>
>129.186.184.208.in-addr.arpa. PTR router.mossyford.infoasis.com.
>130.186.184.208.in-addr.arpa. PTR untitled.mossyford.infoasis.com.
>131.186.184.208.in-addr.arpa. PTR untitled.mossyford.infoasis.com.
>[etc.]
>
>These must be removed, though if the unititled are generated from a
>wildcard, you don't have to worry about them.
They were just placeholders while we got this reverse thing sorted.
Is it possible to generate these records from a wildcard in QDNS?
>Then you must add NS records to your reverse zone, to delegate the subzone:
>
>128/25.186.184.208.in-addr.arpa. NS <name server 1>
>128/25.186.184.208.in-addr.arpa. NS <name server 2>
>
>One for each server that will be serving the zone.
Can these records appear anywhere in the zone, or must all the NS
records be the first entries?
>After that, you'll need CNAME records:
>
>129.186.184.208.in-addr.arpa. CNAME 129.128/25.186.184.208.in-addr.arpa.
>130.186.184.208.in-addr.arpa. CNAME 130.128/25.186.184.208.in-addr.arpa.
>131.186.184.208.in-addr.arpa. CNAME 131.128/25.186.184.208.in-addr.arpa.
>[...]
>254.186.184.208.in-addr.arpa. CNAME 254.128/25.186.184.208.in-addr.arpa.
In the reverse zone? I was under the impression that only NS and PTR
records appeared in reverse zones?
Has anyone whipped up an AppleScipt to automate such incrementing
entries? Care to share?
>On the NT side of things, they create a reverse zone called
>128/25.186.184.208.in-addr.arpa. Then they need the following
>records, using BIND shortcut notation:
<snip>
>Lastly, let me mention that BIND 4.9.7 is very much out of date and
>contains several security holes. They should update to BIND 8.2.2p5,
>the latest version. The source code for this is available from
><http://www.isc.org/>. It contains a port for NT, which will compile
>using MS Visual C++ 6.0.
I'll pass that on. I was aware that BIND 4 was very old, but wasn't
aware that the exploits also affected NT.
Once again, Chris, your knowledge of DNS amazes me. I can only think
that you can't possibly do anything else! Thanks again for sharing
what you know.
--
Peter Lalor Infoasis
plalor@infoasis.com The San Francisco Bay Area's Macintosh
415-459-7991 Consultant and Internet Service Provider
415-459-7992 fax http://www.infoasis.com/
Messages In This Thread:
Return to Digital Point Solutions' Home Page