Hi Paul, Thanks for the feedback. This is interesting. Please see my responses. I do not see any need to add some text, but I am happy to do so if you think that is needed.
Yours, Daniel On Sun, Oct 23, 2022 at 8:57 PM Paul Wouters <paul.wout...@aiven.io> wrote: > > 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. > > That is what we do. TLS provides enough security to replace TSIG / SIG(0). > 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., > > so we only considered DoT in the document. Other protocols are left for future work and only mentioned as potential examples. OARC35 [1] announced ongoing support for XoT by NSD, Unbound, BIND, PowerDNS and [2] is the commit "New configuration variables for client-side certificate". I believe we can reasonably say mutual authentication is on its way to become widely available. [1] https://indico.dns-oarc.net/event/38/contributions/857/attachments/802/1470/oarc35-xot-slides.pdf [2] https://github.com/NLnetLabs/nsd/commit/044c4b5d267dba69996267164395c6ed799e389b > Paul > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
