Strange DNS PTR records
linux at kukkukk.com
Mon Jun 10 20:45:32 MDT 2013
Am Sonntag, 9. Juni 2013, 06:19:03 schrieb Günter Kukkukk:
I mentioned "... that something is working completely wrong ..".
See below at the end - I was wrong with that.
> Am Donnerstag, 6. Juni 2013, 21:23:42 schrieb Charles Tryon:
> Hello Charles,
> > 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.
I don't see a problem here when using
samba-tool dns zonecreate my_dns_server 4.10.in-addr.arpa
and then adding entries to that (reverse) zone, also using samba-tool.
The used netmask shouldn't play a role here at all when creating a SOA record.
When you create a PTR entry in the reverse zone - like:
samba-tool dns add samba 4.10.in-addr.arpa 25.0 PTR something.mydomain.org
that IP (10.4.0.25) points to a _hostname_ ! (a _name_, not an IP).
In your posts you say "...and then creates PTR records like 10.4.0.0.25
and 10.4.2.2.100 ..." - which i don't understand.
Please explain a bit more.
> > 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
You get further info here when you use e.g.:
samba-tool dns query samba 4.10.in-addr.arpa 0 ALL
samba-tool dns query samba 4.10.in-addr.arpa 1 ALL
samba-tool dns query samba 4.10.in-addr.arpa 2 ALL
The PTR record should point to a _name_ - example:
samba-tool dns query linux300 0.10.in-addr.arpa 3 ALL
Name=10, Records=1, Children=0
PTR: bbbb.newtest.org (flags=f0, serial=110, ttl=7200)
Here the IP 10.0.3.10 returns the hostname "bbbb.newtest.org",
which can be checked e.g. with the ISC tool "dig":
dig -x 10.0.3.10
; <<>> DiG 9.9.2-P2 <<>> -x 10.0.3.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47823
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;10.3.0.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
10.3.0.10.in-addr.arpa. 7200 IN PTR bbbb.newtest.org.
;; Query time: 4 msec
;; SERVER: 192.168.200.5#53(192.168.200.5)
;; WHEN: Tue Jun 11 04:36:58 2013
;; MSG SIZE rcvd: 70
Btw - these days also IRC can be a big help.
Join irc.freenode.net channel #samba, my nickname is kukks.
> > > 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!
> I did some first tests here and i think that something is working
> completely wrong.....
Sorry, my fault. :-(
I was using the internal samba dns server. In that case samba must
be restarted when a new zone is added.
I wasn't doing that - so all further tests went nuts!
You are using bind DLZ and the restart is not needed.
> Btw - do you use the internal dns server or the samba BIND DLZ plugin?
> I'll keep you informed about my further findings.
> Your usage of a /19 subnet is a completely different story.
> So first of all the minimal basics should work.
> Additional readings about CIDR regarding (subnetted) reverse zones:
> All this is very special - and i guess - has never been tested with samba.
> At least the internal dns server will have problems with CNAME records
> pointing outside the handled zone ...
> Btw - why did you use a /19 subnet?
> I keep you informed.
> Cheers, Günter
More information about the samba-technical