Simple Provisioning of Public Names for Residential Networks
draft-ietf-homenet-front-end-naming-delegation-27

   *  the CPE/HNA router is unaware of the process, and cannot respond
      to queries for these names and communications to these names
      require an Internet connectivity is order to perform the DNS
      resolution.  Such dependence does not meet the requirement for
      internal communications to be resilient to ISP connectivity
      disruptions [RFC7368].

If there is a host within the home network that is the DHCP/DNS server,
then this does not require further support from a CPE/HNA or internet
uplink. For example Linux openwrt with avahi and dnsmasq is a common
deployment of this: https://openwrt.org/docs/guide-user/base-system/dhcp
Arguably, one could say openwrt is the CPE/HNA in such case, provided
that user has their own domain they can send "dynamic DNS" updates for
on the public internet hosting their homenet zone.

   *  the CPE/HNA router cannot control the process.  Any host can do
      this regardless of whether or not the home network administrator
      wants the name published or not.  There is therefore no possible
      audit trail.

To be fair, even with dpeloying all of homenet, those hosts can still keep
doing this - choices made here does not affect this, so I don't see this
as a valid argument one way or the other.

   The DOI is also responsible for ensuring the DS record has been
   updated in the parent zone.

This sentence carries a LOT of process/protocol work. Will it use CDS? How is the
authorization boot strapped? Does it work for non-ISP generated zones, eg "toronto.nohats.ca" ?
If so, how does it handle delegation of NS and DS ?

   The information exchanged between the HNA and the DM uses DNS
   messages protected by DNS over TLS (DoT) [RFC7858].  In the future,
   other specifications may consider protecting DNS messages with other
   transport layers, among others, DNS over DTLS [RFC8094], or DNS over
   HTTPs (DoH) [RFC8484] or DNS over QUIC [RFC9250].

what does "protected" here mean? Privacy protection? Because if it is using
DNS Dynamic Updates, the data authenticity protection comes from a TSIG/SIG0 key.

   The main issue is that the Dynamic DNS update would also update the
   parent zone's (NS, DS and associated A or AAAA records) while the
   goal is to update the DM configuration files.  The visible NS records
   SHOULD remain pointing at the cloud provider's server IP address -

But isn't this simply a "forward" statement for the zone to the private IP
of the local DNS authoritative server within the local DNS recursive server?
That way, the recursive dns IP does not need to have a NS record at all, so
there is also no risk of accidentally pushing it out to public servers and
replacing the real NS records?

   *  By default, the HNA uses a single IP address for both the Control
      and Synchronization channel.  However, the HNA MAY use distinct IP
      addresses for the Control Channel and the Synchronization Channel
      - see Section 5 and Section 4.3 for more details.

Why does this matter and need mentioning? TSIG/SIG0 would not care about the
IP address used, and/or whether it is NATed?

   As such the HNA has a prior knowledge of the DM identity (X509
   certificate), the IP address and port number to use and protocol to
   set secure session.

Ah, so this is a preconfigured IP/name/TSIG/SIG0 key, and limits the HNA to only CPE
supported DNS providers? Either this locks in where users can host their homenet zone
based on CPE preconfiguration, or it is just a fancy way of saying "configure your DNS
server with your remote DNS settings" (which would not need anything of this document to run,
and I was hoping this document was going to provide some automation for this?)

   The HNA SHOULD provide the hash of the KSK (DS RRset), so the DOI
   provides this value to the parent zone.  A common deployment use case
   is that the DOI is the registrar of the Registered Homenet Domain and
   as such, its relationship with the registry of the parent zone
   enables it to update the parent zone.

This now means that the solution is limited to those scenarios that have:
- CPE support for homenet RFCs
- ISP support for CPE for HNA for DOI that supports DNSSEC DS submission via EPP, or
- A Registrar that is also DNS hoster AND supports DNSSEC AND supports CDS/CDNSKEY AND supports AXFR/IXFR
  AND supports homenet RFCs


I would argue these requirements are far more restrictive than:
- CPE with support for stock Dynamic DNS updates for itself only (eg client registrations,
  but could also be autoatic conversion of MDNS/.local to its local homenet zone.
- CPE that can run recursive with an authoritative zone
- Any DNS hoster that supports AXFR/IXFR, DNSSEC and CDS/CDNSKEY
- Any Register that supports DNSSEC

with the only difference that the latter one needs a one step registration of the initial DS record.


   Though the HNA may also later directly update the values of the DS
   via the Control Channel, it is RECOMMENDED to use other mechanisms
   such as CDS and CDNSKEY [RFC7344] for transparent updates during key
   roll overs.

If this is going to be a fully automated enduser CPE solution, this RECOMMENDED
is too weak. It should be a MUST because otherwise DNSSEC rollover is just impossible.


Section 4

this all seems to imply "registered domains". Can these be subdomains? Eg can I own nohats.ca
and configure one CPE for toronto.nohats.ca. and the other for amsterdam.nohats.ca. ? This involves
talking to NS for nohats.ca for sub delegation, but I don't see that mentioned anywhere ?

Section 4.5.1

How would the bootstrap work. I pick "paulhomenet.com" as my zone, but then my CPE doens't have
nameservers for it, so it does AXFR via the Control Channel ? And get a set of NS records back
that my CPE adds to paulhomenet.com ? And then it becomes authoritative? How is the ownership
of paulhomenet.com tested? if it is registered, who will be the registrar, registrant? Is ".io"
supported? Or other TLDs? Or will this all be under "nameyoupick.homenet.cpevender.com" ?

AXFR is normally based on authentication of domain name plus shared key. How does that work when
creating a _new_ domain name by the enduser? How can this be authenticated without knowing the
zone name ?

Section 4.5.3

   The default IP address used by the HNA for the Synchronization
   Channel is the IP address of the Control Channel.  To provide a
   different IP address, the HNA MAY send a DNS UPDATE message.

What does this DNS UPDATE message contain? It says NS records but what
name? And as this is the authoritative server sending an DMS UPDATE
message, it would need to send the RRSIG too, which means it needs to
set the entire NS RRset? Which means it needs to know the remote NS
records, but how can it do that without first already using the proper
IP address to talk to the systems?

Section 4.5.4:

If a deletion is processed, what happens with the domain name? Will all
its NS records be deleted and it is now a lame delegation? How is the enduser
supposed to get their domain under their own control again? Is it ever truly
theirs?


4.6 Securing the control channel

Isn't this channel DNS dynamic updates? Are these not secured by TSIG/SIG0 ?
Did you mean TLS only for privacy considerations and not security considerations?

Apparently this is not the case?

   A pure DNS solution using TSIG and/or SIG(0) to authenticate message
   was also considered.



   A way to translate this OAUTH2 token from HTTPS web space to DNS SIG(0)
   space seems overly problematic,

Why not use TSIG? That is literally the keyed hash of a blob, and the blob can
be an OAUTH2 token ?

ection 4.7

   Interface Binding:  the Hidden Primary Server will almost certainly
      listen on the WAN Interface, whereas a regular Homenet
      Authoritative Servers would listen on the internal home network
      interface.

Does that matter if either one provides a routable public IPv6 address?

   Limited exchanges:  the purpose of the Hidden Primary Server is to
      synchronize with the DM, not to serve any zones to end users, or
      the public Internet.

I thought it was serving endusers so that local things would keep working
with a broken internet link? Or at least "serve" its "resolver" part. And
also serve as auth server to take in DNS Dynamic Updates?

Section 5:

   Uploading and dynamically updating the zone file on the DM can be
   seen as zone provisioning between the HNA (Hidden Primary) and the DM
   (Secondary Server).  This can be handled via AXFR + DNS UPDATE.

I don't see how the start of this works, when the end user tells their CPE
the name of their local homenet zone ?

(also I think you mean AXFR/IXFR ? The DNS UPDATE would be the local machine
 talking to the local CPE ? Not between HNA and DM?)

   Note that there is no standard way to distribute a DNS primary
   between multiple devices.  As a result, if multiple devices are
   candidate for hosting the Hidden Primary, some specific mechanisms
   should be designed so the home network only selects a single HNA for
   the Hidden Primary.  Selection mechanisms based on HNCP [RFC7788] are
   good candidates.

This seems rather under specified. If there is only one, how is it found and
used? I was expecting that the domainname configured on the CPE would be
queried for DNS UPDATES by clients. But looking at RFC2136 Section 4:

   From a requestor's point of view, any authoritative server for
   the zone can appear to be able to process update requests, even
   though only the primary master server is actually able to modify the
   zone's master file.  Requestors are expected to know the name of the
   zone they intend to update and to know or be able to determine the
   name servers for that zone.

   If the requestor has reasonable cause to believe that all of a
   zone's servers will be equally reachable, then it should arrange to
   try the primary master server (as given by the SOA MNAME field if
   matched by some NS NSDNAME

This would be only one possible target based on the domainname given to
a device via DHCP. What "some specific mechanism should be designed" will
be deployed for the clients (eg my phones, laptop and TV ?) I think the
only real chance they have of doing this (without waiting 10 years for
all our electronics to cycle/get updated) is standard the SOA MNAME's IP
address, eg RFC 2136 DNS Dynamic Updates. My devices already support this.

So that redefines the above problem to "Who becomes the Hidden Primary",
which I assumed was the CPE supporting this framework ? And if there
are more than one CPE that can do this, it should be configured by
the user to be done only by one CPE - similar to have a user should
ensure there is only one DHCP server running in the network ?

Section 5:

        First the HNA (primary) notifies the DM (secondary)

The entire document would have been so much more readable if HNA and DM
had not been introduced and primary/secondary was used througout.

   The HNA SHOULD apply an ACL on inbound AXFR requests to ensure they
   only arrive from the DM Synchronization Channel.

Unless the CPE is preconfiguted with service providers, these ACLs cannot
come by default? Also, if this channel uses TSIG (which also needs preconfiguration)
then it can already ACL this based on the known shared secret. No IP based
ACLs needed (which are risky to put into CPE firmware as networks change)

Section 7:

Why can't the HNA be the local authoritative server for clients? Why should
this functionality be split in two? It just means another recursive resolver
needs to query the HNA (and have it configured as forwarder) for the local
homenet zone (in case uplink goes down). For example, this could be a single
instance of the Bind DNS server dong both authoritative and recursive DNS.

Dropping received queries for DNS servers is always a bad idea, as it just
causes the client to retransmit. Always returning an error is the common
DNS reply strategy. This section goes against common best practise for DNS
servers.

Section 9:

  [RFC7368] in Section 3.7.3 recommends DNSSEC to be deployed on both
   the authoritative server and the resolver.  The resolver side is out
   of scope of this document, and only the authoritative part of the
   server is considered.

But if things must work without an internet connection working, then the
resolver needs to be configured for the homenet domain to ask the HNA
and not go the regular upstream path. So it should be in scope I believe.

   Typically, the DS RRset can be updated
   manually in the parent zone with nsupdate for example.

I don't think this applies to "typical DS". The DS RRset lives on the "wrong"
side of the zone cut. A dns update client is would not have permissions to
update its parent zone with dns updates, only its own child zone. So this
would be better done by pushing a CDS record and let the parent pull the CDS
and recreate its own DS record. This method is not widely supported by TLDs,
and I dont know how this solution would work for second or third level domains,
eg if I use provider X to host nohats.ca, and provider Y for my home internet
and I want toronto.nohats.ca to be my home network name using CPE vendor Z.

Section 10:

   The ISP SHOULD ensure that the DNS cache has expired before re-
   assigning the prefix to a new home network.

How does it do that? It can't send queries to get the data for TTL anymore,
since the network already got renumbered and returned and the NS servers
removed. The records now only live in worldwide caches. You don't know the TTL.
Unless you grabbed the data just before getting it returned. But that is also
unlikely, eg imagine a user taking down their CPE because they moved house.
From the ISP point of view the network just vanished including all its nameservers
for it (the public ones will work for a while but will the ISP act within that time?)

And what of the CPE/HNA set TTLs on data of 1 year ?

The TTL math in section 10 makes no sense to me as the CPE/HNA could set it to whatever
it wants. The ISPs secondary servers cannot change the TTL (it is protected by DNSSEC
from being modified)

Section 11:

The Privacy Considerations section is a bit hard to read. But in the end it comes down
to "dont make your homenet DNS publicly reachable if you want privacy". Indeed, I find
publishing my entire home network into public DNS a serious risk. DNS scanners will end
up scanning for well known names of popular brands of TVs, washing machines, saunas,
lightbulbs, etc. Or they will start scanning zones based on well known ISP based secondary
services. It is almost as if the better solution would be to only provide a publicly reachable
homenet VPN server, that provides both DNS and the only working routes from my (remote) devices
on my to my home network based devices.

The privacy and security of the DNS names is a small thing if homenet puts all my devices on
the public IPv6 network. Scanning IPv6 is still fairly hard to do, even of endusers /64. And
putting those IPv6 addresses in DNS makes it much much easier to find all these devices and
use their exposed services to compromise the device and/or network that they are in. These
considerations are completely missing from the Security Considerations Section 12.

Appendix A:

   This document does not deal with how the HNA is provisioned with a
   trusted relationship to the Distribution Manager for the forward
   zone.

But that is core to the protocol ?

   Similarly, if the HNA is provided by a registrar, the HNA may be
   handed pre-configured to end user.

How can that be if the user decides on the homenet network name it wants to use?

Appendix C:

The example zone used is n8d234f.r.example.net. I thought the idea was for the user
to have a memorable zone it can use, eg sharing with friends. Was I wrong?

with the "dm_acl"    : "2001:db8:1234:111:222::/64", set, what happens to the zone
"n8d234f.r.example.net." when the user got unplugged and replugged and lives on a
different ip range now ?

I support Warren, John and Paul’s DISCUSS positions.

Thank you for addressing my COMMENTs.

This isn't my only concern with this document but Warren Kumari has broadly covered the space with his own DISCUSS.  I did want to highlight this one, though.  I think it should be relatively easy to fix.

Section 4.6, "Securing the Control Channel", almost-mandates security:

```
   The control channel between the HNA and the DM MUST be secured at
   both the HNA and the DM.
```

It does not, however, specify any mandatory-to-implement security mechanism, although it provides an interesting and wide-ranging discussion of many options.  It's very difficult for me to see how interoperable implementations can be built, that comply with the quoted requirement, by someone working from the current specification. It does seem from other hints in the document that the authors consider TLS mandatory even though it's not stated as such in Section 4.6. For example, Security Considerations subsection 12.1 says,

```
   The channels between HNA and DM are mutually authenticated and
   encrypted with TLS [RFC8446] and its associated security
   considerations apply. 
```

Another hint that TLS is viewed as mandatory-to-implement is from a different document also currently under review, draft-ietf-homenet-naming-architecture-dhc-options-21 (Sections 4.2 and 4.3):

```
      The bit for DNS over TLS [RFC7858] MUST be set.
```

I talk about this more in my comment on Section 4.6, but there's just no way to read this paragraph as mandating TLS:

```
   Secure protocols (like TLS [RFC8446]) SHOULD be used to secure the
   transactions between the DM and the HNA.
```

It doesn't even quite mandate secure transport in general, since it's a SHOULD (so presumably there are times when an implementor can sensibly ignore it, though these are not discussed). What's more, TLS is only given as an example of one transport that would be OK, not as the mandatory-to-implement secure transport. As written, any secure transport, for example TCP-AO, would satisfy this SHOULD.

Based on the hints throughout the rest of the document set, that the authors think of TLS as the mandatory-to-implement base transport, I think this section should be rewritten to match that expectation.