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?

score 17 · Accepted Answer · edited Oct 03 '18 at 14:55

17

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";
};

edited Oct 03 '18 at 14:55

Patrick Mevzek

9,273
7
29
42

answered Jan 31 '11 at 10:56

Cakemox

24,141
6
41
67

I decided to try specifying the full domain in the RRs, so I changed: ns1 IN A 1.2.3.4 to ns1.nsdomain.com. IN A 1.2.3.4, this didn't work. Now all my requests return the SOA instead of NS/A. – Jon Wu Jan 31 '11 at 11:13
Can you update or add the new zone? – Cakemox Jan 31 '11 at 11:16
I added a new zone for nsdomain.com, and left the old "." zone alone. in the nsdomain.com zone, I added your ext.zone (renamed to nsdomain.zone). Now requests for any domain except nsdomain.com work like they're supposed to, they return ns1.nsdomain.com/ns2.nsdomain.com with the correct IPs(1.2.3.4/1.23.5). But, any requests for nsdomain.com itself return the SOA and no valid response :(. Close! – Jon Wu Jan 31 '11 at 11:24
You need to explicity add an A record for the apex. The wildcard doesn't cover that. I'll update my example. – Cakemox Jan 31 '11 at 11:27
Thanks, that works! Why do you haveto specify the A bit twice in this zone, but not in the "wildcard" zone (zone ".", my original ext.zone)? Got any good links to read up on this stuff? Thanks again! – Jon Wu Jan 31 '11 at 11:33
The RFCs linked in http://en.wikipedia.org/wiki/Wildcard_DNS_record are helpful. RFC-1034 has a brief description of the behaviour. – Cakemox Jan 31 '11 at 12:12

Pedro Lobito · Answer 2 · 2019-11-01T22:02:26.107

4

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

edited Nov 01 '19 at 22:02

answered Aug 14 '19 at 20:32

Pedro Lobito

419
1
4
12

score 0 · Answer 3 · edited Oct 03 '18 at 14:56

0

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.

edited Oct 03 '18 at 14:56

Patrick Mevzek

9,273
7
29
42

answered Jan 31 '11 at 10:56

Istvan

2,562
3
20
28

So I should add another zone for nsdomain.com, and set up the NS/A there for nsdomain.com? – Jon Wu Jan 31 '11 at 11:14
So if you have 2 zones like somedomain.com and nsdomain.com you have to setup the nsdomain related info in the proper zone. Short answer is yes, you have to set up another zone. – Istvan Jan 31 '11 at 12:13

score -6 · Answer 4 · edited Oct 07 '21 at 08:14

-6

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.

edited Oct 07 '21 at 08:14

Community

1

answered Jan 31 '11 at 11:01

poige

9,171
2
24
50

Why would be DNS wildcard evil? It is not evil at all.... – Istvan Jan 31 '11 at 12:12
http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html – poige Jan 31 '11 at 12:27
@poige 1) that URL does not resolve anymore, 2) you quote a document 8 years old at the time of your answer, now supposedly 16 years old which is like eternity on Internet, and 3) its snapshot at https://web.archive.org/web/20030922093331/https://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html it mostly boils down to "In particular, we recommend that DNS wildcards should not be used in a zone unless the zone operator has a clear understanding of the risks, and that they should not be used without the informed consent of those entities which have been delegated below the zone. " – Patrick Mevzek Oct 31 '19 at 20:37
I wrote this 8.+ years ago too still you're reading and replying. :) – poige Nov 01 '19 at 03:25
fwiw. the document is still up at a different url: https://www.iab.org/documents/correspondence-reports-documents/docs2003/2003-09-20-dns-wildcards/ – cstamas May 04 '21 at 11:20

Wildcard DNS with BIND

4 Answers4

Linked