Cfrtjryk

I'd like to build bind zone files via Ansible. To decide how to structure the jinja2 template I need to know if there is any difference in any of these zone configurations:

1.) good old fashioned way:

$ORIGIN foo.bar.

@       IN      SOA     dns.foo.bar. hostmaster.foo.bar. (

                        2018111601

                        3H

                        1H

                        604800

                        86400)



        86400   IN      NS      ns01.foo.bar.

        86400   IN      NS      ns02.foo.bar.



www             IN      A       10.0.0.1

-

2.) Do I have to specify $ORIGIN if the zone name is already foo.bar?

from named.conf:

zone "foo.bar" in{

    type master;

    file "zones/foo.bar";

};

from zones/foo.bar:

@       IN      SOA     dns.foo.bar. hostmaster.foo.bar. (

                        2018111601

                        3H

                        1H

                        604800

                        86400)



        86400   IN      NS      ns01.foo.bar.

        86400   IN      NS      ns02.foo.bar.



www             IN      A       10.0.0.1

-

3.) Split-up apex and use '@' multiple times

$ORIGIN foo.bar.

@       IN      SOA     dns.foo.bar. hostmaster.foo.bar. (

                        2018111601

                        3H

                        1H

                        604800

                        86400)



www             IN      A       10.0.0.1



@       86400   IN      NS      ns01.foo.bar.

@       86400   IN      NS      ns02.foo.bar.

-

4.) No use of '@' placeholder

foo.bar.       IN      SOA     dns.foo.bar. hostmaster.foo.bar. (

                        2018111601

                        3H

                        1H

                        604800

                        86400)



foo.bar.       86400   IN      NS      ns01.foo.bar.

foo.bar.       86400   IN      NS      ns02.foo.bar.



$ORIGIN foo.bar.

www             IN      A       10.0.0.1

-

I always want this as answer:

$ dig foo.bar ANY +noall +answer

foo.bar.    1784    IN  SOA dns.foo.bar. hostmaster.foo.bar. 2018121401 10800 3600 604800 86400

foo.bar.    86384   IN  NS  ns01.foo.bar.

foo.bar.    86384   IN  NS  ns02.foo.bar.



$ dig www.foo.bar +short

10.0.0.1

Question:

• Do all variants results in the same dns answer?

Answer: yes, they're all the same. Though note I haven't actually loaded these zones in to a DNS server to confirm; e.g., I may have missed a typo when reading the question. Load them in to a DNS server, allow zone transfers, and then transfer them — you should get the exact same result.

Details:

• If you check “Other Zone File Directives” in the BIND9 manual, $ORIGIN defaults to the zone you specify in named.conf. Mainly you'd using $ORIGIN in manually-written files e.g., to make it easier to deal with subdomains ($ORIGIN subdmain.domain.com., then define all your records for the subdomain).




• Same section tells you that @ is a shortcut for the current origin. So spelling it out is exactly the same thing.



• 
  

  When you specify two records for the same name in a row without repeating the name, the second record just implicitly uses the last one's name. To quote RFC 1035 (which calls the name the record's owner):

  
  
  

  
  

  The last two forms represent RRs. If an entry for an RR begins with a blank, then the RR is assumed to be owned by the last stated owner. If an RR entry begins with a <domain-name>, then the owner name is reset.

  
  

  
  
  

  (BTW: $ORIGIN and @ are in the RFC as well, so they should apply to servers other than BIND that use the same zone file format. I just used the BIND manual to get terminology newer than 1987.)

  
  

These are all convenience features of the "master file" format — they have nothing to do with the DNS wire protocol. They don't even survive loading the file into BIND (if you have bind rewrite the zone file, e.g., due to allowing DNS updates, then you'll find it'll rewrite the file much closer to your #4).