Wildcard DNS with BIND

Question

I'm trying to setup BIND so that it catches any and all requests made to it, and points them to a specific set of NS servers, and a specific A record.

I have around 500 domains, and I'm adding new ones at the rate of 10-15 a day, so I don't want to explicitely add a zone for every domain.

My current setup is: in my named.conf, I have a view (named external) with the following zone in it:

zone "." {
        type master;
        file "ext.zone";
};

This matches all requests.

ext.zone is:

$TTL    3600
@       IN      SOA     . root.nsdomain.com. (
                              1         ; Serial
                         3600         ; Refresh
                          300         ; Retry
                         3600         ; Expire
                         300 )        ; Negative Cache TTL


        IN      NS      ns1.example.com
        IN      NS      ns2.example.com

ns1     IN      A       192.0.2.4
ns2     IN      A       192.0.2.5

*.      IN      A       192.0.2.6

so, the goal is: for all NS requests, return ns1.example.com and ns2.example.com for all A requests, except where it is ns1.example.com or ns2.example.com, return 192.0.2.6. For ns1.example.com return 192.0.2.4, for ns2.example.com return 192.0.2.5.

This almost works, the only problem is that when I do a dig, I get:

dig @localhost somedomain.example

; > DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 > @localhost somedomain.example
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; opcode: QUERY, status: NOERROR, id: 37733
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;somedomain.example.                        IN      A

;; ANSWER SECTION:
somedomain.example.         3600    IN      A       192.0.2.6 // as expected

;; AUTHORITY SECTION:
.                       3600    IN      NS      ns1.example.com. // expected, I don't know if the "." at the start is bad, though.
.                       3600    IN      NS      ns2.example.com. // see above.

;; ADDITIONAL SECTION:
ns1.example.com.  3600    IN      A       192.0.2.6 // not expected, this should be 192.0.2.4
ns2.example.com.  3600    IN      A       192.0.2.6 // not expected, this should be 192.0.2.5

How do I fix this? Am I doing something horrible? Is there a better way to do this?

Answer 1

Your origin for the zone is . per your configuration. You are creating records for ns1. and ns2. instead of ns1.example.com. and ns2.example.com. Since ns1.example.com and ns2.example.com aren't defined, they are matched by the wildcard.

EDIT: here's an edit of your config and zone:

zone "example.com." {
        type master;
        file "ext.zone";
};

ext.zone:

$TTL    3600
@       IN      SOA     ns1 root (
                              1         ; Serial
                         3600         ; Refresh
                          300         ; Retry
                         3600         ; Expire
                         300 )        ; Negative Cache TTL


        IN      NS      ns1
        IN      NS      ns2
        IN      A       192.0.2.6


ns1     IN      A       192.0.2.4
ns2     IN      A       192.0.2.5

*      IN      A       192.0.2.6

Everything in the zone is relative to the zone name in the named configuration, so adding a second zone just points to the same file:

zone "example.net." {
    type master;
    file "ext.zone";
};

Answer 2

To set a subdomain wildcard in bind you should use the following format:

name.tld.   IN  A   IP    # main domain ip
*.name.tld. IN  A   IP    # wildcard subdomains ip

---

Example:

mydomain.com.   IN  A   1.1.1.1
*.mydomain.com. IN  A   1.1.1.1 

Answer 3

Based on your configuration ns1.example.com is 192.0.2.4 and ns2.example.com is 192.0.2.5. You have to configure the NS server name resolution in the example.com zone to get the proper IPs.

I hope I make myself clear. Come back to me if you need more info.

Answer 4

DNS wildcards can cause troubles!

so I don't want to explicitely add a zone for every domain.

There're lots of ways to go — from SHELL-scripting till SQL-based DNS-servers.

---

UPD. (2019-11): So as I've said 8 years ago, SHELL-scripting is a way to go and it's been proved with accepted answer's proposed solution "adding zone entry" — clearly not based on wildcards use. ;-)

In 2019 it's even easier to find resources explaining downsides of DNS wildcards and although most of them were written "at the dawn of Internet" they still hold some value. For e. g., RFC1912 mentions a few things related to DNS wildcards use. The primary issue is clearly explained as "…

Wildcard MXs can be bad, because they make some operations succeed when they should fail instead. …"

It also has some real-life examples kinda old fashioned though.