Topic: Can I use an internal DNS for domain queries only?

[tspoon1986]

First a bit of background. We use an SME Server (7.3) as a firewall/gateway/DNS/proxy server for our network. Our network runs a Windows 2003 Active Directory (mydomain.local). DHCP is provided by a Win2003 Server, and all workstations send DNS requests to a Win2003 Server. If the DNS request is for an internal host (host.mydomain.local), the Win2003 Server can satisfy the DNS request, otherwise it forwards the request to the SME Server. The vast majority of workstations (300+) receive IP addresses via DHCP.

SME runs dansguardian and we have started to use SARG to monitor internet usage. Users do not log in to the SME proxy server - dansguardian is running transparently. As such, the USERID according to SARG/dansguardian is pc-00xxx.mydomain.local and corresponds to the host's IP address. This therefore means that if a workstation gets a different IP address it will have a different USERID in the dansguardian logs. I would like to have SARG report the USERID as the correct hostname of each machine, rather than logging in effect according to IP address.

I don't fully understand where the name pc-00xxx comes from, but I'm guessing that because the SME Server cannot resolve a hostname for the local IP addresses it generates this name automatically. I was thinking - can I tell SME to query the Win2003 server for reverse lookups for IPs in the local range, but to perform all other lookups as normal? I can't tell SME to forward all queries to the Win2003 Server, because it forwards its queries to SME! And assuming I could do this, would it solve my problem and cause the correct hostnames to appear in the dansguardian logs?

I realise this problem could be solved by entering the MAC addresses and hostnames into the Hostnames and Addresses tab of server-manager, but with 300+ clients that would be irritating to maintain. And besides, if I was going to do that, I may as well enter the MAC addresses into the DHCP server and reserve an IP for each client. I do understand that the clients are going to get the IP number most of the time, but I'd rather be sure if I can that the USERID corresponds to a single machine.

I hope that was clear enough... thanks in advance for your thoughts.

Tim.

[mercyh]

You might post in this thread and see if this user found an answer.

http://forums.contribs.org/index.php?topic=36102.0

[CharlieBrady]

I don't fully understand where the name pc-00xxx comes from, but I'm guessing that because the SME Server cannot resolve a hostname for the local IP addresses it generates this name automatically. I was thinking - can I tell SME to query the Win2003 server for reverse lookups for IPs in the local range, but to perform all other lookups as normal?

Yes. Do:

db networks show

and you will see the network record for your local network.

Do:

db network setprop x.y.z.0 Nameserver a.b.c.d

where x.y.z.0 is your local network and a.b.c.d is the IP that you want to use for reverse lookups for that network (probably x.y.z.d). Then do:

sv t /service/dnscache

[tspoon1986]

Yes. Do:

db networks show

and you will see the network record for your local network.

Do:

db network setprop x.y.z.0 Nameserver a.b.c.d

where x.y.z.0 is your local network and a.b.c.d is the IP that you want to use for reverse lookups for that network (probably x.y.z.d). Then do:

sv t /service/dnscache

Thanks for your reply. I tried the above, however it didn't work. An nslookup on a local IP still returns pc-00xxx.mydomain.local. I notice in the first command you write:

Code: [Select]

db networks show
but in the next you write

Code: [Select]

db network setprop x.y.z.0 Nameserver a.b.c.d
(networks vs network). I tried the command with both network and networks with the same result. Also, should Nameserver have a capital 'N'? I tried all lowercase as well, but nothing worked.

You might post in this thread and see if this user found an answer.

http://forums.contribs.org/index.php?topic=36102.0

Thanks, I'll do that.

[CharlieBrady]

I tried the command with both network and networks with the same result.

It should be 'networks'.

Also, should Nameserver have a capital 'N'?

'Nameserver'.

If you do:

cat /service/dnscache/root/servers/c.b.a.in-addr.arpa

and it shows the IP address of your Win2003 server, then you will have got the syntax right. If it still doesn't work, report a bug via the Bug Tracker.

[tspoon1986]

If you do:

cat /service/dnscache/root/servers/c.b.a.in-addr.arpa

and it shows the IP address of your Win2003 server, then you will have got the syntax right. If it still doesn't work, report a bug via the Bug Tracker.

Thanks for your help so far, I appreciate it.

After following your instructions, this is where I'm at. (To be clear, a.b.c.d is the address of Win2003 DNS Server).

Code: [Select]

[root@smeserver ~]# db networks show
a.b.c.0=network
    Mask=255.255.252.0
    Nameserver=a.b.c.d
    SystemLocalNetwork=yes

Code: [Select]

[root@smeserver ~]# cat /service/dnscache/root/servers/c.b.a.in-addr.arpa
cat: /service/dnscache/root/servers/c.b.a.in-addr.arpa: No such file or directory

Code: [Select]

[root@smeserver ~]# ls /service/dnscache/root/servers/
@    b.a.in-addr.arpa   mydomain.local

Code: [Select]

[root@smeserver ~]# cat /service/dnscache/root/servers/@
127.0.0.2

Code: [Select]

[root@smeserver ~]# cat /service/dnscache/root/servers/b.a.in-addr.arpa
127.0.0.1

Code: [Select]

[root@smeserver ~]# cat /service/dnscache/root/servers/mydomain.local
127.0.0.1
Is it bug tracker time? Or am I still not doing something right?

[janet]

tspoon1986

It seems you may not have understood or followed the instructions correctly.
Originally you should have got ouput like this (where 192.168.3.1 is your sme local IP):

db networks show

192.168.3.0=network
    Mask=255.255.255.0
    SystemLocalNetwork=yes

Charlie then advised you to run a command which will add a property and value to the existing db entry for 192.168.3.0
db networks setprop x.y.z.0 Nameserver a.b.c.d

which in your case translates to:
db networks setprop 192.168.3.0 Nameserver a.b.c.d

where a.b.c.d = Win2003 servers IP = eg 192.168.3.150

so you should have entered:
db networks setprop 192.168.3.0 Nameserver 192.168.3.150

db networks show
should now give
192.168.3.0=network
    Mask=255.255.255.0
    Nameserver=192.168.3.150
    SystemLocalNetwork=yes

As reverse DNS uses your IP in reverse order, then the command

cat /service/dnscache/root/servers/c.b.a.in-addr.arpa
should translate to

cat /service/dnscache/root/servers/3.168.192.in-addr.arpa
which (in my case) gives
127.0.0.1

In your situation if you have used a different Win 2003 server IP then I would expect a different answer, ie as Charlie says it would be your Win 2003 servers IP

I suspect you have wrongly entered the first command and created a new db entry for your Win 2003 servers IP, which you will need to remove correctly.
Paste here the output of
db networks show

[tspoon1986]

tspoon1986

It seems you may not have understood or followed the instructions correctly.
Originally you should have got ouput like this (where 192.168.3.1 is your sme local IP):

db networks show

192.168.3.0=network
    Mask=255.255.255.0
    SystemLocalNetwork=yes

Yes, that's correct. That was the output I had before I ran Charlie's command.

Charlie then advised you to run a command which will add a property and value to the existing db entry for 192.168.3.0
db networks setprop x.y.z.0 Nameserver a.b.c.d

which in your case translates to:
db networks setprop 192.168.3.0 Nameserver a.b.c.d

where a.b.c.d = Win2003 servers IP = eg 192.168.3.150

so you should have entered:
db networks setprop 192.168.3.0 Nameserver 192.168.3.150

Correct, that's what I entered (except with my IPs of course).

db networks show
should now give
192.168.3.0=network
    Mask=255.255.255.0
    Nameserver=192.168.3.150
    SystemLocalNetwork=yes

As reverse DNS uses your IP in reverse order, then the command

cat /service/dnscache/root/servers/c.b.a.in-addr.arpa
should translate to

cat /service/dnscache/root/servers/3.168.192.in-addr.arpa
which (in my case) gives
127.0.0.1

In your situation if you have used a different Win 2003 server IP then I would expect a different answer, ie as Charlie says it would be your Win 2003 servers IP

I suspect you have wrongly entered the first command and created a new db entry for your Win 2003 servers IP, which you will need to remove correctly.
Paste here the output of
db networks show

Perhaps my previous post wasn't clear. All output listed in my previous post was output after I had run Charlie's command:

Code: [Select]

db networks setprop a.b.c.0 Nameserver a.b.c.d
Therefore, to see the output of db networks show, see my previous post. For simplicity, where you and Charlie have used x.y.z.0 I have used a.b.c.0, since as Charlie suggests in my case x=a, y=b and z=c.

Does this make sense? Let me know if I'm still not clear.

[janet]

tspoon1986

Please post the current output of
db networks show

It is safe to show local IP numbers here and they do not need obfuscation.

[tspoon1986]

Code: [Select]

[root@smeserver ~]# db networks show
10.192.128.0=network
      Mask=255.255.252.0
      Nameserver=10.192.128.2
      SystemLocalNetwork=yes

[janet]

tspoon1986

10.192.128.0=network
      Mask=255.255.252.0
      Nameserver=10.192.128.2
      SystemLocalNetwork=yes

Then issue this command to check if OK
cat /service/dnscache/root/servers/128.192.10.in-addr.arpa

If that looks right, and you have done
sv t /service/dnscache

and what you expect to happen still does not happen,
then do as Charlie suggests and report a bug

[tspoon1986]

Mary,

I have already done this in my previous post. But I'll humour you and do it again, without obfuscation   :

Code: [Select]

[root@smeserver ~]# db networks show
10.192.128.0=network
    Mask=255.255.252.0
    Nameserver=10.192.128.2
    SystemLocalNetwork=yes

Code: [Select]

[root@smeserver ~]# cat /service/dnscache/root/servers/128.192.10.in-addr.arpa
cat: /service/dnscache/root/servers/128.192.10.in-addr.arpa: No such file or directory
I suspect the reason for the above is because the local network is 10.192.128.0/22 (note mask 255.255.252.0) and so IPs are in the range 10.192.128.1-10.192.131.254. The third octet is not always 128, so I'm guessing the file we're looking for is 192.10.in-addr.arpa, which exists:

Code: [Select]

[root@smeserver ~]# ls /service/dnscache/root/servers/
@    192.10.in-addr.arpa   mydomain.local
However, the contents of this file is not the Win2003 server (10.192.128.2), but localhost:

Code: [Select]

[root@smeserver ~]# cat /service/dnscache/root/servers/192.10.in-addr.arpa
127.0.0.1
FYI, the contents of the other two files is as follows:

Code: [Select]

[root@smeserver ~]# cat /service/dnscache/root/servers/@
127.0.0.2

Code: [Select]

[root@smeserver ~]# cat /service/dnscache/root/servers/mydomain.local
127.0.0.1

[tspoon1986]

It's working. The problem I was having is that the name of the property is NameServer, not Nameserver. So:

Code: [Select]

[root@smeserver ~]# db networks setprop 10.192.128.0 NameServer 10.192.128.2
[root@smeserver ~]# sv t /service/dnscache
means that

Code: [Select]

[root@smeserver ~]# cat /service/dnscache/root/servers/192.10.in-addr.arpa
returns

Code: [Select]

10.192.128.2
Yay! Lookups on local IPs now return correct hostnames. As to whether this solves my problem with Dansguardian Logs I've yet to see. I'll post when I find out.

Thanks Mary and Charlie for your help, if this works it'll save me a lot of time.

[CharlieBrady]

It's working. The problem I was having is that the name of the property is NameServer, not Nameserver.

Sorry about that. On closer checking I see that we have 'Nameservers' for domain delegation, and NameServer for network reverse delegation.

Code: [Select]

10.192.128.2
Yay! Lookups on local IPs now return correct hostnames.

But I believe there is still a problem. Some non-local IPs which also start with 10.192. will be wrongly delegated - we don't deal correctly with the /22 netmask. Would you please summarise the problem from this forum thread in a new bug in the bug tracker?

[tspoon1986]

Hostnames now appear in dansguardian logs. Wonderful!

But I believe there is still a problem. Some non-local IPs which also start with 10.192. will be wrongly delegated - we don't deal correctly with the /22 netmask. Would you please summarise the problem from this forum thread in a new bug in the bug tracker?

See http://bugs.contribs.org/show_bug.cgi?id=4249. I hope I've understood the problem correctly.