Strange DNS PTR records

[Charles Tryon]

More information:


On Thu, Jun 6, 2013 at 11:04 AM, Charles Tryon <charles.tryon at gmail.com>wrote:

> OK, I've partially answered my own question, but now I have another...
>
> I found that I can remove the entire reverse lookup zone through the MS
> tool, without it throwing fits or the exist/doesn't exist catch 22.
>
> However, when I run my rebuild script to add the PTR records back in, I
> get the following:
>
> (these are the
> /usr/local/samba/bin/samba-tool dns zonecreate samba 4.10.in-addr.arpa
> /usr/local/samba/bin/samba-tool dns add samba 4.10.in-addr.arpa 25.0 PTR
> something.mydomain.org
> /usr/local/samba/bin/samba-tool dns add samba 4.10.in-addr.arpa 26.0 PTR
> nas1.mydomain.org
> /usr/local/samba/bin/samba-tool dns add samba 4.10.in-addr.arpa 100.2 PTR
> vmhost.mydomain.org
> etc...
>
> Remember that I'm using a /19 subnet.  This creates folders for "0" and
> "2", and then creates PTR records like 10.4.0.0.25 and 10.4.2.2.100.
>
> I'm assuming my problem is in how I'm calling the samba-tool, but I'm not
> clear on the directions for when you are working with something other than
> a 255.255.255.0 subnet.
>

The problem is definitely in how the zone is getting created by the
samba-tool dnz zonecreate command.  I deleted the entire reverse zone
again, and then used the Zone Create wizard on the Windows DNS admin tool
to create just the empty zone.  Since I only specified "10.4" for the
subnet (which still isn't strictly correct, since this usually means a /16
or 255.255.0.0 net mask), it didn't try to create a /24 subnet, with
folders under that.  When I used exactly the same samba-tool commands to
create the individual PTR records, the were all created correctly (for
example, 10.4.2.100), and now work as expected.

So, it there an option on the samba-tool zonecreate command that allows you
to use a specific subnet mask?

Output from the samba-tool query:
<samba:dev>? samba-tool dns query samba 4.10.in-addr.arpa @ ALL
  Name=, Records=2, Children=0
    SOA: serial=62, refresh=900, retry=600, expire=86400, minttl=3600, ns=
samba.usa.om.org., email=hostmaster.usa.om.org. (flags=600000f0, serial=62,
ttl=3600)
    NS: samba.usa.om.org. (flags=600000f0, serial=1, ttl=3600)
  Name=0, Records=0, Children=34
  Name=1, Records=0, Children=18
  Name=2, Records=0, Children=9




> On Wed, Jun 5, 2013 at 4:18 PM, Charles Tryon <charles.tryon at gmail.com>wrote:
>
>>
>> Another question regarding DNS:
>>
>> I have a test domain I provisioned quite a while ago (probably shortly
>> before the final 4.0.0 release, but I don't remember exactly when).  It is
>> currently set up to use BIND 9.9 for DNS.  Most things are running fine on
>> it (though admittedly it doesn't get pushed very hard).
>>
>> When I look at the domain using the DNS manager from Windows Remote
>> Management Tools set (from a Win7 client), I the forward lookup zone looks
>> fine, but I see a bunch of strange PTR records.  Almost all the PTR records
>> have five octets rather than the normal four -- for example, 10.4.0.0.100,
>> or 10.4.2.2.10.  In all cases, the third and fourth positions are the same.
>>  (We are using a /19 subnet.)  The really bizarre thing is that if I try to
>> delete the records, I get an error back that the records "do not exist."
>>
>> Is this an example of the "zombie DNS records" which I've seen mentioned
>> here?
>>
>>  - If it is, what is the best way to clean this up?
>>  - If I use the "samba_upgradedns" command, will that purge/rebuild/fix
>> the DNS database, or will it simply change the front end (BIND vs.
>> Internal) server which is looking at the same back end database?
>>
>> (Re-provisioning this box from scratch isn't entirely out of the
>> question, since it is a test server, but it would be a big pain to
>> reconstruct the domain, especially the machine accounts.  :-( )
>>
>> Thanks!
>>
>>
>>
-- 
    Charles Tryon
_________________________________________________________________________
  “Risks are not to be evaluated in terms of the probability of success,
but in terms of the value of the goal.”
                - Ralph D. Winter