I have an AWS load balancer. AWS assigns a DNA name like:
data-vm-190.eu-west-1.elb.amazonaws.com
When I try to create a DNS CNAME record in Google Cloud, I get this error:
"Record data must be in the format server-1.example.com"
How can I get past this?
The solution is to append a dot (.) to the record name.
Adding a dot (period or .) at the end of a domain name declares a fully qualified domain name. Without the trailing dot, some DNS servers will treat the name as relative to the zone name.
In the hierarchy of the domain name system, the root servers are named .. The domain com is a child of the root servers. The fully qualified name for com is com.. Popular usage dropped the trailing root servers (dropped the .) but DNS still treats that character as important.
Related
I have an Azure Front Door environment that I would like to use to route a domain to an app service sub directory. But im having some issues setting it up
Domain: portal.example.com
Back End Pool: App Service - xxx.azurewebsites.net
I would like portal.example.com to route to xxxx.azurewbesites.net/portal
But for some reason im not able to do that and getting errors if i try to have it redirect with the slash " / "
"The domain and subdomains can be between 1 to 63 alphanumeric characters, must start and end with an alphanumeric character, and additionally can contain the '-' character in between. The top level domain must be between 2 to 61 alphabetical characters."
I have tried creating a routing rule and also tried using rule engine configuration.
seems there will be wrong route configuration. I have tried to replicate the same scenario.
Step1:
Created a front door environment with backend endpoint as
*****.azurewebsites.net
Step2:
Applying rule configuration to update route rule as
if request URL is "portal.example.com" then route the traffic to xxxx.azurewbesites.net/portal
refer this tutorial for more information. Found another similar post for reference.
I am looking at the stackstorm docker-compose file, and within it almost all containers have a line dns_search: . According to docker-compose documentation, dns_search is for the purpose of configuring search domains.
I am used to seeing this in context of transparently adding a domain to unqualified short domains. For example if I add dns_search: mydomain.com, I would expect "host1" to transparently resolve as "host1.mydomain.com".
I have never seen this set as a single dot . before. What is the effect/purpose of doing this configuration?
I'm posting the answer from the Stackstorm Git project issue see comment/"dns_search: .". Paraphrasing: it was useful in old versions of Docker before 2017, before the ndots configuration was available. Nowadays that configuration has no impact, and in fact has been removed from the stackstorm docker-compose file.
I believe this is because all domain names end in . under the hood, but browsers and other software abstracts this out.
For example. under the hood www.google.com is actually www.google.com.
So, in the docker-compose file, this would essentially be saying "Find me any domain"
A bit more detail on why there's an extra dot, if you're interested:
Domain name resolution is heirachical, reading right to left, with each block, separated by a ., being a step in the process. A DNS resolver will first find a source of ., which will be able to return the address for a resolver for the next block, until it reaches the final block, where it returns the full DNS record.
Extending EdwardTeach's answer:
#ytjohn effectively said they did in the past because putting dns_search: . configures the DNS search domains to be only . instead of inheriting the host ones. I can't confirm that because I didn't test it.
Now, I tested what docker-compose does today, and in a container, cat /etc/resolve.conf returns:
nameserver 127.0.0.11
options ndots:0
Where options ndots:0 is (from resolv.conf docs):
ndots:n
Sets a threshold for the number of dots which must
appear in a name given to res_query(3) (see
resolver(3)) before an initial absolute query will
be made. The default for n is 1, meaning that if
there are any dots in a name, the name will be
tried first as an absolute name before any search
list elements are appended to it. The value for
this option is silently capped to 15.
With ndots:0, all domains will be attempted using the absolute name first, only then using the search list.
How I came to this conclusion
The Github comment:
If you don't set this dns_search: ., then whatever the host has in search in their /etc/resolv.conf will get put into your container's /etc/resolv.conf.
This doesn't happen. My host has search domain[0]: broadband (macOS command: scutil --dns), and in docker containers, it doesn't show broadband (linux command: cat /etc/resolv.conf). Instead, it says options ndots:0
dns_search docs:
dns defines custom DNS search domains to set on container network interface configuration. Can be a single value or a list.
What is a DNS search domain?
It is the DNS service used to resolve hostnames that are not fully qualified, e.g. hostname will try hostname.example.com then hostname.website.com if your search domains list was example.com, website.com. More information on https://superuser.com/a/184366
In another repo (crossdock), their dockerfile had the comment:
`dns_search: . # Ensures unified DNS config.`
I'm trying to deploy my portfolio to my domain www.dillonbartkus.com with Surge.
The instructions are as follows:
I'm using a GoDaddy domain that I bought through Google Suite.
In the picture it shows a CNAME record with a hostname of www and # and a value of na-west1.surge.sh. When I try to do this in my DNS records, I can do the CNAME with www for the name, but when I try to do the # I get an error that says 'Enter your host name as "#", "sub-domain" '.
I have tried all different syntax for this, but it won't go through.
How do I add / edit the other to include # ?
You must delete all A & CNAME records on GoDaddy first, then follow the Surge documentation. GoDaddy only allows a CNAME www record to be added, not #.
The documentation states you should replace the CNAME # (apex domain) record with an A # record using Surge's IP.
Thus, on GoDaddy you must delete all existing A & CNAME records and add the following two records following a Type : Name : Value format:
CNAME: www : na-west1.surge.sh
A : # : 45.55.110.124
This had my domain resolving within 5 minutes.
https://www.godaddy.com/community/Managing-Domains/domain-DNS-with-surge-sh/td-p/24075
I have a hostname with dots and dashes. I need to use that hostname as the service name.
Suppose My hostname is Prasanna.abc.in. I want to make that hostname as a service name in the docker stack file.
Docker allows you to create a service with a "DNS name component". That's alpha numeric with dashes, and up to 63 characters. See the hostname spec on wikipedia. This does not let you use underscores or dots in the name since that is not a hostname component (dots are used to separate multiple components and underscores would be invalid).
For a FQDN, consider using a label on your service instead. You'll be able to give that label the full value of the hostname, and query by that label.
I'm a newbie in domain names, DNS etc.
I'm using surge.sh for deploying my app. Now I want to add a custom domain, that I registered using transIP, and I can't get it working. I set the IP address to 45.55.110.124, as they explain here. All together, I entered the following settings:
Name: *
TTL: 1 min
Type: A
Address: 45.55.110.124
And another one, exactly the same but then using name #:
Name: #
TTL: 1 min
Type: A
Address: 45.55.110.124
I created a test page that contains hello domain, inside a simple html file. Now, I deployed the page by moving to the folder that contains the html file and doing: surge ./ mydomain.io.
I waited over 5 minutes and nothing is changing.
Now, my questions are:
What am I doing wrong?
My domain provider suggests that I also use an IPv6 address, but which one should I use for Surge?
Why is there an option of setting TTL longer than 1 minute, who wants to wait longer before their deploy comes online?
For starters, you want to use the CNAME instead of A record if possible. The reason for this is that their IP address can possibly change out from under you when infrastructure changes / updates / re-deploys. If possible, remove the A records and create CNAME records pointing to na-west1.surge.sh. instead.
Next, assuming that they want you to point to the same IP as na-west1.surge.sh resolves to, that IP is different from the documentation (possible even due to my previous explanation). You can ping the domain or use the host utility to get the current IP address:
$ host na-west1.surge.sh
na-west1.surge.sh has address 138.197.235.123
Armed with this information, try changing to CNAME records first. If this isn't possible, then use the updated IP address that you get from resolving the their CNAME.