I have a device that is already mapped to domain.tld. I now want to create a wildcard for all subdomains *.domain.tld so that they are mapped to the ip of domain.tld, too.
How do I do this with dnsmasq?
In the dnsmasq.conf file, add the line
address=/.domain.tld/192.168.0.1
But use the IP you actually want as that end bit
While the accepted answer may have solved the author's problem, it is misleading as it suggests that the leading dot would match subdomains only, which is not true.
dnsmasq ignores any leading dots, so that
address=/domain.tld/192.168.0.1
is equivalent to
address=/.domain.tld/192.168.0.1
or even
address=/......domain.tld/192.168.0.1
As of now (dnsmasq v2.76), there is unfortunately no way to specify some things (server, address, ipset) for
a single domain name only, i.e. domain name without its subdomains
only for the subdomains of a domain name
The only thing you can do, is to specify something for a domain name and all its subdomain and have override it for specific subdomains, e.g.
address=/domain.tld/192.168.0.1
address=/sub.domain.tld/10.10.0.1
This single domain name only case, may be tackled with different options, such as host-record, srv-record, which may be sufficient in some cases, but certainly not in all. It won't work for example, if you really need to use the server or ipset option for a single domain name only.
Related
I have a Content Security Policy img-src I am unable to configure. The URL being requested has a dot country code suffix.
Example:
In Hong Kong = www.example.com.hk
In Thailand = www.example.com.th
Is there a way to add a wildcard to the end of a path? all the documentation I can find uses wildcards as a prefix.
I have tried www.example.com.* but it's an invalid source.
From MDN:
Internet hosts by name or IP address, as well as an optional URL scheme and/or port number. The site's address may include an optional leading wildcard (the asterisk character, '*'), and you may use a wildcard (again, '*') as the port number, indicating that all legal ports are valid for the source.
Nowhere does it say a wildcard can be used anywhere else.
While for you it may seem convenient in this specific context, in the bigger picture it would be a strange and probably dangerous thing to allow wildcarding the toplevel domain. Each toplevel domain is separately authoritative for the domains below it. There is no rule that says that www.example.com.hk and www.example.com.th must be owned by the same entity, and the same goes for the same-origin-policy. If that happens to be the case, it should be seen as coincidental.
You can use csp-evaluator to try out CSP values and see what they mean.
So I have to make an SPF record for a shared domain - 2 mailsystems, one is Office 365. Normally it looks like this:
“v=spf1 mx include:MAIL_SERVER include:spf.protection.outlook.com ~all”
It's quite straight forward, if it has been configured like this beforehand:
“v=spf1 mx include:MAIL_SERVER ~all"
But I have a different situation, where it is like this:
“v=spf1 mx redirect:_spf.PROVIDERSERVER.COM"
I am not sure, it I can do it like this:
“v=spf1 mx redirect:_spf.PROVIDERSERVER.COM include:spf.protection.outlook.com ~all”
Is it going to work like this? If not, then what should be changed?
The redirect is a modifier rather than a mechanism, and will only be considered after all other mechanisms have been tested. Unlike an include, once a redirect has been navigated it will not return to evaluate further terms, and although your positioning isn't invalid for clarity it should appear as the last term in the record since it will only be evaluated after all the other terms have been tested and passed over. ie its position in the SPF record will not determne its order of processing.
If any alternative mechanism term is satisfied in the record then the processing will stop at that term and return the evaluated condition, this includes any all mechanism that may be present. Therefore you cannot use redirect in combination with all, because the all mechanism will always be tested and satisfied first, and the redirect will never be processed. Of course, any all mechanism in the redirected domain's SPF would still apply if reached, unlike the -all in an include which would be ignored by returning not-matched to the include mechanism call. (Caveat: if a +all is encountered within a traversed include it will return matched, and trigger whichever result has been prepended to that include, usually a default + .)
It's worth noting that any redirected domain's own SPF may contain further redirects, and they would cascade as expected. However each redirect counts towards the lookup count limits.
So in summary you would want to use something like...
“v=spf1 mx include:spf.protection.outlook.com redirect:_spf.PROVIDERSERVER.COM”
I'm not sure on this, but here goes a guess! The docs say that redirect entirely replaces the current record, so I would expect it to ignore all other clauses - but it also evaluates from left to right, so maybe it would do the mx lookup first - you could test that manually.
I'm not sure why you're looking at redirect in the first place.
I suspect you could achieve what you're aiming for with:
"v=spf1 mx include:_spf.PROVIDERSERVER.COM include:spf.protection.outlook.com ~all"
Ass an addon to earlier answers.
From the RFC, section 6.1 on the redirect modifier it reads:
This facility is intended for use by organizations that wish to apply
the same record to multiple domains. For example:
la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"
In this example, mail from any of the three domains is described by
the same record. This can be an administrative advantage.
Note: In general, the domain "A" cannot reliably use a redirect to
another domain "B" not under the same administrative control. Since
the stays the same, there is no guarantee that the record at
domain "B" will correctly work for mailboxes in domain "A",
especially if domain "B" uses mechanisms involving local-parts. An
"include" directive will generally be more appropriate.
And, a redirect modifier MUST not be combined with an all mechanism:
For clarity, any "redirect" modifier SHOULD appear as the very last
term in a record. Any "redirect" modifier MUST be ignored if there
is an "all" mechanism anywhere in the record.
Considering all this, I would suggest to go with the syntax as provided by #Synchro. Although it is not against the rules, it is highly unusual to combine mechanisms with the redirect modifier.
As far as I know ( / understand https://www.rfc-editor.org/rfc/rfc7208#page-26) you can do the record from the last example. The redirect modifier will be used if everything else fails, meaning it will be the last thing checked).
Note that according to this same RFC the redirect modifier is recommended to be at the end of the record, before ~all.
Consider this:
example.com is equivalent to domain.com/example
this is also true
example.com/subfolder is equivalent to example.com/example/subfolder
as a result of the domain mapping / .htaccess
is this bad?
to further elaborate, I am hosting multiple domains on the same ip
Search engines has the concept of duplicate content and that is exactly what will happen in your case.
If example.com/subfolder and example.com/example/subfolder have same content and is not marked as canonical of one another, then search engines considers them as duplicate. Your own page competes against each other, which will hurt the SEO values. In order to solve it, pick your preferred domain and do <linl rel=canonical href='your preferred domain' /> the other one to that.
I seem to understand that a dot after the TLD doesn't matter, eg:
http://example.com/somepage/ == http://example.com./somepage/ (notice the dot after the TLD)
My question is: is this always the case? Or is it DNS or anything dependent?
In other words, will an extra dot after the domain work for everybody, no matter what the setup and the domain? (example.com., localhost., mycomputer.lan., 127.0.0.1., etc...)
Bonus question: why is that extra dot allowed?
Thanks
The extra dot, after the top level domain name, for example com. or gov. , is valid and optional as per DNS specifications. More details here.
However, this must not be used with anything that is not a domain name and that does not require a domain lookup. In your examples, it cannot be used with IP address and host name for above reasons. The optional last dot is guaranteed to work with any domain name. If mycom.lan is a domain name, where you are hosting a zone named "LAN" in your intranet, then the trailing dot can be used.
Bonus Answer: the last dot represents the "root zone". :), which must be looked up to find the nameservers of top level domains like com, gov, org, etc. Its however optional to type it. You can try this in the browser URLs.
Is it possible to do a DNS redirect so that mywebsite.com would remap to MyWebsite.com?
This would be for purely cosmetic purposes on the domain name alone. I understand that the domain name will ultimately resolve to a lower case version, and that all characters following the TLD are best kept in lowercase.
What I'd like to achieve is simply maintaining MyWebsite.com/whatever-in-lower-case in the URL bar.
DNS is not case-sensitive, so this is not likely to be possible. You can modify your bookmarks/home page links/embedded URLs/whatever to contain the case you want, though, but I'm not sure it's really worth the effort...