Tag Info

Hot answers tagged

36

It is possible to do this. At one point it was up in the air a bit until 4592 clarified that it should be supported. Just because it is possible doesn't mean it is supported by all DNS providers. For example, GoDaddy won't let you set up a wildcard in a CNAME record. In terms of whether it is advisable or not to do this, it depends on your usage. Usually ...


30

Yes, globbing expansion is alphabetical. From the Bash man page: Pathname Expansion After word splitting, unless the -f option has been set, bash scans each word for the characters *, ?, and [. If one of these characters appears, then the word is regarded as a pattern, and replaced with an alphabetically sorted list of file names ...


22

RFC2818 states: If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches ...


12

I added the line *.www IN CNAME my_webserver to my zone file in my bind config and that worked perfectly (ie. whatever.www.domain.com and whatever2.www.domain.com all pointed to my_webserver. It was also possible to to add exceptions to this by adding the line exception.www IN CNAME another_server so that ...


12

I shall show you. The configuration file server { server_name example.com www.example.com; root www/pub; } server { server_name ~^(.*)\.example\.com$ ; root www/pub/$1; } Test files We have two test files: $ cat www/pub/index.html COMMON $ cat www/pub/t/index.html T Testing Static server names: $ curl -i -H 'Host: example.com' ...


12

With BIND, you need a fake root zone to do this. In named.conf, put the following: zone "." { type master; file "/etc/bind/db.fakeroot"; }; Then, in that db.fakeroot file, you will need something like the following: @ IN SOA ns.domain.com. hostmaster.domain.com. ( 1 3h 1h 1w 1d ) IN NS <ip> * IN A <ip> With that configuration, ...


10

Yes, like Zoredache says, "this works". There are some caveats though with wildcards that it's worth knowing: The wildcard matches one or more labels, so in your case foo.bar.domain.com will be matched by the wildcard, but bar.foo.domain.com will return NXDOMAIN because the presence of foo prevents any sub-domains of foo from matching The wildcard match ...


10

The wildcard is working fine, which is why a.test.carrie resolves. Your issue is that test.carrie doesn't resolve. The reason is simply that you haven't got a record for test.carrie. *.test.carrie matches immediate subdomains of test.carrie, but matches neither test.carrie itself, nor any subdomains of subdomains of test.carrie. Add another record ...


9

Yes, this works.


9

The more specific DNS record overrides the wildcard. So your CNAME should override your wildcard A. What this might be is that you still have the domain name cached to the a record. Use the dig command: dig @yourdnsserver mydomain.freshdesk.com Normally it should return the CNAME.


8

According to the dnsmasq man page address=/#/1.2.3.4 should do the trick.


8

Just to add that Amazon Route 53 supports wildcards in any record type. So you can safely use Route 53 as your DNS provider.


8

No, this doesn't work. You can't legally have a CNAME at the root of your zone, because the SOA record belongs there too and it's not possible to have both a CNAME and other RRs attached to the same domain name. Your zone file would need to look like this: $ORIGIN example.com. @ IN SOA ...... IN A <server_ip> * IN A ...


8

When Wildcard SSL certificate is issued for *.domain.com, you can secure your unlimited number of sub domains over the main domain. For example: sub1.domain.com sub2.domain.com sub3.domain.com sub*.domain.com If the Wildcard SSL certificate is issued on *.sub1.domain.com, in that case you can secure all second level subdomains which are listed under the ...


8

I need to have a wildcard certificate that recognizes a prefix; so it would be www.*.domain.com. That means, www.one.domain.com, www.two.domain.com, www.three.domain.com, etc would all work correctly. Is this possible, and is there a SSL provider that can do this? No. According to the rules of the CA browser forum, RFC2818 and RFC6125 only one ...


7

Yes, there is not technical limitation for this; except if your CA prohibits this use explicitly. The most frequently limitation given by a CA is on the "physical servers", but may be someone limits even on IP basis. As an example, Geotrust Wildcard Ssl says: If you need to span the wildcard certificate across multiple physical servers, you may ...


7

Unfortunately you cannot do this. The rules for handling wildcards on subdomains are similar to the rules about cookies for subdomains. www.domain.com matches *.domain.com secure.domain.com matches *.domain.com domain.com does not match *.domain.com www.domain.com does not match domain.com To handle this you will have to obtain two ...


7

I think as it is *.example.com it is only valid for immediate sub-domains, it does not support nesting. You'll have to name it somethingmore.example.com, or buy either an explicit something.more.example.com certificate or another wildcard as *.more.example.com.


7

iptables does not know wildcards but used the CIDR method. F.e: -s 192.168.0.0/24 will cover all the hosts from 192.168.0.1 to 192.168.0.254. You can find more info about CIDR here


7

All SSL certificate do two things, authenticate that the holder of the certificate is who they claim to be, and encrypt the communications between client and server. When you pay more the levels of authentication (i.e. the checks that the certificate authority makes when you go to them to purchase a cert for your website) increase as do the levels of ...


6

Not really a wildcard, you can match IP Adresses by subnets: 192.168.0.0/16 192.168.1.0/24 192.168.2.0/25 Another way is to use ipranges like this: iptables -A INPUT --destination-port 80 -m iprange --src-range From_IP-To_IP -j ACCEPT There is a second module for --dest-range as well.


6

To my knowledge, there is no difference between wildcard and normal certificates. So long as you have full control over domain.com's DNS, then there's no reason not to use a wildcard. In fact, I would recommend it in your case. What are your specific concerns with them? (IMO, Redirects such as the one you suggest are always a bit of a fudge when they're ...


6

No wildcard per se, but you can specify a CIDR netmask: 192.168.0.0/16 The above would be the CIDR equivalent of the example you gave.


6

I seem to recall that *.domain.com actually violates RFC anyways (I think only lynx complains though :) Create a certificate with domain.com as the CN and *.domain.com in the subjectAltName:dNSName names field - that works. For openssl, add this to the extensions: subjectAltName = DNS:*.domain.com


6

This could be worth a new round of tests with current browser versions. My personal quick check results in: Firefox 20.0.1 seems to still not support this. It shows: This certificate is only valid for *.*.mydomain.com ...when surfing to https://svn.project.mydomain.com. Internet Explorer 9.0: The certificate of this website was made for another ...


6

If you ever put a computer in that domain, you will get bizarre DNS failures, where when you attempt to visit some random site on the Internet, you arrive at yours instead. Consider: You own the domain example.com. You set up your workstation and name it. ... let's say, yukon.example.com. Now you will notice in its /etc/resolv.conf it has the line: search ...


5

Wildcard DNS records have a single "*" (asterisk) as the leftmost DNS label, such as *.domain.com. Asterisks at other places in the domain will not work as a wildcard, so neither *development.domain.com nor development.*.domain.com work as wildcard DNS records. Source: Wikipedia


5

That should work fine, however, I'd probably use an A record, rather than a CNAME record to save that extra lookup. Also, bear in mind that this will resolve them to www.domain.com. but not redirect. So, for example, if a user starts accidentally using ww.example.com - they will be lead to believe that this is the correct web-address, which could cause ...


5

No, you can't have a wildcard there. Instead, use symlinks: ln -s /path/to/application-1.2.2/client/app /path/to/application/client/app and have the config read <VirtualHost *:80> Servername www.website.com DocumentRoot /path/to/application/client/app/ ErrorLog /var/log/apache2/logs/application.log </VirtualHost> ...



Only top voted, non community-wiki answers of a minimum length are eligible