Juliusz Chroboczek writes:
>> Why? What is wrong with the owner of the network selecting which devices
>> / services he/she wants globally reachable
>
> I don't think this is about global reachability (which is hopefully
> managed by PCP), it's about exporting names into the global DNS. We
>
Hi,
On Mon, Jul 23, 2018 at 08:50:50PM +0200, Toke Høiland-Jørgensen wrote:
> Juliusz Chroboczek writes:
>
> > Exporting names from the Homenet into the global namespace, on the
> > other hand, should be done by the hosts, with no involvement of any
> > third party (neither the ISP nor the
> Why? What is wrong with the owner of the network selecting which devices
> / services he/she wants globally reachable
I don't think this is about global reachability (which is hopefully managed
by PCP), it's about exporting names into the global DNS. We ought to
distinguish the two -- you can
> Apparently my comment was clear as mud. I meant this:
> https://tools.ietf.org/html/draft-ietf-opsawg-mud-25
Quote, "YANG-based JSON that describes a Thing", unquote. 61 pages.
Revision 25, and still a draft. I wish you a lot of fun implementing that.
> Having a public/private zone pair
Juliusz Chroboczek writes:
> Exporting names from the Homenet into the global namespace, on the
> other hand, should be done by the hosts, with no involvement of any
> third party (neither the ISP nor the Homenet itself). This is where I
> argue for some form of end-to-end, secured, dynamic DNS
> By using DynDns are you proposing to remove the requirement of having
> a naming resolution mechanism internally in the homenet ?
No. Naming *internal* to the Homenet needs another mechanism, perhaps
what Ted is designing (and implementing), perhaps something else.
Exporting names from the
>updating a single record continuously.
Cheers
Elson
-Original Message-
From: homenet On Behalf Of Juliusz Chroboczek
Sent: Thursday, July 19, 2018 4:38 PM
To: Ted Lemon
Cc: Homenet
Subject: Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> One
Apparently my comment was clear as mud. I meant this:
https://tools.ietf.org/html/draft-ietf-opsawg-mud-25
Having a public/private zone pair where the public zone is an image of the
private zone that is constructed following rules, the default rule being
"don't copy," seems very straightforward
> One way to automate this would be using mud.
A bright light shines from the heavens, bathing you in its warm glow. An
enormous, white temple stands to the north, taking most of your view.
In order to enter the Temple of Homenet Naming, you must travel up the
large staircase that stands in
;
Juliusz Chroboczek
Subject: Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
One way to automate this would be using mud.
On Thu, Jul 19, 2018 at 9:28 AM, Stephen Farrell
mailto:stephen.farr...@cs.tcd.ie>> wrote:
(with no hats...)
On 19/07/18 10:42, Juliusz Chroboczek
> On the other hand same thing using nsupdate (using TSIG and dynamic
> dns) is one command line + input file for nsupdate:
Cool.
Whichever end-to-end (host to DNS provider with no intermediate proxying)
encrypted and authentified protocol you pick, I'm with you.
-- Juliusz
Juliusz Chroboczek writes:
> And it's literally four lines of shell:
>
> while true; do
> wget --post-data 'name=gameserver.myhome.net=topsecret' \
> https://dyndns.example.com
> sleep $((24 * 3600))
> done
How does that get both IPv4 and IPv6 addresses
>> And it's literally four lines of shell:
> vs
> while true; do
> (omitted for brevity)
You're doing end-to-end dynamic update over DNS, which is fine with me.
The exact transport we end up using doesn't matter that much.
You're not doing the proxying through a hidden master mandated by
> On 19 Jul 2018, at 11:58 pm, Mark Andrews wrote:
>
>
>
>> On 19 Jul 2018, at 11:30 pm, Juliusz Chroboczek wrote:
>>
>>> I am not speaking about discovery within the Homenet. I am speaking about
>>> exporting names into the global DNS, which is what Daniel's draft is
>>> about.
>>
> On 19 Jul 2018, at 11:30 pm, Juliusz Chroboczek wrote:
>
>>I am not speaking about discovery within the Homenet. I am speaking about
>>exporting names into the global DNS, which is what Daniel's draft is
>>about.
>
>> Yes, but the problem is that you are treating this as if
One way to automate this would be using mud.
On Thu, Jul 19, 2018 at 9:28 AM, Stephen Farrell
wrote:
>
> (with no hats...)
>
> On 19/07/18 10:42, Juliusz Chroboczek wrote:
>
> >> Also, think of the privacy implications if all of the services on the
> >> homenet had to be discovered from a
> I am not speaking about discovery within the Homenet. I am speaking about
> exporting names into the global DNS, which is what Daniel's draft is
> about.
> Yes, but the problem is that you are treating this as if these are two
> separate problems, but they are not.
These are two
(with no hats...)
On 19/07/18 10:42, Juliusz Chroboczek wrote:
>> Also, think of the privacy implications if all of the services on the
>> homenet had to be discovered from a shared zone like dyndns.org.
> Quite the opposite. In the trivial update protocol, the update is
> end-to-end,
On Thu, Jul 19, 2018 at 5:42 AM, Juliusz Chroboczek wrote:
> > In order for services to be discoverable on the homenet, they have to
> > publish their contact info on the homenet. The protocol that everyone
> > uses for this is DNSSD. This is how you find your printer when you want
> > to print
> In order for services to be discoverable on the homenet, they have to
> publish their contact info on the homenet. The protocol that everyone
> uses for this is DNSSD. This is how you find your printer when you want
> to print to it. Nobody uses the ad-hoc DynDNS protocol for this.
I am not
The trivial update protocol isn't a standard protocol, and doesn't do what
we need it to do. In order for services to be discoverable on the
homenet, they have to publish their contact info on the homenet. The
protocol that everyone uses for this is DNSSD. This is how you find your
printer
> All of this can be done in the DNS without resorting to any other protocol.
Excellent.
So what technical reasons are there to prefer the complexity of
draft...front-end-naming-delegation over a trivial update protocol,
whether encapsulated in HTTPS or DNS?
-- Juliusz
All of this can be done in the DNS without resorting to any other protocol.
_dns-update._udp SRV is registered with IANA for finding where to send
UPDATE request to if the SOA MNAME or the NS’s are not reasonable.
UPDATEs can be secured with TSIG (shared secret) or SIG(0) (public key
23 matches
Mail list logo
