2

So most of our developers work with a MAMP/XAMPP setup using rewrite rules to point username.project.local to a document root of /Users/username/Projects/project/public_html. This part works, but the problem is getting *.local to point to their machine. Instead of tackling this on each developer's machine, I was thinking I could add a rule on our internal DNS, since we already have one set up.

Currently in /var/named/example.com I see

@       IN      SOA     SERVER1.EXAMPLE.COM.   dns.example.com.(
                        2013020501      ; Serial yyyymmddnn
                        3h              ; Refresh After 3 hours
                        1h              ; Retry Retry after 1 hour
                        1w              ; Expire after 1 week
                        1h)             ; Minimum negative caching of 1 hour

; NS Records
@                       3600    IN      NS      DNS1.STABLETRANSIT.COM.
@                       3600    IN      NS      DNS2.STABLETRANSIT.COM.

; MX Records
@                       3600    IN      MX      10      ASPMX.L.GOOGLE.COM.
@                       3600    IN      MX      20      ALT1.ASPMX.L.GOOGLE.COM.
@                       3600    IN      MX      20      ALT2.ASPMX.L.GOOGLE.COM.
@                       3600    IN      MX      30      ASPMX2.GOOGLEMAIL.COM.
@                       3600    IN      MX      30      ASPMX3.GOOGLEMAIL.COM.
@                       3600    IN      MX      30      ASPMX4.GOOGLEMAIL.COM.
@                       3600    IN      MX      30      ASPMX5.GOOGLEMAIL.COM.

; Google
mail                    3600    IN      CNAME   ghs.google.com.
docs                    3600    IN      CNAME   ghs.google.com.
mail                    3600    IN      CNAME   ghs.google.com.
calendar                3600    IN      CNAME   ghs.google.com.
sites                   3600    IN      CNAME   ghs.google.com.

; A Records
@                       3600    IN      A       ***.***.***.***

; CNAME Records
www                     3600    IN      A       ***.***.***.***

; Staging Environment
server2              3600    IN      A       192.168.1.1
*.server2            3600    IN      CNAME   server2.example.com.
server3              3600    IN      A       192.168.1.2
*.server3            3600    IN      CNAME   server3.example.com.

Is it possible to add a rule so that *.local will resolve to 127.0.0.1?

2
  • Your line beginning with 'www' under 'CNAME Records' is not a CNAME record.
    – Jonathan J
    Dec 12, 2013 at 0:53
  • Those responsible have been sacked. Dec 12, 2013 at 1:46

3 Answers 3

4

Like Michael Dillon pointed out, using .local for an internal TLD is a Bad Thing -- it breaks RFC-specificed services (RFC 6762, if you're curious).

I would take his answer a step further and say that using any arbitrary top-level domain is a Bad Thing.
ICANN is now allowing the registration of arbitrary top-level domains. This means that you can use .secret today and have no collisions, but tomorrow the NSA may acquire that TLD for publishing other people's dirty laundry, and you would then be in conflict with all their .secret domains on the internet. That's a lousy situation to be in.

The best current practice for exposing "internal stuff" with a DNS name is to use a subdomain of a registered domain you control. For example if you own example.com you might put your development sites under dev.example.com.


From your question it sounds like what you want are "local" domain names that always point back to 127.0.0.1, so for your situation I would recommend creating two records for local.example.com on your internal DNS:

local.example.com.    IN  A  127.0.0.1
*.local.example.com.  IN  A  127.0.0.1

Developers could then access foo.local.example.com and they'd be pointed to their local machine (127.0.0.1). This requires more typing (which you can eliminate by changing your DNS suffix search order on the clients), but it guarantees your namespace is safe from collisions with arbitrary gTLDs and conforms with best practices.

If you need something to cite to convince other people in your organization that this is The Right Thing To Do I suggest MDMarra's excellent blog post on why you shouldn't use .local for your Active Directory domain -- the reasons articulated there extend very well to anything DNS-related.

1

In general it is a bad idea to use .local for internal domains. It gets mixed up with the use of .local by Bonjour/Rendezvous services. Better to pick another name like .secret

After that, you just treat the .secret the same way as you would treat .mycompany.com and you were hosting the DNS (master/slave) yourself. You set up a zone file for .secret and serve it up internally. Instead of SERVER1.EXAMPLE.COM in your example, you would have a SOA for SECRET.

4
  • 2
    ...trade one bad non-standard internal domain name (.local) for another (.secret)? Admittedly that's Doing It Less Wrong (it won't break Bonjour/Rendezvous), but how about we encourage Doing It Right (with a subdomain of a registered domain name) instead? :-)
    – voretaq7
    Dec 11, 2013 at 3:15
  • .local is bad because it is used by a widely deployed protocol. If you want a local domain that does not exist outside your organization then you must choose something that does not collide with global top level domains. It needs to have at least 4 letters, and preferably is the kind of thing that would not be desirable to the crop of new registrars opening up. .FSXN would work too as would .OUROWN. It boils down to company policy. If the company is fine with priv.mycompany.com thats great. If not, choose wisely. Dec 11, 2013 at 18:42
  • You could add an example of what the configuration would look like? My attempts aren't working. I'll change .local to something else (or if you want to elaborate on using a subdomain of a registered domain). Dec 11, 2013 at 20:21
  • 1
    @MichaelDillon a subdomain of a registered domain (private.mycompany.com, client.dev.mycompany.com, or something similar) guarantees you will not have collisions with potential new arbitrary gTLD registrations. Since ICANN in their infinite wisdom has made it so anyone with the cash can register any arbitrary bunch of symbols as new TLD there is no "wise" choice of arbitrary names - there's always the potential for a collision (If you want to promulgate a "local-only TLD" in an RFC I would personally be open to the idea but AFAIK nobody has done that)
    – voretaq7
    Dec 11, 2013 at 21:51
0

With due consideration to the other posts suggesting you not use an invalid TLD, it is certainly possible.

What you are seeking to implement is known as a wildcard DNS record. There is much wisdom available from Internet searches.

I would expect to implement it this way:

*    IN  A  127.0.0.1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .