To use a .Local or real internet DNS name for SBS (Small Business Server)

  • Comments 15
  • Likes

I while back I got into a debate with a good friend of mine – Mitch Garvis – President of the Montreal IT Pro user-group.  He’s a hands on Small Business Server guy with plenty of practical real world experience with the product and with various customer requirements. We were having a few drinks with a bunch of people after an event one night and I overheard him mention installing Small Business Server with the DNS namespace ending in a .local top level domain.  That is to say – if I owned canitpro.ca public DNS namespace, the default SBS install suggests I install Active Directory with a canitpro.local DNS namespace.

This intrigued me – why do this? I’ve been designing AD and DNS namespaces for small, medium and enterprise organisations since the product was in Beta and working with DNS and internet connected systems way before then. It doesn’t make sense… A non routable domain suffix?  How could I let Mitch pass out this recommendation to someone without asking – WHY?  So I asked, and opened the proverbial can of worms….

Mitch – Because it’s default… it’s simple.. and it works… Why would I change it?

OK. I had to speak up. My main concern for recommending someone use a .local is that it is not routable and never will be routable on the internet. This is both a good thing (security some say) and bad thing (what if I want to talk to someone on the internet directly without jumping through hoops). If you have a server that has a FQDN (Fully Qualified Domain Name) that ends in a .local – someone who needs to get back to you, can not – without extra work. This isn’t a big deal for internet email (if you don’t mind the extra work), since you can edit the MX records to point to a properly formated, internet resolvable name that just happens to correspond to your IP where your firewall / router / ISA server will accept the incoming SMTP request and switch-er-oo the addressing info to the proper info and pass it on through.  This isn’t the case for other technologies coming down the pipe… maybe they will work with the extra work, maybe they wont… Here are three things that I foresee as being problems for you if you decide to use .local

  • SPAM evaluation scores… if your FQDN that your server spits out when queried is different then your MX record or your SPF record or if it’s non resolvable – you will get higher SPAM ratings for the various systems and have a significantly higher chance of having your email flagged as SPAM.
  • Non translatable services with the ISA firewall / router switch-er-oo… have you thought about your Identity on the internet going forward? What about if you want to start to do some e-commerce stuff or Active Directory Federation Services with someone – can you or will you be able to do it when you have a .local internal name? Maybe, but it sure will require a LOT more extra work.
  • Self issued certificates for SSL – way more complicated – to be trusted outside of your environment without direct importing your issuing root server certificate resulting in extra work for EVERY device and EVERY customer you need to work with. Why is this important? Do you ever want to use a Mobile 5 device with your SBS Exchange SP2 based system for Push email?  Do you have an SSL protected HTTPS page on the internet that prompts you?  If you get prompted by an SSL protected OWA or Exchange Active Sync page, Mobile 5 with Push technology will cause your additional setup grief for each device resulting in extra work.
  • Macintosh machines really hate it – they just can’t cope.

My questions back to him (and you) is – do you own your own internet based DNS namespace that ends in a properly resolvable top level domain (like canitpro.ca or canitpro.com)?  Why not save yourself all that extra work and set up your SBS server environment in such a way as to future proof yourself for DNS namespace and FQDN name resolution headaches. What could you use? Following the K.I.S.S. (Keep It Simple S{fill in here}) principle – if you own canitpro.ca, name your internal AD name space ad.canitpro.ca or corp.canitpro.ca or whateveryoulike.canitpro.ca… You control the namespace, you call it whatever you like. Sure it will make your user names slightly longer (rick@ad.canitpro.ca) – but you can fix that with a couple of simple post install steps. 

  • When you create your AD and you make your first users – run the Administrator tool called Active Directory Domains and Trusts.  You will want to choose properties of the top level object in the details pane (left side of the MMC console) and type in a shortened UPN suffix of canitpro.ca… All new users can be created and then you can select this shorter logon name that will match their email address.
  • You will want to create a Recipient policy in Exchange that will create and set the default SMTP address to be the external routable DNS name… i.e. My internal DNS name space is ad.canitpro.ca and my default email address with exchange is rick@ad.canitpro.ca… you will want to update this recipient policy so that it reflects rick@canitpro.ca as the default…

After some back and forth amongst Mitch, myself and the other table participants – we all came to the agreement that it made sense to use proper DNS naming conventions that are routable and controllable by yourself in an effort to reduce the extra work that would be coming down the pipe as the company grows. I mean hey – what small business wants to stay small forever, right?   Does this mean you should run out and re-install all your SBS installations or reinstall your personal one? You would have to evaluate the Pros and Cons for that one, since it would take a big chunk of planning to determine the impact. Don’t worry – you can continue to live just fine with a .local implementation, provided you are ready for the extra work that lays ahead.

Please don’t take this post as a slight to the SBS community or Development team for using a .local DNS name as a default install choice. IT IS NOT. Likewise – Small Business Server is a True / Real server OS that is an extremely integrated and powerful solution that grows to accommodate up to 75 users.  It is not a “lite” version of Windows Server 2003.  Trust me – I respect SBS and the user community that supports it – they know their stuff.   

Disclaimer: This discussion was over beer, amongst friends, peers and fellow geeks.  It was around DNS naming conventions and best practices for DNS namespace with debates on both sides of the house in good faith. Who won and who lost? I think I picked up the tab, but Mitch and others in attendance now use a different approach to namespace design. You make the call.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • I just posted a lengthy discussion around the question that comes up when one installs Small Business...

  • I had discussion with a new client recently about her in-house computer guy.  It was actually a conversation about 'where should we go from here' and every time I asked why they were doing something she would say 'because my computer guy told me this is the only way to do it.'  



    I told her there were a couple of different types of 'computer guys...' the ones who were willing to learn from others and to keep up with the ever-evolving industry in which we earn our living, and the ones who are not willing to learn, and are lucky enough to have jobs where their bosses also don't keep up and are willing to pay them a salary to stay at the level they were at when they were hired.  



    I always want to be the first guy.  I do not want to be like some of my peers of old who think that IPX/SPX is simpler than TCP/IP, and who are happy earning their keep fixing simple setups.  When I am unwilling to learn from people who know more than me then it will be time for me to find another profession, because from what I can see the IT industry is not planning on staying in one place for long.  



    Thanks to Rick for opening this SBS guy's eyes to routable DNS issues, and thanks to my colleagues and peers who challenge me every day to learn more.  I only hope that you are able to learn from me from time to time too!

  • I'm having a hard time understanding what this "extra work" that keeps getting mentioned.  The really "cool" thing about SBS is that there is no extra work.  There's a wizard for everything.  I name the DNS .local, run the CEICW wizard and voila, each user has a .com or .net or whatever is appropriate to match the FQDN, Exchange is all set up, no muss, no fuss.   No if you can call, creating the MX record to match your external facing IP "extra work" then how is that different that admittedly extra work the OP mentions are required if you choose the FQDN for your SBS. "Sure it will make your user names slightly longer (rick@ad.canitpro.ca) – but you can fix that with a couple of simple post install steps."

    If the SBS AD domain is given the FQDN, then extra work will be required because the Admin will have to create records in the DNS so that internal users can get to the company's externally hosted website.  And there is no wizard for that.  So actually choosing the FQDN does create extra work for the SBS Admin.

    The DNS in SBS is meant for internal name resolution only.

    I appreciate the OP's kind words about SBS and its community.

    But its the suggestion's made here, i.e. not accepting the default recommedations for the domain, IP, etc, and not using the wizards, that lead to many, many questions for fixing issues that are caused in the many SBS community forums.

    Cris Hanna
    SBS-MVP

  • http://blogs.technet.com/canitpro/archive/2006/03/05/421256.aspx
    Between the arguments over "IT", and...

  • The whole topic is a load of BUNKUM. This _has nothing_ to do with SBS, it is a pure AD question.

    The OP is wrong. Your AD DNS namespace should in no way be connected to any other namespace and there is no advantage in making it so.

    Turn the question upside down. Rather than asking yourself 'I have this namespace, why shouldn't I use it?' ask yourself 'I am about to create a namespace which will be solely used internally to my AD, is there any reason why this namespace should be in any way related to my public namespace?'

    I look forward to continuing discussion.

  • I never mentioned this post or the one on the public newsgroups was solely about SBS.  I merely mentioned that when choosing a DNS namespace for your AD design, you need to considered a lot more then just taking a .local because it's default and non routable.

    You kind of reinforced my point with your comment "...I am about to create a namespace which will solely used internally to my AD, is there any reason why this namespace should be in any way related to my public namespace?" the answer is YES.  If you take the short sighted approach that your AD will never need to be referenced outside your network, you are selling your design choice short and potentially limiting your options.

    All my examples in the post related to needing access information and AD stuff outside (ie: SSL certificates, Mobile 5 Push email, Active Directory Federation Services with partners).  These are the types of questions I get from SBS professionals who deploy and support SBS and have made the .local choice. There are work arounds, but they could have been avoided if they chose a sub dir option with a split managed DNS zone.

    I'm not saying your way is wrong or my way is right - it's all a matter of perspective and what's right to the customer.

    Rick

  • I love reading the intelligent back-and-forth between professionals.  I was completely onside with SuperGumby until Rick gave me reason to change my mind.  I did not do this solely because I respect Rick and his experience - I do, but I know we disagree on other matters.  I changed my mind because Rick made a lot of valid points and touched on some technology pains that I had already encountered - yes this works but it's more work.  

    I am not an SBS-MVP but Microsoft does consider me an SME.  As such I know the easy way to do things and I can assure you I know the hard way too.  I do not particularly like building systems on workarounds which is why after my conversation with Rick I went back to my lab and built a test environment with a .com extension.  Lo and behold some of my pains disappeared.  I learned something new and yes, the next time Rick and I were together *I* bought the drinks!

    M

  • sorry if I misunderstood but a heading of 'To use a .Local or real internet DNS name for SBS (Small Business Server)' seems, to me, directly aimed at SBS. go figure.

    More to the point. What problem with SSL certificates? What problem with Mobile 5 push? You may have an edge on me in the area of ADFS, but what exactly is the problem? All questions asked in light of .local vs FQDN based AD DNS, nothing yet about SBS.

    But I'd also like to point out: SBS dev chose .local, it turns out to be a bad choice. Shortly _after_ SBS Dev chose .local other OS's (it's not only OSX, some linux variants are also involved) started treating .local in a non-standard manner. Due to this I have, for some time, used and promoted the use of .lan (hoping that no-one decides this also needs special handling).

    But I do go further. I believe using an FQDN based DNS for your AD is so wrong, and that so many people make the mistake, that I want to thrash it out with someone, anyone, who can give me a valid reason for so naming your AD. Though I have been involved in such discussion for several years _not once_ has anyone come up with such 'valid reason'.

    If I wish to make something inside my AD available publicy I point a name from my FQDN zone to the IP of my firewall (generally ISA, not that it matters much), the firewall then passes requests to my AD resource. I can, but normally don't, also host the FQDN zone.

    As indicated in the newsgroup. I'd really much prefer the discussion to return to that forum, and I'd really like your participation. I hope to persuade you to stop doing what I consider a bad thing but maybe you can change my mind.

  • The cert issue has nothing to do with AD naming though.  Exchange naming is not tied to AD naming.

    Again.. you have to get up to R2 EE before you even get ADFS bits to play with.

    99.99% of the SBS customers will never see these issues.

    I have a self signed cert now that has no relationship with how my domain is named.  In fact you don't even have to have it resolve to a proper name at all..it works with an IP address.

    The only issue I currently have with self signed certs is that Vista slightly barfs on them, but other than that, there's no restrictions.

    If you got a question about ADFS from a SBS customer they are probably also the ones complaining about the fact that SBS 2003 R2 has no real Windows R2 bits and they can't do quotas and DFS.

    There's a white paper coming out with Mobile 5 and SBS in fact.. I'll ping it up here when it's live.

  • SuperGumby is right on the money here. The .local namespace is an issue as he pointed out. Besides that, there is no technical justification for exposing your internal AD or tethering your AD namespace to your external presence.

    The fact that your internal AD is named myAD.xyz does not inhibit your ability to present yourself as Rick@mycompany.co.whatever. Your exchange infrastructure is not married to your internal AD namespace in any technically rigid way. If this were so, there would have been no business built around the concept of Hosted Exchange.

    So, while your discussion may have been technically fulfilling while it lasted, I am afraid it may have been for nought as it appears to me that there really is no "issue" here to be addressed in the first place.

  • I got an email from Kenrick Robertson a week or so ago about problems he’s been having trying to get...

  • Interesting discussion.  Here's my 2 cents.

    1.  By using a registered, globally unique domain suffix you ensure that there are never going to be any interoperability issues with other AD implementations that may have chosen the same name (e.g. activedir.local).

    2.  If you use a subdomain of your existing, registered domain (e.g. ad.myco.com) then the integration with your existing DNS namespace is going to be easier.

    Tony
    MVP - Directory Services

  • (Originally posted March 5, 2006) One of the perks to my position is that I have had the opportunity

  • One of the perks to my position is that I have had the opportunity to make friends with some great people

  • PingBack from http://www.techexams.net/forums/off-topic/39342-local-vs-top-level-domain.html#post284943