Skip to main content
Question

Yosemite 10.10.5: Weirdness with reverse DNS and SRV lookups on Wi-Fi interface

  • September 22, 2015
  • 7 replies
  • 26 views
J
Forum|alt.badge.img+3

I ran into issues with our Yosemite 10.10.5 image this year. After pushing an image from AutoDMG via DeployStudio to my fleet of Macs, DNS resolution is behaving weirdly.

Initial boot with Ethernet DNS lookups work fine. I can 'dig host', 'dig -x IPADDR', 'dig -t SRV _ldap._tcp.ad-domain.tld'

However, when I connect via Wi-Fi only, things get weird. I can 'dig host', however 'dig -x IPADDR' and 'dig -t SRV _ldap._tcp.ad-domain.tld' fail ( time out? ) with "connection timed out, no servers could be reached'. I can ping the servers.

I get similar behaviour with nslookup against the primary domain controller.

Basically, this kills AD binding for my student clients since SRV lookups are failing.

Steps to replicate:

  1. Install 10.10.5 to Macbook Pro 13" mid-2012
  2. Prep 10.10.5 image with AutoDMG 1.5.3 ( standard install w/updates applied + local admin user via CreateUserPkg )
  3. Deploy image with DeployStudio 1.6.16 via ethernet connection
  4. Push out campus wireless credentials with .profile via Munki
  5. Point clients to use PDC at NTP server and sync time
  6. Remove ethernet connection and switch to Wi-Fi only
  7. Try DNS tests

I did a fresh install with 10.10.5 and I don't see the DNS weirdness there.

Thoughts on troubleshooting?

Thanks

    7 replies

    S
    Forum|alt.badge.img+5
    • SQR
    • Contributor
    • 25 replies
    • September 22, 2015

    Not sure I have an answer or solution for your DNS / WiFi look up issue. but if you say it works with a fresh install of 10.10.5...is something being picked up from the Network service order priority during imaging?

    ...and perhaps rethinking your imaging process may help.
    I suppose, I dont understand the need for casper+deploy studio+munki....can you eliminate one or more of those and focus on a streamlined path?

    Additionally, some images made from AutoDMG work no issues, and sometimes they cause headaches or problems. and theyve all been based off a App Store OS download.

    H
    Forum|alt.badge.img+10
    • htse
    • Contributor
    • 142 replies
    • September 22, 2015

    see if you can open an connection via telnet to the DNS Server on Port 53, that should be more effective than ping

    have you tried specifying the DNS server directly in dig with @?

    Have you tried flushing the DNS Cache on the imaged system or creating a new network location?

    C
    Forum|alt.badge.img+10
    • calumhunter
    • New Contributor
    • 596 replies
    • September 23, 2015

    are you including anything in your AutoDMG image or just dropping the installESD on to it and thats it?

    Sounds like its an image issue, if you cant replicate it with a fresh install from the install.app

    bentoms
    Forum|alt.badge.img+35
    • bentoms
    • Hall of Fame
    • 4331 replies
    • September 23, 2015
    1. Install 10.10.5 to Macbook Pro 13" mid-2012 2. Prep 10.10.5 image with AutoDMG 1.5.3 3. Deploy image with DeployStudio 1.6.16 via ethernet connection

    @jhowesgs The above is from your OP. Can you expand upon more on 1 & 2?

    J
    Forum|alt.badge.img+3
    • jhowesgs
    • Author
    • New Contributor
    • 3 replies
    • September 23, 2015

    Currently drilling down into the packages passes between steps 3 and 4. Post-munki package/policy MDM pushes seems to creating this issue.

    Flushing DNS cache doesn't not fix the issue.

    Dig with targeted @server shows same behaviour.

    I will report back later.

    Thanks for the feedback!

    J
    Forum|alt.badge.img+3
    • jhowesgs
    • Author
    • New Contributor
    • 3 replies
    • September 24, 2015

    I did some more testing with just a baseline image ( and rolled back to 10.9.x ) .

    It seems the issue is somewhere in our Aruba Wireless network.

    Ethernet connections resolve DNS as expected.

    Solo Wireless connection are failing on reverse and SRV lookups.

    We are running Aruba 105/205s on-site. May be an issue with the 6.4.2.6-4.1.1.9_51442 version of the Aruba firmware.

    Thanks for everyones feedback.

    J
    Forum|alt.badge.img+3
    • jhowesgs
    • Author
    • New Contributor
    • 3 replies
    • September 26, 2015

    Aruba Support acknowledged this is a known issue in Build 6.4.2.6-4.1.1.9_51442. Engineering is working on a fix.

    They recommended downgrading to 6.4.2.6-4.1.1.8_50989.

    We have a mix of Aruba IAP-105/205 on site.

    Pushing out this firmware resolved the DNS reverse/SRV issues.

    Thanks


    Terms & ConditionsCookie settingsAccessibility statement