Subject: [dnssd] The DNSSD WG has placed draft-sctl-service-registration in state "Call For Adoption By WG Issued"

From: IETF Secretariat <[email-masked]>
Date: Tue, 03 Jul 2018 12:21:33 -0700

The DNSSD WG has placed draft-sctl-service-registration in state
Call For Adoption By WG Issued (entered by David Schinazi)

The document is available at
https://datatracker.ietf.org/doc/draft-sctl-service-registration/

---

From: David Schinazi <[email-masked]>
Date: Tue, 03 Jul 2018 12:22:36 -0700

Hi everyone,

This email starts a three-week adoption call for draft-sctl-service-registration <https://tools.ietf.org/html/draft-sctl-service-registration> .
The call will run until the week after IETF 102.
Please review this draft between now and Montreal, we will also discuss it in person in Montreal.

Thanks,
David

> On Jul 3, 2018, at 12:21, IETF Secretariat <[email-masked]> wrote:
> 
>

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 04 Jul 2018 10:50:20 +0200

David Schinazi <[email-masked]> writes:

> Hi everyone,
>
> This email starts a three-week adoption call for
> draft-sctl-service-registration
> <https://tools.ietf.org/html/draft-sctl-service-registration> .

I provided some comments on the -00 of this draft back in October[0].
The -01 version addresses one of them (related to how to specify the
TTL), but the others are still relevant, I think.

I don't believe these comments should block adoption, but I figured this
would be a good time to repeat them, since I received exactly zero (0)
responses on my previous email... :)

Relevant parts of the previous comments below:

- It is not clear how to find the server to register with: Section 2
  refers to RFC2136 and RFC3007 for the DNS Update mechanism, and to
  RFC6763 Section 11 for information on how to discover the zones to
  attempt registration in. So from my best reading of this, the client
  should discover the relevant zones, then just send its signed updates
  to any authoritative server for those zones. However, this prevents
  implementing the registration logic as a proxy (as I'm currently
  doing). So I feel like there should be a SRV lookup in there
  somewhere? I seem to recall Stuart telling me that this is indeed
  specified somewhere, but my google fu is failing me right now, and in
  any case it's not clear from the draft how this process is supposed to
  work.

- Address-based ACLs: Obviously, in most cases a client should only be
  able to perform registration if it is actually on the right network.
  Firewalling off the ports from outside the relevant networks is a way
  to ensure this, but it is somewhat of a crude tool. For one, it
  prevents a single registration server / proxy from serving multiple
  networks[1]. For another, it prevents a use case where a client is only
  allowed *initial* registration (when the key is first cached) from
  inside the network, but is allowed to subsequently update the same
  record from anywhere. This is useful to, for instance, have my laptop
  maintain my-laptop.myhome.example.org even when visiting another
  network.

  So another way to ensure this source verification is needed, I think.
  The way I implemented it is to have the registration server only speak
  TCP; that way, source address spoofing is not possible (as that would
  make the handshake fail), and the server can simply implement a
  straight-forward ACL policy.

- It is not quite clear to me whether the sleep proxy described in
  section 4 is an optional feature or if its meant to be mandatory.
  Stuart explained its usefulness for devices that power off when not in
  use, requiring this function will mean that registration servers will
  need to be on the local link, which is somewhat limiting. Also, the
  implementation complexity goes way up (I certainly don't plan to
  implement this feature :)). So I think having a way for the server to
  signal "no, I can't perform sleep proxying" to the client would be
  good to allow things to fail in a graceful way.

-Toke

[0] https://mailarchive.ietf.org/arch/msg/dnssd/n1H-OGDx8BioVqjTuDTz6jmUmoo

[1] I'll add that since the -01 draft now says that the update should
    always be for .local, how is a registration server supposed to know
    which domain a client wants to register in? By source address only?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Jul 2018 09:45:40 -0400

>  any case it's not clear from the draft how this process is supposed to

I thought it was specified somewhere too, but it doesn't seem to be explicitly stated in RFC 6763.   In general, RFC 2136 says that any server authoritative for the zone can be sent a DNS update for that zone, and is directed to preferentially send updates to the master if it is reachable.

That said, Apple's implementation looks for a _dns-update._udp.<domain> SRV record, and it might make sense to specify that explicitly.   Also, this has been specified in such a way that the client need do minimal work before firing off the update.   Stuart and I have talked about using anycast to make this a single-transaction service in the default case, which would be particularly nice for low-power devices.   I didn't have time to spec that out in this version, but it's definitely an intended feature.

>  maintain my-laptop.myhome.example.org even when visiting another

That's a good point—I hadn't thought about enabling the off-site update.   There are security implications of that, of course: it could be a foothold for an informed attacker.   I'm not convinced that it should be permitted by default, and indeed in the homenet scenario, for example, I would say that it should not be permitted by default.   There may be scenarios where it makes sense.

As for the address-based ACL, that's in fact what I'm using in the prototype.   Another way to do it would be to have an anycast listener in, for example, each homenet router, which only accepts updates from the local wire.   This listener would add its signature to the message and forward it in an encapsulation.   If we allow for a two-packet exchange for service registration, which I think is desirable, this may be worth specifying.   In an LLN I don't think it would be hard to do—it could be done at the edge of the mesh.

>  straight-forward ACL policy.

This could also work, or we could use DNS cookies, but it breaks the LLN use case.

>  good to allow things to fail in a graceful way.

Sleep proxy is advertised as a service, so devices that don't implement it can not advertise it.   However, this breaks the LLN single-exchange use case, so I think there's an argument that it should be required on LLNs.   That said, this is existing technology, which is widely deployed, and often deployed in very tiny devices.   I don't think it's hard to implement, and I am a little surprised that you think it is.   Is it really that it's hard to implement, or is it that you don't think it's important, don't know how to implement it, and therefore would prefer not to?   That's a perfectly valid position to take, but it's not what you said.

>    which domain a client wants to register in? By source address only?

I think that in a network where there is more than one domain in which a registration could occur, something like that would indeed be required.   My base assumption in writing this text (which Stuart hasn't seen yet, because he's on vacation) is that in most cases where this will be used, either there will be only one registration domain, or else the link to which the service is attached will be sufficient to decide what domain to use.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 05 Jul 2018 19:02:04 +0200

Ted Lemon <[email-masked]> writes:

> That said, Apple's implementation looks for a
> _dns-update._udp.<domain> SRV record, and it might make sense to
> specify that explicitly.

Yeah, I think Stuart explained this to me at some point. But I'm not
sure if "ask Stuart" is sufficiently discoverable, so mentioning it in
the document might be a good idea ;)

> That's a good point—I hadn't thought about enabling the off-site
> update. There are security implications of that, of course: it could
> be a foothold for an informed attacker. I'm not convinced that it
> should be permitted by default, and indeed in the homenet scenario,
> for example, I would say that it should not be permitted by default.
> There may be scenarios where it makes sense.

Sure, by all means hide it behind a big "I know what I'm doing" button,
or something. I just don't want the standard to rule out the possibility
entirely.

> This could also work, or we could use DNS cookies, but it breaks the

Wouldn't it be possible to specify both?

> Sleep proxy is advertised as a service, so devices that don't
> implement it can not advertise it.

Ah, great. As long as its in spec to not advertise that service, that's
good enough for me.

> However, this breaks the LLN single-exchange use case, so I think
> there's an argument that it should be required on LLNs.

Hmm, I'm not sure I quite understand what you mean by single-exchange
use case, then?

> That said, this is existing technology, which is widely deployed, and
> often deployed in very tiny devices. I don't think it's hard to
> implement, and I am a little surprised that you think it is.

I said "harder", not "hard" ;)

What I mean is that to do sleep proxying (as I read the spec) requires
raw sockets, or some other way to answer neighbour requests on the
sleeping device's behalf. Which generally tends to be a privileged
operation, and raises the complexity from "just answer DNS requests".
And of course it requires link-local presence, which means it either
requires automation (such as in homenet), or lots of manual
configuration.

> Is it really that it's hard to implement, or is it that you don't
> think it's important, don't know how to implement it, and therefore
> would prefer not to? That's a perfectly valid position to take, but
> it's not what you said.

I think it's not important enough to put in the effort to implement it,
basically.

Note that this is for my use case; I can totally agree that requiring it
for homenet makes sense; but service registration can be useful in other
contexts as well...

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Jul 2018 18:29:00 -0400

> the document might be a good idea ;)

Agreed.

> or something. I just don't want the standard to rule out the possibility

Sure.

> Wouldn't it be possible to specify both?

I'm coming around to thinking this might be a good idea for some cases, but I also think that the anycast use case needs to be preserved, and that ought to be a simple two-message exchange in the success case.   The problem is deciding when TCP makes sense.

I think there are three cases we should consider here:
Homenet
Campus net
LLN
In the case of Homenet, I think TCP works fine, except that we can expect to see LLNs in most homenets going forward.   So TCP doesn't entirely work fine, and managing this edge case is tricky.   We'd need to define a heuristic for how the LLN edge router(s) validate updates from the LLN.

Actually, I think the Campus net case is pretty much the same.   So okay, that means that if we can figure out how to do one thing on LLNs and another thing in all other cases, maybe that's the answer.   I'd just as soon avoid DNS cookies—they don't add any value over TCP in this case as far as I know.   We'd have to forbid 0RTT, because the whole point of using TCP is to validate that the IP address that sent the update can receive a reply.

> Hmm, I'm not sure I quite understand what you mean by single-exchange

An LLN device should be able to register with a sleep proxy without first discovering a specific sleep proxy with which to register.   It should IOW be able to send a single DNS Update packet to an anycast address and get back a response of "yes, we have set up a sleep proxy for you."

> requires automation (such as in homenet), or lots of manual

Right.   This is actually a really key point that we'd utterly missed.   Since we are supporting multiple subnets, the current sleep proxy paradigm doesn't work.   That doesn't mean it _can't_ work, but it is different than what we'd had in mind, and is in fact more work than we'd been assuming.   Thanks for poking a hole in this blind spot!

I'm not sure what the answer is here—on a homenet it's not too hard to imagine a solution; on an LLN I think it's not a problem, but it's definitely a problem for the campus use case.   I don't think this is an impediment to adoption, because the registration protocol is useful whether it supports the sleep proxy use case or not.   But we need to figure out how to address this.

> for homenet makes sense; but service registration can be useful in other

I'm curious if I've listed the contexts that you care about, or if I missed some.   What contexts do you have in mind?

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 10 Jul 2018 14:48:50 +0200

Ted Lemon <[email-masked]> writes:

> I'm coming around to thinking this might be a good idea for some
> cases, but I also think that the anycast use case needs to be
> preserved, and that ought to be a simple two-message exchange in the
> success case. The problem is deciding when TCP makes sense.

Couldn't that just be left up to the client? I.e., the network SHOULD
provide both, clients MUST support both and if the network only supports
one use that; but if the network supports both, the client is free to
pick whatever makes the most sense for its use case.

I'm a little worried that this would lead to too many permutations to
test interoperability, and/or just lead to cherry-picking. But it's
definitely easier to specify than coming up for rules for when to do
what... :)

> An LLN device should be able to register with a sleep proxy without
> first discovering a specific sleep proxy with which to register. It
> should IOW be able to send a single DNS Update packet to an anycast
> address and get back a response of "yes, we have set up a sleep proxy
> for you."

Right. And how is it supposed to discover which anycast address to use?
Or is that going to be a special address assigned as part of the
standard?

> Right. This is actually a really key point that we'd utterly missed.
> Since we are supporting multiple subnets, the current sleep proxy
> paradigm doesn't work. That doesn't mean it _can't_ work, but it is
> different than what we'd had in mind, and is in fact more work than
> we'd been assuming. Thanks for poking a hole in this blind spot!

Haha, you're welcome ;)

> I'm not sure what the answer is here—on a homenet it's not too hard to
> imagine a solution; on an LLN I think it's not a problem, but it's
> definitely a problem for the campus use case. I don't think this is an
> impediment to adoption, because the registration protocol is useful
> whether it supports the sleep proxy use case or not.

Agreed.

> But we need to figure out how to address this.

Hmm, only thing that comes to mind is doing the proxying at layer 3
instead; i.e., advertise the proxy's address in DNS and forward packets
to the sleeping device using encapsulation or (*shudder*) two-way NAT.
That would require the proxy to stay in the loop for everything to be
transparent, though, so not sure if it's a good solution...

> I'm curious if I've listed the contexts that you care about, or if I
> missed some. What contexts do you have in mind?

I think my use case is covered by the campus use case, more or less.
I.e., a managed network where devices should be able to register
themselves automatically in (global) DNS with a minimum of
configuration.

I use it to find devices on my network; if I just configure devices to
run the registration daemon, and put the right discovery PTR records in
the network-local recursive resolver, I will be able to find them by
hostname on the local link, and the registration server can be
configured to (selectively) put things into global DNS as well. Since
I run this on different networks, I run registration proxy in the cloud,
where it services several networks (with different domain names). So
anything that requires link-local presence is a hassle to support...

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jul 2018 00:10:08 -0400

I just did a somewhat larger-than-expected update to the document to
capture Toke's comments thus far.   I also got a surprise guest review from
a friend of mine, Tamara Kemper, who revealed a few opportunities to make
the document clearer and better scoped.  In the process of doing these two
things I noticed that I'd fairly significantly misstated how SRV records
work and left out some important details.   The new document fixes all of
these things (I hope).   Sorry for adding so much text during an adoption
call, but I didn't want to leave it for later because it would have made
reading the document kind of unpleasant for Stuart, who I hope will review
it this weekend, and if I hadn't done it now it would have taken at least
twice as long later.  The good news is that I'm pretty chuffed about the
quality of the document now.

You can see the diffs here:
https://github.com/StuartCheshire/draft-sctl-service-registration/commit/51b7cb54300fea7e44e8e7dee49c17e9f598b3ba
The text of the document is here:
https://github.com/StuartCheshire/draft-sctl-service-registration/blob/master/draft-sctl-service-registration.txt

I don't think this substantially changes what we'll discuss in Montreal,
but attendees who want to give technical feedback at the mic should
probably read this version.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 12 Jul 2018 12:40:29 +0200

Ted Lemon <[email-masked]> writes:

> capture Toke's comments thus far. I also got a surprise guest review
> from a friend of mine, Tamara Kemper, who revealed a few opportunities
> to make the document clearer and better scoped. In the process of
> doing these two things I noticed that I'd fairly significantly
> misstated how SRV records work and left out some important details.
> The new document fixes all of these things (I hope). Sorry for adding
> so much text during an adoption call, but I didn't want to leave it
> for later because it would have made reading the document kind of
> unpleasant for Stuart, who I hope will review it this weekend, and if
> I hadn't done it now it would have taken at least twice as long later.
> The good news is that I'm pretty chuffed about the quality of the
> document now.

Thanks for the update! I think this version addresses my concerns from
the previous round. :)

A few other comments based on a quick read-through:

- Since registrations are always done with .local, it is up to the
  registration server to decide which domain(s) the registration ends up
  in, right? How is it supposed to do that if servicing multiple zones?
  Just based on source IP?

- The document says that clients must generate their own reverse PTR
  records. Should the server be able to do that on the clients behalf?
  It may be a matter of policy which ranges have reverse domain
  delegations...

- Related to the above, is it permitted for the registration server to
  modify the records submitted by clients before putting them into
  DNS? For example, to add PTR records, or to remove a subset of the
  records etc? The alternative to modifying would be to reject the whole
  registration if a subset is not admissible. If the server *is* allowed
  to modify things, should it communicate back to the client what it
  really did?

- You mention in the text that a network may use a different domain than
  ip6.arpa for reverse PTRs. How does that work? Won't clients always
  do reverse lookups to ip6.arpa?

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jul 2018 09:25:13 -0400

> Thanks for the update! I think this version addresses my concerns from

Great!

>   in, right? How is it supposed to do that if servicing multiple zones?

I think that that's up to the implementation.  It could do it based on IP
address, or as I suggested in the document it could have a whitelist that's
maintained by an administrator, based on the key or the name or the service
type.   As long as it does the same thing every time, the details are (I
think) immaterial.   However, this is worth thinking about—if you can come
up with something that doesn't work, we should document it.

>   It may be a matter of policy which ranges have reverse domain

Interesting.   I did it this way because I don't want to get into the "PTR
is bad, get rid of it, no it's good, I want it" argument. :)

It could certainly be a site policy to auto-add a PTR record.   Since the
content of the PTR record is fixed, this would just have the effect of
making PTR records non-optional, not of changing what got stored in the
update.   I would be in favor of adding this as an optional behavior.

However, I think that this should be optional behavior, and therefore I
think it's worth allowing the client to update the PTR record.   The
benefit of this is that it gives the software/hardware vendor some say in
what debugging information is available, regardless of the opinions of the
network operator or DNS server implementor.

>   to modify things, should it communicate back to the client what it

Can you think of a scenario where it makes sense to do this?   The reason
that this might not be permissible is simply that I can't think of a record
other than the PTR record that could be omitted without making things fail.

>   do reverse lookups to ip6.arpa?

Unless they are modified.   The point of that is not to suggest that
implementing this is REQUIRED, but it could be useful for someone, and
hence is not FORBIDDEN.  If you think the text reads as making this a
required feature, we should fix that!   :)

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 12 Jul 2018 17:10:06 +0200

Ted Lemon <[email-masked]> writes:

> I think that that's up to the implementation. It could do it based on
> IP address, or as I suggested in the document it could have a
> whitelist that's maintained by an administrator, based on the key or
> the name or the service type. As long as it does the same thing every
> time, the details are (I think) immaterial. However, this is worth
> thinking about—if you can come up with something that doesn't work, we
> should document it.

Right. I *think* that will work; but will probably have to try it out to
be sure :)

> Interesting. I did it this way because I don't want to get into the
> "PTR is bad, get rid of it, no it's good, I want it" argument. :)

I'm fine with not having that argument; just want to make sure the
standard doesn't disallow it (auto-adding). See below.

> Can you think of a scenario where it makes sense to do this? The
> reason that this might not be permissible is simply that I can't think
> of a record other than the PTR record that could be omitted without
> making things fail.

What I implemented is that the client will add AAAA records for all
addresses assigned to the interface; and the registration server will
filter out the ones it doesn't like (mostly making sure site-local
addresses don't end up in global DNS). I think this sort of thing should
be allowed at the server side (could also be a policy like "we don't
want printers on this network").

The question is if the client should be notified; my server will tell
the client which records were actually created, and the client won't
bother maintaining the ones that weren't. However, this is mostly an
optimisation; not sure if it's worth specifying in the spec...

> Unless they are modified.

Right, that's what I thought.

> The point of that is not to suggest that implementing this is
> REQUIRED, but it could be useful for someone, and hence is not
> FORBIDDEN. If you think the text reads as making this a required
> feature, we should fix that! :)

Hmm, don't think it read like it's required, necessarily; I was just
confused by it. I consider(ed) the reverse domains a static thing not
likely to change, in which case it seems odd to do the mapping from
.local. Is this what happens in mDNS?

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jul 2018 13:59:20 -0400

It seems like the client should just keep maintaining whatever records it
maintains.   If the server doesn't take some updates, then the client can
just keep trying.   Otherwise the client has to somehow model the state of
the server, which seems unnecessary.

As for A and AAAA records, this is an open question: how to handle it.   Is
it a problem to allow a client to update arbitrary A and AAAA records?
 The restriction of only updating the one that corresponds to the source
address used to send the update is there because we have some reasonable
assurance that the client actually has that address.   We could have some
hack where we use the neighbor table to notice that several addresses are
associated with the same layer 2 address, but that seems like not what we
want to do.

mDNS seems to just use .arpa.   I don't know how/if that works, but I
definitely don't see how to make it work with the DNS protocol.   Maybe
mDNSResponder caches this information and then returns it for 1918 networks
and ULA networks, I don't know.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 12 Jul 2018 22:49:30 +0200

Ted Lemon <[email-masked]> writes:

> It seems like the client should just keep maintaining whatever records
> it maintains. If the server doesn't take some updates, then the client
> can just keep trying. Otherwise the client has to somehow model the
> state of the server, which seems unnecessary.

Yeah, agreed.

> As for A and AAAA records, this is an open question: how to handle it.
> Is it a problem to allow a client to update arbitrary A and AAAA
> records? The restriction of only updating the one that corresponds to
> the source address used to send the update is there because we have
> some reasonable assurance that the client actually has that address.
> We could have some hack where we use the neighbor table to notice that
> several addresses are associated with the same layer 2 address, but
> that seems like not what we want to do.

Why is it a problem that a client registers other addresses for its
A(AAA) records? As long as it can't update the addresses of another name
it can't spoof that service; if it sets another device's address as it's
own name, it is just spoofing itself? It could be a problem for PTRs, of
course, but not for A(AAA)?

Maybe this could also be something that is left up to the registration
server as a matter of policy? An example policy could be "only 1 address
per subnet per name" or something... But since a client can just
generate an infinite number of new names, I'm not really sure that buys
much either...

> definitely don't see how to make it work with the DNS protocol.

Wait, don't see how to make what work with the DNS protocol?

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jul 2018 17:20:37 -0400

The only reason I think it would be a serious problem for a service to
register an IP address other than its own is that it could be used as a way
to wedge in an attack.

What I mean regarding .arpa is that mDNS literally just multicasts updates
to x.y.z.q.in-addr.arpa. over mDNS.   So it's completely bypassing DNS
delegation of authority.   This will work just fine as long as the server
processing the update is able to be authoritative for the subdomain of
in-addr.arpa corresponding to its address space.   The real sticky wicket
is that you can't update two zones in the same update, but that's not
really what you were talking about.   IOW, it has to be in-addr.local in
the update, but it can be in-addr.arpa in the zone.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 12 Jul 2018 23:27:41 +0200

Ted Lemon <[email-masked]> writes:

> register an IP address other than its own is that it could be used as
> a way to wedge in an attack.

Right. But if we want to protect against that we'd need to only allow
registrations for the IP we are talking to; which means separate
registrations for IPv4 and IPv6. And for v4 it would probably mean a
requirement for on-link presence, since anything that is not on-link is
likely to have at least one layer of NAT in-between...

> The real sticky wicket is that you can't update two zones in the same
> update, but that's not really what you were talking about.

Ah, right, then it makes sense. I may have been ignoring this part of
the spec in my implementation ;)

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jul 2018 17:32:29 -0400

Yes, this requires separate registrations for IPv4 and IPv6.   I think
that's okay.   What's a bit chancy is that it also means that if you have a
ULA and a GUA, you have to pick one, or do two updates.   As for NAT, I
think we have to assume that the network is not double-natted.   If it's a
homenet, that will be true.   If it's a campus network, that will be true.
 If it's a bunch of crappy routers plugged together, it's unlikely that
service registration will be available anyway, so we don't care.   Do you
buy that?   :)

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 12 Jul 2018 23:39:18 +0200

Ted Lemon <[email-masked]> writes:

> that's okay. What's a bit chancy is that it also means that if you
> have a ULA and a GUA, you have to pick one, or do two updates. As for
> NAT, I think we have to assume that the network is not double-natted.
> If it's a homenet, that will be true. If it's a campus network, that
> will be true. If it's a bunch of crappy routers plugged together, it's
> unlikely that service registration will be available anyway, so we
> don't care. Do you buy that? :)

Heh. For now, probably; by the time this becomes a standard, who knows?
(but surely there will be no more IPv4 by then, right? ;))

My concern is that requiring client address visibility breaks my
deployment use case, where the registration server lives in the cloud...
Or rather, I could probably live without v4, but I wouldn't be surprised
if someone else got the same idea (DNSSD as a service? One could
potentially run a dyndns type service using the same mechanism...).

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jul 2018 17:44:29 -0400

Hm.   For the cloud case, with NAT, that seems kind of problematic anyway,
because now you have A records in the public DNS pointing at RFC1918
addresses.   The right way to handle this is with PCP and an SRV record
pointing at the NAT router's public address and using the PCP-assigned
port.   I didn't document this because I think it's kind of an extra-cost
option, but that's how it would have to work.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jul 2018 17:47:05 -0400

Er, slight clarification, if you want to do Registration Protocol the way
you're describing, and you don't care about the RFC1918 issue, then you'd
need the update to go to your edge router, which would validate the
Registration and then turn it into one or more regular RFC2136-style
updates.   That implementation could be relatively stateless (only state in
memory, only until the transaction is done).

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 13 Jul 2018 00:50:09 +0200

Ted Lemon <[email-masked]> writes:

> Hm. For the cloud case, with NAT, that seems kind of problematic
> anyway, because now you have A records in the public DNS pointing at
> RFC1918 addresses.

Unless the registration server knows how to talk to the gateway resolver
and install the RFC1918 addresses as local only (and put the global v6
addresses into global DNS). That's what I'm doing now; but having the
registration server in the cloud means I can use a standard unbound
instance on the gateway; and also the gateway doesn't need to have
access to update the global DNS...

-Toke