Name resolution, skip IPv6 for some domains?
-
I'm having an issue with Office 365 where Lync refuses to work if you have IPv6 name resolution enabled. It's almost like they have DNS set up for the services at their end but the services aren't listening.
Is there any way for me to force a domain to be resolved as IPv4 only so that no IPv6 results are returned to clients? I am using unbound.
I found that I can set a static entry for a single host and that works, but I was hoping to set something up for the entire domain that will update as they change DNS at their end.
-
Nope, not really. Not per domain. Would suggest to fix the real problem instead. Most likely you are missing SRV DNS entries. Plus, if this is AD environment, you clients shouldn't point to DNS on pfSense at all.
-
I should have noted that I work from home, and my company uses Lync Online as part of Office 365. If I had the power to fix the real problem I would, but unfortunately the issue is on microsoft's end and/or in the lync client. If a AAAA record is returned in DNS, lync fails to look up the meeting. If I enter host overrides on my end to force IPv4 all is well but I have to constantly look up and correct the entries as new directory servers are used.
-
This is a paid subscription service, no? Get MS fix it.
-
So you have a working ipv6 network? you can access other ipv6 stuff? Or do you have a broken ipv6 network that your box tries to use when an AAAA is returned for a fqdn you query for.
If your ipv6 is working for other sites, etc. Then looks to be broken on the MS side - I agree prob nothing you can do to fix that. I would find that really funny to be honest that MS puts out there AAAA that doesn't work.
I would suspect its more on your OS side that thinks it has a valid IP connectivity that is not actually working and yes by default out of the box if AAAA is returned and your box has IPv6 it would try that first. You could just disable ip6 in your OS, or turn it off in your browser or change the precedence to prefer ipv4 over ipv6 vs the default ipv6 over ipv4
But I know of no way in to say hey use AAAA if returned for domainx.tld but not for domainy.tld Other than taking ownership of a domainy and only returning A vs AAAA for a specific fqdn.
-
So you have a working ipv6 network? you can access other ipv6 stuff? Or do you have a broken ipv6 network that your box tries to use when an AAAA is returned for a fqdn you query for.
That's exactly what I'd pursue. If you have proper, functioning IPv6, this is Microsoft's problem. Confirm that's the issue, and report it to them. They're IPv6 friendly, and I'm sure would like to know if they have a problem.
What you're asking for in the original post isn't practical (at best).
-
I can confirm this issue. I also believe this isn't a pfSense, but a MS one as well. I've been pursuing this one for a little while.
Situation:- Using Office365 for Email/Exchange and Lync/Skype for Business.
Originally had IPv6 tunneled through Hurricane Electric. Today; moved to CenturyLink's 6rd. Same symptoms.
Symptoms:
- E-mail works fine.
Lync/SfB logs in slowly (30-60 sec) the first time, but successfully. Once successful, subsequent re-launches are somewhat instant (I suspect this is DNS related in some way but haven't looked at this closely yet.).
Lync/SfB direct phone/VoIP calls and all person-to-person meeting functions, like screen sharing, work.
Lync/SfB meetings never connect. The alias "meet.lync.com" never responds. Wireshark sees lots of RST action (still some of that in IPv4-only though, so this may not be germane).
I did call MS support while still connected to Hurricane Electric but the support person concentrated on the pfSense config, and while we created an any-any-everything rule temporarily, it didn't resolve the issue. I attempted to escalate the case to someone more knowledgeable but the case got closed (I ran out of time).
While my money is on it being a MS problem, this forum is the only place where I've seen this issue described as I'm experiencing it. So it possibly is a pfSense issue, but I'm at a loss as to how that could be.
- Using Office365 for Email/Exchange and Lync/Skype for Business.
-
Well does it work when directly connect to your isp using ipv6? Looks like it doesn't even ping to me, trace looks like they have a problem once it sure looks like it enters the ms network "ntwk.msn.net" then looks like some weird ass loop??
;; QUESTION SECTION:
;meet.lync.com. IN AAAA;; ANSWER SECTION:
meet.lync.com. 3063 IN CNAME webdir.online.lync.com.
webdir.online.lync.com. 272 IN AAAA 2a01:111:f404:3401::38"Wireshark sees lots of RST action"
You see rst coming back from that ipv6?? Then how and the F does it have anything to do with pfsense? What I would suggest if that is what you need, don't use ipv6.. Ipv6 is not required at all currently, I can not think of one resource other than maybe porn and darknet stuff that is only on ipv6.. So you have no actual reason to need ipv6 to function, or for that matter all sites to have their shit together with it. Clearly it seems ms does not..
So as stated before disable ipv6, or set your system to prefer ipv4, simple manipulation of your prefix policy to prefer ipv4 over ipv6 vs the default way of ipv6 over ipv4. There you go done - you can use ipv6 when YOU want to access something via ipv6 address, but by default system will use ipv4 if given.
-
What exactly do you mean by "lots of RST action"? That could be anything between perfectly normal and a clear indication of a problem.
I get a similar traceroute to johnpoz. Definitely odd looking, but might be normal for Microsoft's infrastructure.
-
very odd trace – lots of bouncing around the same /64 to me.. then back to original /64 and then out to different /64 -- very odd... But sure could be normal for ms.. they don't always do things like everyone else ;)
-
Ha. by "lots of RST action" I meant that many of the calls to the MS servers were being responded to by RST packets by their systems. Because the range and quantity (sometimes just a few, about 10 in a row; sometimes a lot, upwards of fifty, followed by a pause of 5-10 seconds and then another round, etc…), and the fact that they were happening on IPv4 as well, I was tending to rule them out as a factor at all but included the mention for completeness...
Since originally posting, I've had to travel a bit and some locations were offering IPv6. However, they all worked! It turns out that in every case, despite having a v6 address, DNS resolution always pointed to IPv4. So much for that!
Because of that, I also agree that by resolving their servers in IPv4 will be the fix du jour - until they get their issues resolved.
Having worked with MS in the past, the best way is to do as much research as you can prior to contacting them. Which I'll do again shortly (and report back if something useful comes of it). This discussion has been a great help for that.
