Added a slice of NS to be used when retrying queries. Also used with FindZoneByFqdn()
Adjusted 2 error messages given to better differentiate the returned error string
This patch adds code to only parse the HTTP response body as JSON if the
content-type header advertises the content as JSON. In my case, the
directory server was unavailable: it returned a 503 HTTP response code
with an HTML document, and the only thing lego reported was:
2016/04/04 19:12:56 Could not create client: get directory at 'https://acme-v01.api.letsencrypt.org/directory': invalid character '<' looking for beginning of value
This was caused by trying to parse the document body (HTML) as JSON,
without looking at the content-type header and returning the JSON parse
error.
- Reworked the code in dns_challenge.go to not assume nameserver is
port-less or defaults to 53. (messes up testing)
- Updated nameserver test to clear the fqdn2zone cache and return a dummy
SOA RR to make initial findZoneByFqdn call happy.
- Used publicsuffix library to determine if the "authorative" zone we found
is a public registry, in that case error out. (Also used by boulder btw)
- Removal of RFC2136_ZONE from help text
- Query nameserver directly to find zone we have to update
- During insert, make sure the new record is the ONLY challence.
(I had a few panics, hence 3 challences left. Not good.)
Prior to this commit, the checkDNSPropagation function was exiting
early if the TXT record could not be found on the recursive
nameserver, and thus the authoritative nameservers were not being
queried until after the record showed up on the recursive nameserver
causing a delay.
This commit changes that behaviour so that the authoritative
nameservers are queried on each execution of checkDNSPropagation when
possible.
