How to get Ubuntu to pick up proper DNS routes over PPTP

I'm wondering if the issue is how suffix appending is working on the windows machines. To test this, try running nslookup on a full name on one of the windows machines, i.e. nslookup ns.leerdomain.local. If that works it means your windows machines are not appending the leerdomain.local suffix to your queries. You can check that in tcp/ip properties->advanced on one of the windows machines.

Look at /etc/resolv.conf on the ubuntu box, the search directive there will tell you how that machine is appending domains. Look at the output of ipconfig /all on one of the windows machines, in particular check the output of primary dns suffix. ipconfig /displaydns may also give you some useful info about how the machine is configured to use DNS.

There is really no way to accomplish your task, because the DNS server can resolve queries in any way it feels is appropriate, and it's a black box to the client. However, it is possible to get close to answering your question.

The trick is to set up a subdomain with a special nameserver whose response to any A query simply echoes the IP address of the host that issued the query. Such a nameserver can be implemented in Perl using the Net::DNS::Nameserver module:

#!/usr/bin/perl

use Net::DNS::Nameserver;

Net::DNS::Nameserver->new(
    # w.x.y.z is the IP address of the host where this code is running
    LocalAddr => ['w.x.y.z'],
    ReplyHandler => sub {
        my ($qname, $qclass, $qtype, $peerhost, $query) = @_;
        my ($rcode, @ans, @auth, @add) = ('NXDOMAIN');
        print "Received query for $qname from $peerhost\n";

        if ($qtype eq 'A') {
            $rcode = 'NOERROR';
            push @ans, Net::DNS::RR->new("$qname 1 $qclass $qtype $peerhost");
        }
        return ($rcode, \@ans, \@auth, \@add, { aa => 1});
    },
)->main_loop;

Next, configure some domain's NS record to point to this special nameserver. I've done this for a domain called resolverid.acrotect.com. (As a service to you, I'll leave the code running there for the next few days.)

Then, issue a few different DNS queries from a client inside your network:

dig +short cachebuster1.resolverid.acrotect.com
dig +short cachebuster2.resolverid.acrotect.com
dig +short cachebuster3.resolverid.acrotect.com

This will cause your nameserver to resolve the queries by contacting the rigged nameserver, which replies with the IP address of the machine that forwarded the query. In some cases, that address is the "public" side of your "private" nameserver, which is what you asked for.

In other cases, the infrastructure is more complicated. For example, if you are configured to use Google DNS servers 8.8.8.8 and 8.8.4.4, you are actually using a geographically distributed pool of nameservers. The Google server that makes the query to the rigged nameserver might not have an IP address anywhere near 8.8.8.8 or 8.8.4.4. However, you would be able to see that it belongs to Google by doing a reverse-IP or WHOIS lookup on the response. (Interestingly, if you do the reverse-IP lookup using Google DNS, you'll see that Google has optimized away the reverse-IP lookup based on the A lookup you just performed. The PTR that it returns will be something.resolverid.acrotect.com. To bust that optimization, you'll have to do dig +trace -x a.b.c.d.)