Subject: Re: [pcp] Using dynamically assigned port numbers with static URLs

From: Masataka Ohta <[email-masked]>
Date: Wed, 02 Nov 2011 18:45:23 +0900

Francis Dupont wrote:

> =>  there is some indications in the base draft, even only
> in non-normative sections (this is out of scope of the PCP WG)
> and more DNS SD than SRV oriented.

Thank you for a pointer.

> =>  IMHO it is more dnsop than dnsext as you propose a clever
> use of SRV RRs, not a new protocol/RR/etc.

As it proposes an interpretation of URLs and SRVs, especially
when there are some conflicts, I think it implies some
semantical changes, which means it contains protocol issues.

> I have a concern about using (dynamic) DNS is this context:
> DNS answers are cached, in fact even with TTL=0 by most applications,
> so it doesn't survive a CGN address or port renumbering from a reboot.

Pcp recovery should be able to take care of the problem.

> Note this is not an issue for the now traditional DHCP+DDNS used
> for nomadism because in that context the nomad server releases/
> deregisters before being shutdowned and no longer available for
> a delay greater than the DNS lifetime,

As you said:

> DNS answers are cached, in fact even with TTL=0 by most applications,

cached answers can survive a lot longer thant DNS lifetime.

> This is not the case for a server behind a CGN
> which doesn't enforce mapping stability using for instance
> stable storage.

Is it enough to specify that servers behind a CGN gateway
without stable storage nor pcp recovery should have SRVs
with small (a few minuts?) TTL?

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 03 Nov 2011 10:15:31 +0900

Francis Dupont wrote:

> a delay greater than the DNS lifetime, i.e., in the rare cases
> a nomad computer provides a service this can be done in a
> secure way.

I reconsider the case and noticed that, if a primary server is
down, secondaries will keep replying to queries using unupdated
old data.

Secondaries expire their copies of zone data only after
SOA EXPIRE is reached, which often takes several weeks.

So, though it's a security concern for DHCP+DDNS, it is an
acceptable concern for users of DHCP+DDNS.

						Masataka Ohta