15

It seems there's no way to tell bind that *-foo.example.com should resolve to eg. 10.1.2.3, while *-bar.example.com resolves to 10.2.3.4. Is there any workaround? Can some names eg. resolve with an external program? Or should I change bind to eg. PowerDNS?

I'm trying to avoid buying another SSL wildcard cert. (With wildcard certs, such as *.example.com, it's not possible to allow dots in the * part.)

Specifying all *-foo or *-bar names in the zone file is not an option, since I need to be able to create both type of addresses on the fly.

tuomassalo
  • 738
  • 2
  • 8
  • 22
  • Is there no way to add the domains to the zone on the fly as well? I have never seen partial wildcards used with bind. I cannot say for sure that it's not possible though. – David Houde May 03 '13 at 10:21
  • @DavidHoude: I'm afraid that adding on the fly is not an option, since any query that predates the addition will "pollute" name servers with an invalid answer. That creates problems that are quite rare but a bit nasty to resolve. (Of course time will fix the problem.) – tuomassalo May 03 '13 at 10:23
  • 1
    Does `$GENERATE` help you? – Celada May 03 '13 at 16:07
  • 1
    @DavidHoude - you could use dynamic update, but as the original poster points out you then run into the situation where a caching resolver may have cached a negative response before the record was added. To try and mitigate that you could lower the negative caching ttl to a very low value but not every resolver honors ttls scrupulously and some impose a practical minimum so results could be frustratingly variable. – Michael McNally May 04 '13 at 06:19
  • @Celada: the `*` part can be any `[a-z]` string (with length restrictions, of course). So, in my case `$GENERATE` does not help. Thanks for the tip though - might become handy for someone else who finds this page. – tuomassalo May 06 '13 at 06:54
  • Using a single wildcard certificate for both can be a security problem. It would allow an attacker to hijack connections intended for one of the two servers and undetected forward them to the other server. Depending on what those servers do it can range from just an annoyance to a full-blown compromise. – kasperd Jan 15 '19 at 11:08

2 Answers2

14

The reason why it doesn't work is because it's not defined behavior within the RFCs. It must be implemented as an extension of the software you're using. RFC4592 cements the definition of a wildcard record pretty firmly:

2.1.1. Wildcard Domain Name and Asterisk Label

A "wildcard domain name" is defined by having its initial (i.e.,
leftmost or least significant) label be, in binary format:

  0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)

Note the term label here. A label is the dot separated entity. If you have anything other than the asterisk in the label, it's not a wildcard.

You're kinda stuck here. Working within DNS, you need that dot that you're trying to avoid. Everything else is extensions to the server software and implementation specific.

Community
  • 1
Andrew B
  • 31,858
  • 12
  • 90
  • 128
1

RFC 6125 prevents having a generic certificate for nested subdomains. RFC 4592 and RFC 1034 prevent from having *-xxx.domain.com as a DNS entry.

So you only have two alternatives (which is not nice when trying to automate) :

  • Create a certificate per subdomain (there are free alternatives but might be complicated depending on your platform).
  • Create a full DNS entry per sub-service (which won't be sub-subdomains).
Community
  • 1
Ten
  • 111
  • 1