DNS Forward Zone confusion

UCS - Univention Corporate Server
,
#1

Hi everyone,

configuring the DNS forward zones in a UCS environment, I am facing a situation I don’t quite understand. I would like to devide our network into 2 sections. One for all the clients managed by UCS. Another one for BYOD clients. Here is the sceanrio:

  • 2 seperate subnets, each connected to its own DNS FORWARD ZONE:
    • 192.168.0.0/23, local.some.thing (managed clients)
    • 192.168.30.0/24, byod (dhcp pool for byod clients)
  • ucs-slave with two VLAN interfaces
    • eth0, 192.168.0.12
    • eth1, 192.168.30.1
  • dhcpd listening on both interfaces
  • Samba-4 is involved

For some reason both, the zonefile local.some.thing and the computer object of the DHCP Server are mixed up shortly after dns-updates. That happens quite often, since Windows clients seems to update DNS dynamically.

The LDAP of the zonefiles looks like this:

DN: zoneName=local.some.thing,cn=dns,dc=local,dc=some,dc=thing
  a: 192.168.0.12
  a: 192.168.30.1 # This should not be here, am I right?
  contact: root@local.some.thing.
  expire: 7 days
  nameserver: delphi.local.some.thing.
  refresh: 8 hours
  retry: 2 hours
  serial: 3927
  ttl: 3 hours
  zone: local.some.thing
  zonettl: 3 hours

DN: zoneName=byod,cn=dns,dc=local,dc=some,dc=thing
  a: 192.168.30.1
  contact: root@local.some.thing.
  expire: 7 days
  nameserver: delphi.byod.
  refresh: 8 hours
  retry: 2 hours
  serial: 7
  ttl: 3 hours
  zone: byod
  zonettl: 3 hours

The LDAP of the machine object:

DN: cn=delphi,cn=dc,cn=computers,dc=local,dc=some,dc=thing
  dnsEntryZoneForward: zoneName=local.some.thing,cn=dns,dc=local,dc=some,dc=thing 192.168.0.12
  dnsEntryZoneForward: zoneName=local.some.thing,cn=dns,dc=local,dc=some,dc=thing 192.168.30.1  # This should not be here!
  dnsEntryZoneForward: zoneName=byod,cn=dns,dc=local,dc=some,dc=thing 192.168.30.1
  dnsEntryZoneReverse: zoneName=168.192.in-addr.arpa,cn=dns,dc=local,dc=some,dc=thing 192.168.0.12
  dnsEntryZoneReverse: zoneName=30.168.192.in-addr.arpa,cn=dns,dc=local,dc=some,dc=thing 192.168.30.1
  domain: local.some.thing
  fqdn: delphi.local.some.thing
  groups: cn=DC Slave Hosts,cn=groups,dc=local,dc=some,dc=thing
  groups: cn=Enterprise Domain Controllers,cn=groups,dc=local,dc=some,dc=thing
  groups: cn=Domain Controllers,cn=groups,dc=local,dc=some,dc=thing
  instprofile: None
  ip: 192.168.0.12
  ip: 192.168.30.1
  mac: 7a:39:4e:5d:97:04
  mac: 52:54:00:45:5e:c9
 ...

When I delete the false entries from the DNS forward zone and in the machine object, they reappear after the next dns-update. That happens quite often, for example when a Windows Machine is starting.

When a client asks:

# nslookup delphi
Server:		192.168.0.12
Address:	192.168.0.12#53

Name:	delphi.local.some.thing
Address: 192.168.0.12
Name:	delphi.local.some.thing
Address: 192.168.30.1

it gets all the adresses, known in every subnet - pointing to local.some.thing - which is not what I want.

What I’d like to do is this: if a client is connected in local.some.thing:

nslookup delphi
Server:		192.168.0.12
Address:	192.168.0.12#53

Name:	delphi.local.some.thing
Address: 192.168.0.12

If another client is connected to byod:

nslookup delphi
Server:		192.168.30.1
Address:	192.168.30.1#53

Name:	delphi.byod
Address: 192.168.30.1

Am I mixing up some things here?

Cheers
Sebastian

#2

Hi audiolinux,
can you please post the (Windows CMD) output of

ipconfig /all

on the host delphi?

#3

Yes. This is not how DNS works. By default a DNS server will reply with all addresses known for an entry no matter where the request came from. This is more than sensible as in general DNS servers don’t have intimate knowledge of the network infrastructure the requesting client’s located in. This is even more the case when the requesting client isn’t the originating client (e.g. when your client at home asks your router at home which asks your provider’s DNS server which asks the authoritative DNS server for the target domain — in this case the originating client’s been hidden between two intermediate DNS servers).

What you’re trying to do is to get the server to reply with different answers depending on where the request came from. This can be done with views. UCS does’t support configuring views, though, so you’d have to do manual configuration and manual management of the zone files.

Note that apart from not being able to manage the results through UCS’s own management infrastructure, views tend to make network management more complex as you suddenly have to keep multiple zone files up to date manually. In all the cases where customers wanted to use something like this they were ultimately better off not using views and adjusting firewall settings instead allowing traffic from both networks to the relevant IP addresses & ports in the other networks.

Mastodon