Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I had to manually tweak my DNS service providers BIND file.

BIND file, created by professional hosting company, before:

$ORIGIN mycoolsite.com.  
$TTL 300  
@ SOA ns1.cheapreg.com. registry.cheapreg.com. ( ... )  
@ IN 3600 NS ns1.cheapreg.com.  
@ IN 3600 NS ns2.cheapreg.com.  
@ IN 3600 A 199.9.99.85  
@ IN 3600 A 199.9.99.86  
* IN 3600 A 199.9.99.85  
* IN 3600 A 199.9.99.86  
www IN 3600 A 199.9.99.85    
www IN 3600 A 199.9.99.86  

BIND file, created by layman, after:

$ORIGIN mycoolsite.com.  
$TTL 300
@ SOA ns1.cheapreg.com. registry.cheapreg.com. ( ... )  
@ IN 3600 NS ns1.cheapreg.com.  
@ IN 3600 NS ns2.cheapreg.com.  
* IN 3600 A 219.94.116.50  
* IN 3600 A 219.94.116.51  
* IN 3600 A 219.94.116.52    

The difference is that the "pro"-file has duplicated the nameserver entries, once for @, and once for *,
and I haven't.

Any reason I should also duplicate nameserver entries (@ and *) ?

share|improve this question

3 Answers 3

up vote 1 down vote accepted

As per the first bind file, I believe the following will send out both of the IPs when you query mycoolsite.com for its A record:

@ IN 3600 A 199.9.99.85
@ IN 3600 A 199.9.99.86

The following records are wildcard records:

* IN 3600 A 199.9.99.85
* IN 3600 A 199.9.99.86

so when you query couldthispossiblyexist.mycoolsite.com or blah1290eu.mycoolsite.com for A records, you will receive both IPs.

share|improve this answer
    
This doesn't really answer the question though... –  thomasrutter Dec 13 '12 at 3:25

@ represents records for the main domain itself (i.e. without any prefixes)

* is a wildcard record, representing all possible sub-domains of the main domain, but not the domain itself.

Hence in this case your new zone file won't supply any "A records" (i.e. IP addresses) when queried for the domain itself, but only for its subdomains.

[You say that it's the nameserver entries that are duplicated but that's not the case - it's clearly the lines with A rather than NS that were duplicated but now aren't]

share|improve this answer

There are two main differences:

  • The first example explicitly duplicates the A entry for the subdomain www, even though they would otherwise be covered by the * (wildcard) subdomain A entry. This should not affect the result given for lookups of the www subdomain at all.

    It is there only for the benefit of whoever is maintaining the zone file: to inform them that www is actually used. It is often preferable to list the actual subdomain names that you're using rather than use wildcards only, because it helps serve as a self-reminder to whoever might be managing that zone in the future, about which subdomains are actually being used. This may be helpful should you want to migrate one day.

    As for whether you should do it - it's not mandatory.

  • The second example removes the A record for the domain itself.

    This is a problem, because it means that mycoolsite.com alone (without any subdomain) no longer maps to anything. The top of the current zone (also known as @), is not covered by a wildcard subdomain entry - a wildcard subdomain entry only applies to subdomains.

    This is probably considered a mistake - unless for some reason you want mycoolsite.com not to map to anything, and to be usable only when specifying a subdomain.

share|improve this answer
    
NFSN FAQ has an opinion why you should not use A record for the domain itself. AFAICR they use redirects for naked domains. –  user27465 Apr 22 '13 at 4:25
    
Redirects? You mean a CNAME? That's not possible for a domain that has any other records and not a good idea otherwise. Or do you mean an HTTP redirect? Those are nothing to do with DNS, bind, or zone files. –  thomasrutter Apr 22 '13 at 4:38
    
Interesting discussion. Should be separate topic, however NFSN FAQ: It creates noncanonical URLs for your site. It is less reliable. DNS CNAME records cannot be used in this situation. It becomes confusing if you have more than one web site under the domain. (Which site does example.com refer to?) One name should do one thing. Bare domain names already serve the purpose of organizing the domain, and often they do email duty as well. Web traffic is better kept in its own box. This aids filtering, debugging, and compartmentalizing services. –  user27465 Apr 22 '13 at 5:14
    
Well, assuming this is mainly about wanting to use subdomains per service, like "www" for websites, that's an opinion that the rest of the world is increasingly moving away from, including for example this website (serverfault.com). Relevant discussion also here and here. –  thomasrutter Apr 22 '13 at 6:41
    
Thanks for the update. Best practice is a moving target. –  user27465 Apr 22 '13 at 8:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.