Daniel Migault wrote on 07/06/2019 22:27:
Hi,
We are looking for a simple way to configure the primary / secondary
DNS setting between the homenet and the outsourcing infrastructure.
The exchange of these information is done over a secure channel - let
say TLS. While we coudl re-define a configuration template / mechanism
we believe that re-using widely deployed libraries would ease the
deployment.
The HNA is responsible for building / signing the zone and
synchronising the zone with the outsourcing infrastructure. To build
the zone some elements of the infrastructure are needed such as the NS
and IP for example. One way to enable the transmission of information
from the the outsourcing infrastructure to the homenet is to use an
well known fqdn hna.example.com <http://hna.example.com> with an AXFR
request. Does it sound reasonable ?
Stating the obvious: if an HNA is going to sign a zone, it has to own a
globally unique delegated zone.
I see 3 ways of delegating a piece of namespace and gathering the input
for the SOA:
1) HNA is pre-configured with one or more DNS outsourcing providers in
the admin GUI e.g. <example.com>.
User picks one via LuCI.
HNA creates a proposed zone name e.g. <HN-ULA>.<example.com> or asks for
a proposal from the user.
DNS Outsourcing Infra confirms that <HN-ULA>.<example.com> is unique via
the parent zone <example.com>
2) HNA is pre-configured with one or more DNS outsourcing providers in
the GUI e.g. <example.com>.
User picks one via LuCI.
HNA contacts <example.com>.
HNA receives the zone name <HN-XXX>.<example.com> from the DNS
Outsourcing Infra.
3) HNA owner purchases a nice name from a registrar e.g.
<me.mydomain.com>. Domain Registrar and the DNS Outsourcing Infra
example.com, don't share a common parent zone.
IMHO for (1) and (2) we already have working outbound DNS resolution in
place, and the HNA can gather SOA variables using either a simple SOA
lookup of the parent zone, or via a SOA + and AXFR to fetch a template.
(1) dig -t soa example.com +dnssec -> NS1 NS2 + AAAA RR + timers of the
parent -> copied 1:1 to the child zone <hn-ULA>.example.com.
Obvious disadvantage: everyone is tied to the same infra, timers, and NS RR.
Advantage: cheap and cheerful.
(2) dig -t soa example.com +dnssec|perl extract_MNAME_from_SOA.pl; dig
@$MNAME -t axfr <hn-ULA>.example.com +dnssec|perl extract_SOA_variables.pl;
The MNAME in example.com SOA would contain the name of the DM config
server/template server.
The DM config server/template server would either have to generate the
template on the fly, or have one pre-configured during sign up.
(3) would have to be out of band or require something much more complex.
On the other hand, the outsourcing infrastructure needs to know the
fqdn of the hna. One way to provide that information could be to
re-use DNS update updating the SOA of hna.example.com
<http://hna.example..com>. The fqdn of the hna would be indicated
using the MNAME field. Does it sounds reasonable as well ?
Yours,
Daniel
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
