4 ms·
That would break internal workflows for a lot of companies—they’re relying on “corp” as a bare TLD to resolve to an internal network endpoint. I bet many IT ad
by TimTheTinker 7y ago
That would break internal workflows for a lot of companies—they’re relying on “corp” as a bare TLD to resolve to an internal network endpoint.
I bet many IT admins would find this “quick fix” that would “make it work again” by effectively removing that /etc/hosts entry.
Perhaps a better patch would be to remove the [TLD] => [TLD].com DNS failover resolution feature.
- gpm 7y agoIf .corp is successfully resolving this change should have no impact, since the problem is only when .corp fails to resolve and the resolver falls back to .corp.com.
- TimTheTinker 7y agoSorry - you’re right. I misread. But I still think failing over from corp to corp.com is a bug, not a feature.
- gpm 7y ago> But I still think failing over from corp to corp.com is a bug, not a feature. I think it was a mistake, but you probably can't fix it now. Too many random pieces of code are going to be relying on it.
- pishpash 7y agoThat doesn't make sense. When .corp fails to resolve now, .corp.com is also a deadend because O'Connor turned the domain off, so nothing should happen to any software by not trying to access .corp.com. Surely a rule can be made in the resolver code that specifically in the case of .corp failing to resolve, short-circuit it there and do not failover to internet domains.
- gpm 7y agoRight, what you're suggesting is one implementation of what I meant by "the moral equivalent of adding these lines to /etc/hosts". I think TimTheTinker was suggesting the much more general fix of breaking the fallback for all domain names, not just .corp domain names.
- deleted 7y ago[deleted]