hello, I am developing with php and lescript client.
I think that
Domain validation in Let’s encrypt is possible when DNS have to be changed at my server.
so I have to wait until DNS propagate?
Is there an another way to prove domain validation?
thx.
Let’s Encrypt will check your authoritative nameservers - so you don’t need to wait for full propagation everywhere.
The other way would be to use the DNS challenge, that will check the same authoritative nameservers though, so there probably isn’t any real advantage.
I find only web site about DNS challenge => https://lincolnloop.com/blog/letsencrypt-dns-challenge/
I am using proxy server. I want to issue ssl before DNS propagate.
can you explain more about dns challenge?
or I can not issue ssl before DNS propagate?
The DNS challenge isn’t currently supported by the official client (certbot), although should be shortly.
All the bash and go alternate clients do support the DNS challenge though.
I wrote getssl (one of the bash client ) which can be used. For the DNS challenge the concept is that you add a token into your DNS to prove ownership / control of the domain. As long as your DNS provider has an API then that can be done automatically. There is an example configuration here
DNS “propagation” is mostly a myth invented to cover up incompetence by people managing DNS records.
DNS is a distributed name resolution system with caching, name owners get to specify how long the caches should last and there is little practical benefit to specifying very long lived caches of more than an hour or so. Administrators should plan in advance, so that if for example they expect to change some records tomorrow they run down the cache lifetimes first, then ramp them back up after making the change to give the best possible experience. Google’s google.com for example sets caches to last just sixty seconds for all its records.
However the perception by users that something has to “propagate” slowly when they make a change allows incompetents to justify the problems they cause as somehow inevitable, just part of “how DNS works”, you have to wait for it to “propagate”. I’ve seen people insist that it will take “a few hours” even for their authoritative servers to update “due to propagation”,
Another example, a moderately popular web forum changed host, they told their users “Due to DNS propagation it might take a few days for you to see our new server. Meanwhile to reach our site you’ll need to manually follow this alternate URL”. In fact they had written their new IP address into DNS as a CNAME string for the site name, which of course can’t work, but if anybody complained they’d be told to stop whining, it’s just DNS propagation. After a couple of days the people running the site grasped their mistake, pasted the correct A record into DNS and declared that now “propagation” had succeeded.
@parkhyunjoon - you need to ensure all Authoritative DNS servers for the name you want a certificate for are updated, this is not “propagation” and is purely under the control of your or your hosting supplier. Once the servers are updated, you don’t have to wait for any “propagation”, the Let’s Encrypt systems will interrogate these Authoritative servers themselves directly about the new domain.
If the names will be entirely new domains (e.g. you just purchased example.com and want a certificate for example.com or www.example.com) you should make sure NOT to request the certificate before you receive confirmation from the registrar that your domain is actually being served by that registry’s authoritative servers. For a domain you already control this isn’t an issue.
If you want certificates for names that aren’t (yet) known to Authoritative DNS servers for those names on the public Internet, you cannot get them from Let’s Encrypt, you will need to find a commercial CA which is willing to make such speculative certificates for names that don’t exist yet, which is unlikely to be free.
so Thank you for your answer.
I have one more question.
Where is the Authoritative server that Let’s Encrypt check first?
If I check the same server, maybe I can issue certificate much faster.
Thank you.
Your authoritative nameservers are those defined at your domain registrar for your domain. i.e. the place where you update your DNS records for your domain.
uhm… Maybe I can change server location using cloud server.
Can I know Authoritative server that Let’s Encrypt check first?
It checks the specific authoritative nameserver for your domain … what’s your domain name ?
ahahahahah I understand that
You say
Let’s encrypt check my server’s authoritative nameserver?
So your authoritative nameserver is ns-27.awsdns-03.com
(or for the full list, looks to be …
NS-1183.AWSDNS-19.ORG
NS-1788.AWSDNS-31.CO.UK
NS-27.AWSDNS-03.COM
NS-657.AWSDNS-18.NET )
This is a very, very valuable reply indeed. I especially like the advice to reduce the TTL at least two days prior to making authoritative DNS changes so the changes propagate must faster around the world. Of course, it actually is true that making a new website visible around the world may take up to 48 hours (you can see this happening using the propagation checker www.whatsmydns.net), so propagation in general is not a myth. But your reply makes it clear that accessing the authoritative DNS (the zone records) (as is done by LE clients) will be instantly successful following an edit to it. IMO, your comments, edited a bit so they aren't LE-specific, deserve much wider publicity.
Hah hah, 
. Have told this to other people before, too!
People should give Google Developers Console a try. I've been impressed with their DNS service. Can usually get "propagated" in less than 300 seconds 
To elaborate, this is only true if someone (unsuccessfully) tried to resolve your new domain before you registered it. They will get an NXDOMAIN whose TTL depends on a value in the SOA record. Some TLDs have a TTL of just one hour, others like .com or .net have 1 day.
If no one tried to resolve your domain, then it will be instantly visible upon registration.
NXDOMAIN TTL for .com and .net is 15 minutes (900 seconds) - where did you read 1 day ?
In the actual record:
$ dig com soa +multiline
; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> com soa +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41363
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 16
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;com. IN SOA
;; ANSWER SECTION:
com. 802 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. (
1470782054 ; serial
1800 ; refresh (30 minutes)
900 ; retry (15 minutes)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)Ah, the SOA record. Yeah, that still catches lots of people out.
Try asking a query that gets you an actual NXDOMAIN and observe the actual TTL you’re served. This TTL, not the “minimum” from the SOA is what actually counts in a working DNS implementation.
What trips people up here is that even relatively modern standards like RFC2308 skip between talking about DNS, the actual protocol, and talking about disk files used by BIND, a particular DNS daemon implementation that was created in the very early days of DNS. In BIND you don’t have to explicitly say what the TTL should be for every record, and if you don’t it will assume based on the SOA entry in the file. But the DNS protocol we’re all interested in isn’t about loading text files into a Unix daemon, and in that protocol there is always a TTL field in answers. That field determines how long the cache lasts.
So when you’re looking at dig output even though something is labelled “minimum” or “refresh” or whatever, it actually doesn’t mean anything at all, unless you’re a slave DNS server for the domain listed AND you have no vaguely modern means of updating your zone database.
This use of the SOA MINIMUM filed was explicitly deprecated in RFC 2308. However, this bit clearly states how the NXDOMAIN TTL should be constructed:
When the authoritative server creates this record its TTL is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
So curiously, the MINIMUM value actually serves as a MAXIMUM for the NXDOMAIN TTL, with the SOA TTL being able to lower it below that. The stuff you learn every day...
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.