On Fri, Jul 07, 2017 at 07:04:27AM +0200, Rene 'Renne' Bartsch, B.Sc.
Informatics wrote:
>
> A lot of DNS server providers do not allow to modify the zones on the fly.
> My DNS server provider e.g. uses a hidden primary DNS for security reasons.
> Changing zones is only possible manually via the
Am 07.07.2017 um 07:10 schrieb Eliot Lear:
Just a caution that configuration for 2138 is not always straight
forward and in implementation and deployment sometimes has interactions
with other functions. I suggest that someone who really wants to do the
standardization here install a version
Am 07.07.2017 um 03:56 schrieb Alan Doherty:
At 09:40 06/07/2017 Thursday, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:
You think there should be a proprietary plug-in for any combination of DNS-provider
<-> ACME-client?
not at all
(only mentioned plugin as many acme clients use
At 09:40 06/07/2017 Thursday, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:
>You think there should be a proprietary plug-in for any combination of
>DNS-provider <-> ACME-client?
not at all
(only mentioned plugin as many acme clients use separately maintained plugins
for each/every challenge
On 7/6/17 10:40 AM, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:
> You think there should be a proprietary plug-in for any combination of
> DNS-provider <-> ACME-client?
The best case would be RFC 2138, but that's not something that can be
enforced.
> Creating DNS challenges on the fly makes
> You think there should be a proprietary plug-in for any combination of DNS-
> provider <-> ACME-client?
The question is backwards.
Does there have to be an open standard for any DNS provider/ACME client?
There is an important distinction.
___
Acme
+1
agreed the acme client design (plugins/modules/supported server architectures
etc) should really be down to the implementors/designers
as some smaller ones will only talk acme + http-01 + 1 specific server (say
acme client built into server/device)
others may offer many/all auth mechanisms
I agree with the others that have shared the opinion that this is outside
of the scope of ACME and this WG.
In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) there
> is already a protocol for clients to add/update/delete resource records on
> DNS servers. Most DNS server
Am 03.07.2017 um 18:28 schrieb Salz, Rich:
For a fully automated validation process the ACME-client needs some kind of
protocol/interface to add/update/remove the DNS challenge records on the
primare DNS server.
This is out of scope for our WG, but since we are looking at rechartering, it
> For a fully automated validation process the ACME-client needs some kind of
> protocol/interface to add/update/remove the DNS challenge records on the
> primare DNS server.
This is out of scope for our WG, but since we are looking at rechartering, it
could be brought within scope.
But I think
Am 03.07.2017 um 17:17 schrieb Salz, Rich:
is there any procedure proposed in the ACME documents to update the
ACME resource records on the primary DNS server (e.g. DynDNS/TSIG RFCs
2136/2845)?
No, there is no DNS-update protocol specified.
But what ACME resource records are you thinking of?
There isn't anything in the current spec(s), and it doesn't really seem in
scope for this work. That is, I don't think it's worthwhile to make a
one-off solution for updating the DNS with records for ACME, vs. improving
the state of DNS management in general.
That said, you can certainly
> is there any procedure proposed in the ACME documents to update the
> ACME resource records on the primary DNS server (e.g. DynDNS/TSIG RFCs
> 2136/2845)?
No, there is no DNS-update protocol specified.
But what ACME resource records are you thinking of?
13 matches
Mail list logo
