Re: [homenet] primary / secondary configuration

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
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>