I just created my first... forest?

ubern00b said:
Then don't make statements like this:



AD is hardly "deep down the rabbit hole".
Click to expand...
Learn to read. The context is towards forests. I've known of AD since I started working with servers, I just steered clear because I thought I couldn't handle the excitement.
 
Caged said:
What do you gain by using a .local?

Using a subdomain of a domain you own is as easy as using a .local, you never have to type the entire thing anyway if your DNS and DHCP offers are configured correctly, and it's considered current best practise.

Will using company.local cause you a ton of headaches right now? No, probably not. Neither will doing it with a subdomain.
Click to expand...
Although I don't necessarily disagree with any of that, you could literally reverse what you just wrote (replace "subdomain of a domain you own" with ".local", and vice-versa), and it would still make just as much sense. I challenge the whole "but it's best practice" without an actual reason why.

I admit I am being stubborn (everyone likes parroting a good best practice), but I didn't get to where I am by accepting other people's "best practices" without fully understanding (and accepting) why.

I remain... unconvinced.
 
I can only go by what Microsoft say about this topic:

https://technet.microsoft.com/en-us/library/cc726016

Using a domain you do not own and therefore don't have control of could potentially be a security issue if your networked clients started throwing authentication requests at a third party in the event they had DNS servers set incorrectly. Using .local can interfere with mDNS and has the potential to cause problems for any Apple devices on the network that resolve addresses in that way. Your domain is company.local, what happens if someone renames their Mac to company? What do clients looking for company.local resolve that name to? Why do you want to put yourself in the position of causing problems when the fix is simple and well known?

Using .int is daft because that's a real TLD.

None of these issues exist if you use a subdomain of a domain you own (or even a domain you own that isn't your public-facing one - bobstyres.com / btad.com). They don't cost a lot. If you had to write a list of potential problems caused by using a subdomain of a domain that you control then it would be an empty list. The same can't be said for .local.
 
Last edited:
If Microsoft and Google have both forgotten to renew domain registrations, then anyone can forget. So in fact I'd say there is higher risk of not being globally unique by using a TLD than by using .local (because it could expire and someone else could buy it). The .local interfering with mDNS keeps getting mentioned, but it's not an actual real problem.

The fact that this is the sum total of Microsoft's guidance: "Also, we do not recommend using unregistered suffixes, such as .local." is what sums it up for me. I don't want to be wed to a TLD at home; maybe at work (debatable), but definitely not at home. I've had my home AD for 7 or 8 years now and it would annoy me to keep paying the £10 or so for something I just don't need.
 
Caged said:
Your domain is company.local, what happens if someone renames their Mac to company? What do clients looking for company.local resolve that name to? Why do you want to put yourself in the position of causing problems when the fix is simple and well known?
Click to expand...

The root would be companyroot.local, and the actual domain would be subdomain.companyroot.local.

If a Mac user causes a problem, I go and fix it, and tell them not to do it again, with a big stick -- in other words, I have control over my environment. In your example, every client on my network is pointing to *my* DNS servers, so the fact that there is a rogue computer on the network is irrelevant to me.

What happens if a Mac user shows up with a digger and digs up the front of the building and disrupts the internet connectivity of the building? Blame it on .local!

Sorry... getting a little carried away here. Let me know if I'm coming across rude or aggressive -- I'm not trying to be. It's just one of my little pet peeves that occasionally gets the chance to rear its ugly head.
 
If you're going to keep waving away genuine issues that can arise as a result of using .local and turning this into a Python sketch with "well apart from all those reasons there's not a problem" then I can't see this being a productive discussion.

Keep using your .local if you want, it's obviously not causing you issues.
 
The reason I tried to inject some humour into it was because I disagree with you that what you've brought up are genuine issues, which is why I'm waving them off.
 
rotor said:
The reason I tried to inject some humour into it was because I disagree with you that what you've brought up are genuine issues, which is why I'm waving them off.
Click to expand...

It's not just you. He literally drawing on strawman arguments and really extreme cases.

AD, at home, and introducing Mac's or systems with manual dns setup. Oh no .local doesn't work... that is when you roll your sleeves up and learn the ins and outs of how to do a forest/domain migration.

Microsoft might say something is best practice, however they make plenty of mistakes were clearly they need to be more thorough with their own procedures. The number of hotfixes AD and SQL have needed over the past few years. They need to get their own house in order before telling everyone else how things should be done. Don't get me started on Internet Explorer.
 
So because a vendor patches their products to fix flaws it impacts on how willingly you pay attention to their design and implementation documentation? It's an interesting position to take.

The whole argument seems to be that without rock solid proof that .local will always cause a problem that you're going to continue to argue that it's a valid way to deploy AD despite the company that makes the software saying its a bad idea and there being literally no advantages to be gained from doing it, as well as a list of problems you can run into. Yes someone could forget to renew a companies domain name, yes someone could dig through your fibre, someone could burn your office down. I'm not sure how they are relevant to what is ultimately a design decision though.
 
Caged said:
So because a vendor patches their products to fix flaws it impacts on how willingly you pay attention to their design and implementation documentation? It's an interesting position to take.

The whole argument seems to be that without rock solid proof that .local will always cause a problem that you're going to continue to argue that it's a valid way to deploy AD despite the company that makes the software saying its a bad idea and there being literally no advantages to be gained from doing it, as well as a list of problems you can run into. Yes someone could forget to renew a companies domain name, yes someone could dig through your fibre, someone could burn your office down. I'm not sure how they are relevant to what is ultimately a design decision though.
Click to expand...

Well yeah, it's M$. Soon everything will read: Buy Azure*.
Best practice: Azure*.

Want to install SQL to best practices? Don't need to, buy Azure*.
Want to run your own DC? Don't need to, Azure*.


* Uptime not guaranteed because in practise we don't follow best practice.

:p
 
I had a meeting MS this week basically saying move to Azure but once I started asking questions they basically said keep some on premise kit and use azure too (and it's not cheap!).
 
paradigm said:
You've never heard of an AD forest? But you work in IT?

Scary stuff.

Get learning about forest roots, trees, child domains...
Click to expand...

Somalians :D

Felix said:
I had a meeting MS this week basically saying move to Azure but once I started asking questions they basically said keep some on premise kit and use azure too (and it's not cheap!).
Click to expand...

I recon within 5 to 10 years we will have things like regional domains not local. I know a project that may take off within the North East where colleges and schools and possibly universities may become one AD because of Azure (and a reduction of IT staff in a bigger location (More Travelling).
 
Last edited:
mrbell1984 said:
I recon within 5 to 10 years we will have things like regional domains not local. I know a project that may take off within the North East where colleges and schools and possibly universities may become one AD because of Azure (and a reduction of IT staff in a bigger location (More Travelling).
Click to expand...


Identity's and Passports are the future for MS, Domains/AD as we know it currently will almost certainly be phased out.

On that note does anyone still use child domains? Every where I've worked now uses a single domain and utilise OU's to separate the lot. i think i even read somewhere that MS themselves do it this way.
 
You get less replication with child domains, so I guess it depends how many sites you have, and what the links are like.
 
Regardless of whether you're going to have multiple child domains, or not, I would still always go for at least root + child domain. Gives you that future flexibility. Also allows you to create e.g. a resource domain.
 
rotor said:
You get less replication with child domains, so I guess it depends how many sites you have, and what the links are like.
Click to expand...

one of the bigger sites was a fortune 500 company with 180,000 employees.

Admittedly they had 2 child domains, one for South Africa and one for the rest of the world.
 
You must log in or register to reply here.
Back
Top Bottom