On Thu, Oct 20, 2022 at 4:04 PM Daniel Migault <mglt.i...@gmail.com> wrote:
> Hi Paul, > > Some brief element of response to your questions. While you are raising > comments within a DISCUSS see your comment as a very high level question on > what is the content of the draft with many questions related not to that > draft. I am happy to respond, but there is nothing actionable that can be > done, so please be more specific. > ---------------------------------------------------------------------- > >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This might be my misunderstanding > > of homenet, so hopefully easy to resolve. >> >> The HNA (hidden primary?) to DM (primary) DNS communication using DNS >> Update >> needs some kind of authentication, TSIG or SIG0 ? > > no > >> While TLS gives you privacy, >> the DNS Update cannot be done with only TLS (as far as I understand it). > > please develop, but just in case, we do not use dns update to synchronize > the zone. we use AFXR/IXRF over TLS define din XoT. > >> I >> don't see any DHCP options to relay authentication information for >> automatic >> deployment? > > > The FQDN "Distribution Manager FQDN" and "Reverse Distribution Manager FQDN" > are sufficent to set a TLS session. > > So I don't understand how this would startup and be able to setup a >> secure DNS update channel ? >> > > TLS needs only names. The certificates binds the names to a key used for > the authentication. > So you are using transport security as a means for data authentication. https://datatracker.ietf.org/doc/html/rfc5936#section-5 states: Ensuring that an AXFR client does not accept a forged copy of a zone is important to the security of a zone. If a zone operator has the opportunity, protection can be afforded via dedicated links, physical or virtual via a VPN among the authoritative servers. But there are instances in which zone operators have no choice but to run AXFR sessions over the global public Internet. Besides best attempts at securing TCP connections, DNS implementations SHOULD provide means to make use of "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845 <https://datatracker.ietf.org/doc/html/rfc2845>] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" [RFC2931 <https://datatracker.ietf.org/doc/html/rfc2931>] to allow AXFR clients to verify the contents. These techniques MAY also be used for authorization. So you are going against the RFC 5936 SHOULD. I even had to look this up because I didn't know you could do an AXFR as a secondary from a primary without DNS level authentication. Apparently you can, but you SHOULD not. Unauthenticated AXFR is meant for zones that are open to the public and dns clients that want to grab a copy. It's not really meant for the actual primary <-> secondary channel. You might find that some DNS software insists on authentication if configured as secondary, as ACLs to just limit on IP address is really considered too weak. While using mutually authenticated TLS might be an option these days, most DoH/DoT/DoQ I believe only consider their use for privacy of unauthenticated connections. I'm not sure there are implementations and configurations out there that deploy DoH/DoT/DoQ with mutually authenticated TLS., Paul
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
