none
Clients Roaming Multiple Subnets and DNS RRS feed

  • Question

  • I am looking at a better way to handle roaming client devices on a multiple subnet network while keeping DNS A and PTR records access able for a growing network. I am assuming I am not the first with this issue and seeking a little guidance. After looking at " THE GOOGLE", I have not found what I am looking for.

    Current problem is that DNS is not able to resolve a device to the correct IPADDR. FQDN pings are sometimes failing due to incorrect DNS A record information. It hurts the Support Desk when troubleshooting connection troubles and SCCM is not managing correctly since device names are not resolving are timing out. 

    After some intense troubleshooting I have found the devices are obtaining a new IPADDR from DHCP LAN scope (Device is Docked), then DHCP is set to create the DNS A and PTR records. That work as should, but when the device changes to the WIRELESS scope (Device is Undocked) and DHCP is updating the device's DNS A record with the newly obtained IPADDR then creates a new PTR. When running NSLOOKUP on both IPADDRs, they return the device name is associated for both original LAN and current WIRELESS IPADDR based on the PTR record. Using NSLOOKUP by device name will return the current / recent leased IPADDR. This is also correct and working as should. Trouble occurs when the user comes back to the LAN scope of the original network. The device is no longer connected to WIRELESS and using the LAN connection. DHCP replies to the device DHCP request with the previously leased LAN IPADDR that has not yet expired. The device is connected and working as should.  But DHCP does not recreate or update the DNS A or PTR record for the device because DHCP see that the lease had not expired and expects the DNS A and PTR are correct as left. So running NSLOOKUP for the name will return the WIRELESS IPADDR and pings will timeout. 

    DHCP should manage the devices since it knows when a device is leased and expired to creating and remove the A and PTR record keeping DNS up-to-date. Seems better then having Scavenging stale records at a later date.

    This problem also occurs when the device is on the LAN. Some users have multiple Docking stations in different offices or conference and training rooms. Conference and training rooms have their own IP subnets and depending on the office they could be in a different IDF that also has its own IP subnet. 

    Example:
    PC23 leases IPADDR 10.10.128.100 from DHCP for IDF 10A. DHCP registers PC23.beck.local with 10.10.128.100 into DNS A and PTR records. Everything pings and works. Running NSLOOKUP at this point would display:
    nslookup pc23.beck.local
    Server: dc01.beck.local
    Address: 10.10.46.64

    Name: pc23.beck.local
    Address: 10.10.128.100

    &

    nslookup 10.10.128.100
    Server: dc01.beck.local
    Address: 10.10.46.64

    Name: pc23.beck.local
    Address: 10.10.128.100

    PC23 is moved to IDF 20A and now leases IPADDR 10.10.132.200 from DHCP. DHCP registers PC23.beck.local with 10.10.132.200 into DNS A and PTR records. Everything is still pinging and working. Running NSLOOKUP now displays:

    nslookup pc23.beck.local
    Server: dc01.beck.local
    Address: 10.10.46.64

    Name: pc23.beck.local
    Address: 10.10.132.200

    &

    nslookup 10.10.132.200
    Server: dc01.beck.local
    Address: 10.10.46.64

    Name: pc23.beck.local
    Address: 10.10.132.200

    &

    nslookup 10.10.128.100
    Server: dc01.beck.local
    Address: 10.10.46.64

    Name: pc23.beck.local
    Address: 10.10.128.100

    PC23 now moves back to IDF 10A. Since the DHCP lease has not expired yet, the DHCP server sends the leased address back to PC23 of 10.10.128.100. DHCP does not update DNS since DHCP shown it had an existing lease for the device. Pings stop working for the FQDN. Running NSLOOKUP now displays:

    ping pc23.beck.local

    Pinging pc23.beck.local [10.10.132.200] with 32 bytes of data:
    Request timed out.
    Request timed out.
    Request timed out.
    Request timed out.

    ping 10.10.128.100

    Pinging 10.10.128.100 with 32 bytes of data:
    Reply from 10.10.128.100: bytes=32 time<1ms TTL=255
    Reply from 10.10.128.100: bytes=32 time<1ms TTL=255
    Reply from 10.10.128.100: bytes=32 time<1ms TTL=255
    Reply from 10.10.128.100: bytes=32 time<1ms TTL=255

    nslookup pc23.beck.local
    Server: dc01.beck.local
    Address: 10.10.46.64

    Name: pc23.beck.local
    Address: 10.10.132.200

    &

    nslookup 10.10.132.200
    Server: dc01.beck.local
    Address: 10.10.46.64

    Name: pc23.beck.local
    Address: 10.10.132.200

    &

    nslookup 10.10.128.100
    Server: dc01.beck.local
    Address: 10.10.46.64

    Name: pc23.beck.local
    Address: 10.10.128.100

    Is there something that I am missing for this to work correctly? Would creating a sub domain for each IDF and wireless subnet possible correct this? Placing all computers from the IDF into 10a.bldg1.beck.local , 10a.bldg2.beck.local, etc. Seems it would be hard to manage or find devices on the network. Would also leave a lot of records not 


    DOMAIN:beck.local (Yes understand local is not acceptable and that is a losing fight here with our AD Engineers)

    Servers: AD, DNS, DHCP:
    dc01.beck.local - 10.10.46.64
    dco2.beck.local - 10.10.46.65

    DNS Server:
    Forward Lookup Zone
       beck.local
    Reverse Lookup Zones
       10.10.in-addr.arpa
       128.10.10.in-addr.arpa
       130.10.10.in-addr.arpa
       etc - Each Subnet is present.

    DHCP - DNS Options:
    Currently, devices are obtain an IP from the DHCP server while receiving Option 015 DNS Domain Name: beck.local   
       Enable DNS dynamic updates according to the settings below:
       Allows dynamically update DNS A and PTR records
       Discard A and PTR records when lease is deleted
       Dynamically update DNS A and PTR records for DHCP clients that do not request updates.
          Enable Name Protection (Is enabled for a select set of scopes)

    LAN Lease: - 8 days.

    WIRELESS Lease times:
    PROD: - 8 hours
    ENTPR: - 1 hour


    BLDG 1 - IDF:
    ADMIN - 10.10.126.0/24
    10A - 10.10.128.0/23
    11B - 10.10.130.0/23
    20A - 10.10.132.0/23
    40A - 10.10.134.0/23

    BLDG 1 - CONF & TRAIN RM:
    CONF1 - 10.10.160.0/24
    CONF2 - 10.10.161.0/24
    TRAIN1 - 10.10.170.0/24
    TRAIN2 - 10.10.171.0/24
    TRAIN3 - 10.10.172.0/24

    BLDG 1 - WIRELESS SSID:
    PROD - 10.10.224.0/23
    ENTPR - 10.10.226.0/23

    BLDG 2 - IDF:
    ADMIN - 10.12.126.0/24
    10A - 10.12.128.0/23
    20A - 10.12.132.0/23

    BLDG 2 - CONF & TRAIN RM:
    CONF1 - 10.12.160.0/24
    CONF2 - 10.12.161.0/24
    TRAIN1 - 10.12.170.0/24

    BLDG 2 - WIRELESS SSID:
    PROD - 10.12.224.0/23
    ENTPR - 10.12.226.0/23

    Friday, January 19, 2018 9:13 PM

All replies

  • Hi,
    Thank you for your question. 
    I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.
    Thank you for your understanding and support.
    Best Regards,

    Frank

    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, January 22, 2018 2:52 AM
  • Any update?

    Friday, January 26, 2018 4:33 PM