Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

[Lanlan Pan]

Hi Paul,

Thanks for your comments and detail expatiation, :-)


*Why I think ECS is actually based on the map of " client subnet ->
geolocation (country, province, isp) " ? *

Of course, we all read RFC 7871, they said "Topologically Close" , not
"Geographically close".
Everyone know that geolocation is not precisely equal to realtime network
topology.

But, the duck test – "If it looks like a duck, swims like a duck, and
quacks like a duck, then it probably is a duck".
As last mail I replied to Ask, AUTH will not choose to detect network
topology connection speed with each subnet one by one, but summarized the
subnet into some critical information: AS Number, Country, Province, ISP
name. Most of time, AUTH will select some subnets for sample test, then,
configure by geolocation area.

I don't mean that AUTH decide response based on physical geolocation
distance. I mean that AUTH decide response base on *network topology
distance between the isp geolocation area.*
Imagine that,  www.xxxcdn.com  build two datacenter in (CHINA, SHANGHAI,
UNICOM), (CHINA, LIAONING, UNICOM)

   - physical distance: BEIJING - SHANGHAI  >  BEIJING - LIAONING
   - network topology distance: BEIJING - SHANGHAI <  BEIJING - LIAONING

the AUTH of www.xxxcdn.com  will return (CHINA, SHANGHAI, UNICOM) response
to the user from  (CHINA, BEIJING, UNICOM).

There are some examples:

1) Google Public DNS FAQ :
https://developers.google.com/speed/public-dns/faq#locations

In addition, Google Public DNS engineers have proposed a technical solution
called EDNS Client Subnet
.
This proposal allows resolvers to pass in part of the client's IP address
(the first 24/64 bits or less for IPv4/IPv6 respectively) as the source IP
in the DNS message, so that name servers can return optimized results *based
on the user's location* rather than that of the resolver. To date, we have
deployed an implementation of the proposal for many large CDNs (including
Akamai) and Google properties. The majority of *geo-sensitive* domain names
are already covered.

2) Dyn’s ECS Implementation:
https://help.dyn.com/edns-client-subnet-faq-info/

When a DNS query is received by our nameservers, we analyze the query in
order to determine what response we provide. During this analysis, we will
notice if ECS information is provided and whether a Traffic Director
service will be involved in the response. If both is the case, we will *use
the ECS information for our geolocation lookup* instead of the source IP
address.
Once a geolocation is found and a response is selected, Traffic Director
will provide a DNS response back to the source IP address. As part of this
response we will include information via ECS regarding what subnet the
response should be cached for.

3) Amazon Route 53:
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html

To improve the accuracy of *geolocation routing*, Amazon Route 53 supports
the edns-client-subnet extension of EDNS0. (EDNS0 adds several optional
extensions to the DNS protocol.) Amazon Route 53 can use edns-client-subnet
only when DNS resolvers support it
When a browser or other viewer uses a DNS resolver that does support
edns-client-subnet, the DNS resolver sends Amazon Route 53 a truncated
version of the user's IP address. Amazon Route 53 *determines the location
of the user based on the truncated IP address* rather than the source IP
address of the DNS resolver; this typically provides a more accurate
estimate of the user's location. Amazon Route 53 then responds to
geolocation queries with the DNS record for the user's location.

4)  Gdnsd (an AUTH software) 's Geoip plugin, which support ECS:
https://github.com/gdnsd/gdnsd/wiki/GdnsdPluginGeoip
gdnsd-plugin-geoip uses MaxMind's GeoIP binary databases to map address and
CNAME results based on *geography* and monitored service availability. It
fully supports both IPv6 and the emerging edns-client-subnet standard.




*Is geolocation information good for CDN and DNS? *
In the mid-1990's, network resource is rare and uneven, network path is
inconsistent with geolocation. Therefore, in the mid-1990's, many network
operators usually ignored geography.
There was a popular sentence for Chinese network topology, decribed similar
condition: The distance between China Telecom and China Unicom, is much
longer than the distance between China Telecom and United State.

However, Internet grow up dramatically since 1990s. Nowadays, Internet is
critical information infrastructure, global network path connect every
where. Even into remote mountain village, information spread rapidly.
With internet network path connect every where, the aerial view network
topology distance improve like road path more and more.
CDN do best effort to make end user to visit the closest edge server,
consider about geolocation more and more. They call that geolocation
lookup, geolocation routing, geolocation delivery, and so on.

Re: [DNSOP] .arpa

[Ted Lemon]

On Mar 23, 2017, at 12:27 AM, John Levine  wrote:
>  - waits many, many years while ICANN does what ICANN does about anything new
> 
> At this point I see the only plausible options as choose .homenet and
> require all validating resolvers to special-case it, or choose
> .homenet.arpa and put whatever DNSSEC magic we need into .arpa.

The working group is aware of the "wait many years" part of this approach, and 
is willing to try and see.   If the working group sees no progress over the 
course of the next few years, we may shift to the latter approach.

At present, the former approach isn't necessary because hosts don't validate.   
It could be argued that we are not treating this potential emergency seriously 
enough; one solution would indeed be to require that resolvers special-case 
.homenet, but if we are to do that, it would be good to have a complete 
specification for how that is done, and that would be in a follow-on document.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[John R Levine]

The working group is aware of the "wait many years" part of this 
approach, and is willing to try and see.  If the working group sees no 
progress over the course of the next few years, we may shift to the 
latter approach.


Just out of curiosity, is there anyone in the homenet WG who regularly 
engages with ICANN, through AC's or SO's or the like?


R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Matthew Pounsett]

On 19 March 2017 at 21:44, Suzanne Woolf  wrote:

> This document is the product of the homenet WG, which has asked the IESG
> to approve it for publication, so our comments are strictly advisory to the
> IESG. There was some discussion of the draft on this list shortly after it
> appeared, in November 2016, but it’s always the AD’s prerogative to ask for
> additional review.
>
>
To first answer the two questions in the call for reviews:  I see no
technical problems either with the RFC6761 application in the draft, or
with having an unsecured delegation in the root zone, should 'homenet.' be
chosen to anchor HNCP names.   There's a clear technical need for special
handling at the border between the local network and the Internet (local
names) and–in the absence of a specification for getting local trust
anchors into every validating resolver inside the local network–an
unsecured delegation for whatever name is chosen to facilitate end-to-end
security.

The reason we have a problem here is that this has been gone about in
entirely the wrong order, and procedurally leaves the IETF in a difficult
position.  We have no business demanding a root zone delegation from ICANN,
and publishing an RFC that requires that to happen in order to be useful is
tantamount to making that demand, regardless of how nicely the demand is
worded.

The need to correct the mistakes of the HNCP draft has, I think, resulted
in a rush that has been detrimental to careful consideration.  At the risk
of repeating the obvious, so that I can refer back to this list, what
should have been done is:
1) speak to ICANN (the community) about whether/how it's possible for IETF
to reserve & delegate an unsecured name from the root
2) if the community says yes, and after a process is defined, pick a name
that doesn't conflict with anything (including DITL research)
3) write the draft to reserve the name

While I appreciate that there's some risk this name might be exposed to end
users, and that perhaps some tiny percentage of end users might react badly
to seeing a reference to ARPA, I think that exposure is mostly going to
happen with technology professionals and hobbyists (power users), not the
typical home user.  So while it still may be preferable to use homenet.
over homenet.arpa., I'm unconvinced that it *needs* to be that way.

If HOMENET is set on trying for homenet., then I would recommend proceeding
with draft-ietf-homenet-redact, and shelving this draft until (1) and (2)
can be completed.

If there's a need that draft-ietf-homenet-dot be finalized before (1) and
(2) can happen, then homenet. should be replaced with homenet.arpa..

- Matt


PS: given that there is already talk of lawsuits over home. and corp., and
given that for any name that might be chosen there's likely somebody out
there in the world that thinks that name might be valuable to register, I
think the chances of getting a 'yes' out of the ICANN community is very
nearly zero.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] draft-ietf-homenet-dot review limits Re: .arpa

[Suzanne Woolf]

Hi all, and not picking on John….

I think this subthread on process and policy has gone as far as we reasonably 
can in a DNSOP review of draft-ietf-homenet-dot. We’ve established that 
different constraints and expectations apply to policy for different portions 
of the namespace, and that the HOMENET WG believes those differences have been 
taken into account, and that not everyone in DNSOP agrees.

Please share any new thoughts on how the specified protocol in the draft 
interoperates with the global public DNS, particularly with regards to DNSSEC 
or possibly incompatible uses of the namespace, which seem to be within our 
chartered scope.

I believe the process and policy concerns we’ve raised here can be revisited in 
an additional request for review or an IETF Last Call, if needed.


thanks,
Suzanne

> On Mar 23, 2017, at 10:00 AM, John R Levine  wrote:
> 
>> The working group is aware of the "wait many years" part of this approach, 
>> and is willing to try and see.  If the working group sees no progress over 
>> the course of the next few years, we may shift to the latter approach.
> 
> Just out of curiosity, is there anyone in the homenet WG who regularly 
> engages with ICANN, through AC's or SO's or the like?
> 
> R's,
> John
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Ted Lemon]

On Mar 23, 2017, at 10:00 AM, John R Levine  wrote:
> Just out of curiosity, is there anyone in the homenet WG who regularly 
> engages with ICANN, through AC's or SO's or the like?

Possibly one of the two working group chairs.   But how is this relevant?

What's going on here is that we've stumbled over a gap in expectations between 
IETF participants and the general I* leadership, including ICANN.   What the 
MoU says is pretty clear, although it certainly could have been a lot clearer, 
and perhaps many fewer tears would have been shed over this if it had been 
clearer.

The problem is not that homenet are naive, or that ICANN is difficult, or 
anything like that.   It's that we are treading new ground.   This is ground we 
need to tread.   If in fact asking ICANN for delegations in cases of technical 
uses under the MoU is the wrong thing to do, we should know that.   If it is 
the right thing to do, we should have a process for doing it.  If the way the 
document asks is impolitic, we should fix that—it's certainly not what was 
intended.

I really don't know why we're arguing about this here.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Andrew Sullivan]

Hi,

On Thu, Mar 23, 2017 at 08:34:14AM -0400, Ted Lemon wrote:
> 
> The working group is aware of the "wait many years" part of this approach, 
> and is willing to try and see.   If the working group sees no progress over 
> the course of the next few years, we may shift to the latter approach.
> 

As a comment on the document, then (that is what we're discussing,
right?), I'd note that the plan for allocation of a special-use name
contained in the draft does not state clearly (at least in my reading)
whether it is conditional on receiving the relevant unsigned
delegation.  If it _is_ so dependent, then that would be important to
know.  If it is _not_ so dependent, then probably some additional text
is needed (maybe in the security considerations) about the likely
failure of DNSSEC or resolution in such a context.

I hope that's helpful,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Ray Bellis]

On 23/03/2017 09:32, Andrew Sullivan wrote:

> As a comment on the document, then (that is what we're discussing,
> right?), I'd note that the plan for allocation of a special-use name
> contained in the draft does not state clearly (at least in my reading)
> whether it is conditional on receiving the relevant unsigned
> delegation.  If it _is_ so dependent, then that would be important to
> know.  If it is _not_ so dependent, then probably some additional text
> is needed (maybe in the security considerations) about the likely
> failure of DNSSEC or resolution in such a context.
> 
> I hope that's helpful,

Good point.

I consider them to be _independent_.  The special use reservation
mustn't be held up waiting for the requested insecure delegation.

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Suzanne Woolf]

Hi Ray,

> On Mar 23, 2017, at 1:24 PM, Ray Bellis  wrote:
> 
> I consider them to be _independent_.  The special use reservation
> mustn't be held up waiting for the requested insecure delegation.

I’m trying to make sure I understand what the special use reservation 
accomplishes in the absence of the insecure delegation.

If I read your comment correctly, I can infer two things about the protocol, 
whether the insecure delegation is delayed or refused, at least in the short 
term:

1. The protocol is sufficiently functional for deployment without working 
capability for DNSSEC validation.

2. Having a single-label name is more important for the functioning of the 
protocol than having DNSSEC validation work.
 
Is this a fair assessment of the WG’s view?


thanks,
Suzanne
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Ralph Droms]

> On Mar 23, 2017, at 1:34 PM, Suzanne Woolf  wrote:
> 
> Hi Ray,
> 
>> On Mar 23, 2017, at 1:24 PM, Ray Bellis  wrote:
>> 
>> I consider them to be _independent_.  The special use reservation
>> mustn't be held up waiting for the requested insecure delegation.
> 
> I’m trying to make sure I understand what the special use reservation 
> accomplishes in the absence of the insecure delegation.
> 
> If I read your comment correctly, I can infer two things about the protocol, 
> whether the insecure delegation is delayed or refused, at least in the short 
> term:
> 
> 1. The protocol is sufficiently functional for deployment without working 
> capability for DNSSEC validation.

Clarification: does this mean "without DNSSEC validation initially but DNSSEC 
validation is needed eventually" or  "even if DNSSEC validation is never 
available"?

- Ralph

> 
> 2. Having a single-label name is more important for the functioning of the 
> protocol than having DNSSEC validation work.
> 
> Is this a fair assessment of the WG’s view?
> 
> 
> thanks,
> Suzanne
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Suzanne Woolf]

> On Mar 23, 2017, at 1:40 PM, Ralph Droms  wrote:
> 
> 
>> On Mar 23, 2017, at 1:34 PM, Suzanne Woolf  wrote:
>> 
>> Hi Ray,
>> 
>>> On Mar 23, 2017, at 1:24 PM, Ray Bellis  wrote:
>>> 
>>> I consider them to be _independent_.  The special use reservation
>>> mustn't be held up waiting for the requested insecure delegation.
>> 
>> I’m trying to make sure I understand what the special use reservation 
>> accomplishes in the absence of the insecure delegation.
>> 
>> If I read your comment correctly, I can infer two things about the protocol, 
>> whether the insecure delegation is delayed or refused, at least in the short 
>> term:
>> 
>> 1. The protocol is sufficiently functional for deployment without working 
>> capability for DNSSEC validation.
> 
> Clarification: does this mean "without DNSSEC validation initially but DNSSEC 
> validation is needed eventually" or  "even if DNSSEC validation is never 
> available”?

I meant the question to cover both cases. The second question may well be more 
important in the “never available” case, but that’s part of what I’m trying to 
understand.



thanks,
Suzanne

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Ted Lemon]

On Mar 23, 2017, at 1:43 PM, Suzanne Woolf  wrote:
> I meant the question to cover both cases. The second question may well be 
> more important in the “never available” case, but that’s part of what I’m 
> trying to understand.

I think in the "never available" case we would obsolete the allocation and 
choose home.arpa instead.   That would be a bad outcome; if we really think 
there is no chance of this allocation happening, we shouldn't go down this 
path.   But I persist in claiming that we need to go down this path one way or 
the other to get clarity on where we stand with technical uses under the MoU.   
We should have done this back in 2000, but better 17 years late than never.

Do please note that what we have proposed does not cause DNSSEC validation to 
work: rather, absent a pre-configured trust anchor, it causes it to be skipped.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Ray Bellis]

On 23/03/2017 10:34, Suzanne Woolf wrote:

> I’m trying to make sure I understand what the special use reservation
> accomplishes in the absence of the insecure delegation.
> 
> If I read your comment correctly, I can infer two things about the
> protocol, whether the insecure delegation is delayed or refused, at
> least in the short term:
> 
> 1. The protocol is sufficiently functional for deployment without
> working capability for DNSSEC validation.

Correct, in so much as "the protocol" is actually "DNS".

The HNCP protocol is only used to configure the domain name used for
local resolution, but Homenet's zeroconf nature requires that there be a
default value, and as such Homenet / HNCP is not fully deployable
without an agreed default.

The presence of ".home" as that default in RFC 7788 was a mistake, and
the current pair of drafts is our attempt to rectify that.

Hence w.r.t Matt Pounsett's argument that the -redact document go first
and then the assignment of ".homenet" be done later, the Homenet WG has
argued *very* strongly that this is not acceptable because it leaves
HNCP in an indeterminate state.

> 2. Having a single-label name is more important for the functioning
> of the protocol than having DNSSEC validation work.
> 
> Is this a fair assessment of the WG’s view?

Not quite - DNSSEC should work correctly on any Homenet resolver which
has the appropriate trust anchor configured.

The insecure delegation is required to allow validating stub resolvers
in hosts to access .homenet names without the signed proof of
non-existence that's currently in the root from getting in the way.

Since those validating stubs are currently exceedingly rare, we can live
without that insecure delegation _for now_.

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Validating stubs? Was: Re: WG review of draft-ietf-homenet-dot-03

[Mark Andrews]

In message 
, Brian Dickson writes:
> 
> I was thinking about the DNSSEC validation by stubs, with respect to the
> homenet discussion.
> 
> And, I was wondering about various trust anchor options (other than ICANN's
> current root trust anchor).
> 
> It occurred to me, that any non-ICANN trust anchor, would possibly require
> 5011 key rolls under certain circumstances.
> 
> Which begs the question: are validating stub resolvers presumed to be
> 5011-capable?
> 
> But, I realize, the issue of 5011 capability also exists for the root trust
> anchor.
> 
> So, the dilemma is:
> 
>- Can we assume 5011 stub support regardless?
>- If not, does this make the DNSSEC issue for homenet moot, since the
>root KSK will be rolled in the near future (for some value of "near
>future"), and break stub validation?
> 
> On the other hand, if 5011 support by stubs is assumed, there is one
> interesting option:
> 
> Establish a trust anchor for homenet (whatever name is used), AND publish
> the private keys.
> 
> This creates the ability to have a master DNS authority server, in any
> given homenet instance, sign the data in the homenet zone. The default
> software could/would need to ship with the trust anchor, and the private
> key. The out-of-the-box behavior would just work, and would verify/validate
> properly for validating stubs that ship with the homenet trust anchor.
> 
> There would then be the ability for users running their own homenet
> networks, to do the equivalent of changing the default password -- they
> would be able to do a 5011 key roll, which would cause the default trust
> anchor to be replaced with a unique trust anchor for that specific homenet.
> 
> It's not part of the homenet standard (yet), but might be worth thinking
> about.
> 
> Again, the main question is, has an assumption about 5011 support in stubs
> been made, and is it a valid assumption?
> 
> If not, to re-emphasize, then the "unsigned delegation" thing isn't even
> necessary, since the stub resolvers won't be able to validate ANYTHING.

The output state of the validator is "secure", "insecure" and "bogus".

Without a insecure delegation the only result a validator can return is
"bogus".

With a insecure delegtion we get "insecure" by default and when the
client gets a trust anchor for "homenet", it can return "secure",
"insecure" and "bogus".

> Brian
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Paul Wouters]

On Thu, 23 Mar 2017, Suzanne Woolf wrote:


1. The protocol is sufficiently functional for deployment without working 
capability for DNSSEC validation.


No, what was said was there wasn't very much dnssec validating stubs out
there to cause visible problems at this moment.


2. Having a single-label name is more important for the functioning of the 
protocol than having DNSSEC validation work.


The phrase "more important" is pretty meaningless. And as was indicated,
it is all based on the levels of DNSSEC deployment on stubs, which could
change dramatically if one phone vender would suddently enable
validation or default to DNS-over-TLS to 8.8.8.8.

I would also want to add that dnsop (including myself!) pretty much
failed the homenet WG. We were asked to review docs before RFC-7788
got published in April 2016. Then we raised the alarm about .home
and I remember .homenet being a very early alternative, maybe even
suggested by dnsops. And now a year later dnsops is back to telling
homenet they cannot use this string either. I don't think they deserve
another one or two years waiting time to talk about homenet.arpa or
homenet.ietf.

I would again like to suggest that Special Use Names is moved to be
discussed outside dnsops.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

[Barry Raveendran Greene]

> On Mar 21, 2017, at 11:38 PM, Lanlan Pan  wrote:
> 
> However, if you know about the geolocation ,  you can 
> make a better response, most of time, is the best response too.

Your statement is not matching the operational realities I live in. I 
understand how mapping is done in my current environment. I understand how it 
is done in many of my peer CDNs. I also understand the tools I would need to 
measure better path calculations. Everything is in IP, RIPs, FIBs, AS Patch, 
system load, content availability, etc. Knowing that it is in Palo Alto 
California is not something useful.

What is needed is the allocated IP block to start the mapping determination. 
Then every CDN does their “secret sauce” to delver the best customer 
experience. Geographic location is just not one of those factors. ECS delivers 
this now. 





___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Ray Bellis]

On 23/03/2017 11:03, Paul Wouters wrote:

> The phrase "more important" is pretty meaningless. And as was indicated,
> it is all based on the levels of DNSSEC deployment on stubs, which could
> change dramatically if one phone vender would suddently enable
> validation or default to DNS-over-TLS to 8.8.8.8.

To be fair, if they did _only_ the latter then the .homenet names would
never resolve anyway...

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Ralph Droms]

> On Mar 23, 2017, at 1:50 PM, Ray Bellis  wrote:
> 
> 
> 
> On 23/03/2017 10:34, Suzanne Woolf wrote:
> 
>> I’m trying to make sure I understand what the special use reservation
>> accomplishes in the absence of the insecure delegation.
>> 
>> If I read your comment correctly, I can infer two things about the
>> protocol, whether the insecure delegation is delayed or refused, at
>> least in the short term:
>> 
>> 1. The protocol is sufficiently functional for deployment without
>> working capability for DNSSEC validation.
> 
> Correct, in so much as "the protocol" is actually "DNS".

No snark intended, but if "the protocol" were really just DNS, we wouldn't be 
having this discussion.  Rather, it is the DNS wire protocol using a local 
resolution context rather than the root zone.  In any event, yes, the locally 
server homenet zone can function with DNSSEC.

As I see the situation, a problem arises if there is a requirement for DNSSEC 
at some point in the future, and ".homenet" is found to be unusable as the 
special-use domain name.  It would be unfortunate to deploy devices with 
".homenet" now and find that needs to be changed in the future.

> 
> The HNCP protocol is only used to configure the domain name used for
> local resolution, but Homenet's zeroconf nature requires that there be a
> default value, and as such Homenet / HNCP is not fully deployable
> without an agreed default.
> 
> The presence of ".home" as that default in RFC 7788 was a mistake, and
> the current pair of drafts is our attempt to rectify that.
> 
> Hence w.r.t Matt Pounsett's argument that the -redact document go first
> and then the assignment of ".homenet" be done later, the Homenet WG has
> argued *very* strongly that this is not acceptable because it leaves
> HNCP in an indeterminate state.

On the other hand, not publishing -redact now leaves ".home" in an 
indeterminate state in an Internet Standard, for example relative to the TLD 
assignment process in ICANN.

> 
>> 2. Having a single-label name is more important for the functioning
>> of the protocol than having DNSSEC validation work.
>> 
>> Is this a fair assessment of the WG’s view?
> 
> Not quite - DNSSEC should work correctly on any Homenet resolver which
> has the appropriate trust anchor configured.
> 
> The insecure delegation is required to allow validating stub resolvers
> in hosts to access .homenet names without the signed proof of
> non-existence that's currently in the root from getting in the way.
> 
> Since those validating stubs are currently exceedingly rare, we can live
> without that insecure delegation _for now_.

Again, I'll argue that "for now" is a potentially problematic way of looking at 
the issue, considering there may be several years of deployment between the 
selection of .homenet as an SUDN and determination of whether or not the 
necessary entry in the root zone can be added.

- Ralph

> 
> Ray
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Paul Wouters]

On Thu, 23 Mar 2017, Ray Bellis wrote:


On 23/03/2017 11:03, Paul Wouters wrote:


The phrase "more important" is pretty meaningless. And as was indicated,
it is all based on the levels of DNSSEC deployment on stubs, which could
change dramatically if one phone vender would suddently enable
validation or default to DNS-over-TLS to 8.8.8.8.


To be fair, if they did _only_ the latter then the .homenet names would
never resolve anyway...


Correct, and DNS software has to be updated to handle this, just like it
needs updating to handle .local and .onion. If the Powers That Be can
agree on the string, we can start updating DNS software now so we are
ready when 5G hits :P

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Ted Lemon]

On Mar 23, 2017, at 2:11 PM, Ralph Droms  wrote:
> No snark intended, but if "the protocol" were really just DNS, we wouldn't be 
> having this discussion.  Rather, it is the DNS wire protocol using a local 
> resolution context rather than the root zone.  In any event, yes, the locally 
> server homenet zone can function with DNSSEC.

So do locally-served zones, by this definition, use a different protocol?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Matthew Pounsett]

On 23 March 2017 at 13:50, Ray Bellis  wrote:

>
>
> Hence w.r.t Matt Pounsett's argument that the -redact document go first
> and then the assignment of ".homenet" be done later, the Homenet WG has
> argued *very* strongly that this is not acceptable because it leaves
> HNCP in an indeterminate state.
>
> On the other hand, as Ralph Droms points out, not going ahead with either
leaves .home in an indeterminate state.  And, going ahead with both in the
absence of an answer on the homenet. insecure delegation (assume a
hypothetical third hand) leaves the whole thing undeployable in the
presence of any validation between the local nameserver authoritative for
.homenet and and-user applications.  Validating applicatinos, stubs,
localhost resolvers, and forwarders all break HNCP, unless I've completely
misunderstood something.

Since we're trying to encourage validation as close to the application as
possible, I would think we'd avoid attempting to deploy things that cannot
work with application-level validation.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Homenet implementation plans by vendors? Re: .arpa

[Dan York]

Ted or Ray or others more involved with Homenet, (I have not been)

I've not fully read all of the 80+ messages in this thread over the past couple 
of days, but Paul's comment below (as well as Ralph Droms' comment the other 
day about code) made me wonder:

- Do we have any sense of whether people in the industry are going to implement 
these Homenet protocols in actual devices and operations? 

Have any large vendors committed to deploying the protocols? Software vendors? 
Hardware vendors?

Or to put it another way - do we have businesses out there asking for these 
kind of solutions?  Or who are we building it for?

I ask in part because if the IETF did decide to go down the route of 
interacting with ICANN to make special exceptions in the root zone, these are 
exactly the kind of questions I could see people at ICANN asking.  It would 
also speak to the timeframe question. If there are people clamoring for this 
functionality, that might raise its priority.

Again, I've not been involved with the Homenet WG. I have a very basic 
understanding of the problem the WG is seeking to solve. But I'm not clear how 
large of a problem this is seen as within the larger industry.

Thanks to anyone who can shed light on this,
Dan


> On Mar 23, 2017, at 2:13 PM, Paul Wouters  wrote:
> 
> On Thu, 23 Mar 2017, Ray Bellis wrote:
> 
>> On 23/03/2017 11:03, Paul Wouters wrote:
>> 
>>> The phrase "more important" is pretty meaningless. And as was indicated,
>>> it is all based on the levels of DNSSEC deployment on stubs, which could
>>> change dramatically if one phone vender would suddently enable
>>> validation or default to DNS-over-TLS to 8.8.8.8.
>> 
>> To be fair, if they did _only_ the latter then the .homenet names would
>> never resolve anyway...
> 
> Correct, and DNS software has to be updated to handle this, just like it
> needs updating to handle .local and .onion. If the Powers That Be can
> agree on the string, we can start updating DNS software now so we are
> ready when 5G hits :P
> 
> Paul
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

--
Dan York
Senior Manager, Content & Web Strategy, Internet Society
y...@isoc.org   +1-603-439-0024 
Jabber: y...@jabber.isoc.org  Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Homenet implementation plans by vendors? Re: .arpa

[Ted Lemon]

On Mar 23, 2017, at 4:11 PM, Dan York  wrote:
> I ask in part because if the IETF did decide to go down the route of 
> interacting with ICANN to make special exceptions in the root zone, these are 
> exactly the kind of questions I could see people at ICANN asking.  It would 
> also speak to the timeframe question. If there are people clamoring for this 
> functionality, that might raise its priority.

I can see ICANN people asking these questions too.   However, I wonder if this 
is really the right approach.   If the IETF has the right under the MoU to ask 
for root delegations, then it seems to me that the IETF should just be allowed 
to ask.   There should obviously be a process, and the IETF should not ask 
frivolously, and certainly shouldn't ask as a way to bypass the gTLD process.   
But ultimately it doesn't make sense to me for ICANN to ask this question.

Either IETF can ask for technical-use TLDs to be delegated, or it can't; the 
question from ICANN's perspective ought to be "(a) is this a technical use?  if 
not, IETF has no special access.   if so, (b) is the name in dispute?   If so, 
IETF can't have it.   If not, IETF can have it."   Of course, I'm sure that's 
hopelessly naive, but the point is that we need to have this conversation and 
figure this out.   This is true whether the IETF goes ahead with .homenet or 
not, so whether this is hard or not really shouldn't be a determining factor in 
whether we try to get .homenet delegated.

That said, of course you can ask this question _in the IETF_ and maybe it's a 
good question.   The answer is that there is a lot of _interest_, but it's not 
clear to me that this interest will transform immediately into product on the 
shelf.   My expectation is that it will start out in open source distros, and 
in a few high end boxes, and trickle down.   I know various vendors and 
operators have expressed strong interest in this in the past, but the 
difficulty of making any forward progress at all within the IETF (this being an 
example) has been discouraging for them.

So at this point I can't promise that if we build it they will come; they are 
already here, but they are a bit frustrated, and that could have a negative 
impact on deployment.   But we wouldn't be trying to build this if we didn't 
think it was worth building.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Homenet implementation plans by vendors? Re: .arpa

[Ray Bellis]

On 23/03/2017 14:01, Ted Lemon wrote:
> My expectation is that it will start out in open source distros, and
> in a few high end boxes, and trickle down.

AIUI, bits of the Homenet stack (including HNCP) are already available
in OpenWRT.

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Matt Larson]

> On Mar 23, 2017, at 2:30 PM, Ted Lemon  wrote:
> 
> On Mar 23, 2017, at 2:11 PM, Ralph Droms  > wrote:
>> No snark intended, but if "the protocol" were really just DNS, we wouldn't 
>> be having this discussion.  Rather, it is the DNS wire protocol using a 
>> local resolution context rather than the root zone.  In any event, yes, the 
>> locally server homenet zone can function with DNSSEC.
> 
> So do locally-served zones, by this definition, use a different protocol?

I think saying "different protocol" is not accurate and risks being a 
distraction.  Rather, Ralph's comment about "resolution context" is important 
and gets to the heart of the issue.  Before DNSSEC, a recursive name server 
could also be authoritative for local zones or use other mechanisms (such as 
stub zones and conditional forwarding) to "short circuit" resolution to handle 
the local context and not send traffic to the root, and everything resolved 
just fine.  Now, with DNSSEC validation enabled, zones in this "local 
resolution context" need to chain up to a trust anchor somewhere.  If there's 
not a chain of trust from the root, a local trust anchor is needed for 
validation to succeed.

Consider a corporate split DNS example.  Let's say Acme Corp maintains two 
versions of the zone acme.com , one for external consumption 
(delegated to from .com) and another version for internal use.  Their internal 
recursive name servers use some mechanism (local authoritative zones, stub 
zones, etc.) to ensure that internally generated queries resolve against the 
internal version of acme.com .  Let's also say that Acme Corp 
signs both the internal and external versions of acme.com  
and that their internal recursive servers have DNSSEC validation enabled.  The 
chain of trust from the root leads to the external acme.com , 
so the internal recursive servers will need a trust anchor for the internal 
version of acme.com  or validation fails.

homenet uses a local resolution context without a local trust anchor, hence the 
request for special casing in the root.

Matt

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Ralph Droms]

> On Mar 23, 2017, at 2:30 PM, Ted Lemon  wrote:
> 
> On Mar 23, 2017, at 2:11 PM, Ralph Droms  wrote:
>> No snark intended, but if "the protocol" were really just DNS, we wouldn't 
>> be having this discussion.  Rather, it is the DNS wire protocol using a 
>> local resolution context rather than the root zone.  In any event, yes, the 
>> locally server homenet zone can function with DNSSEC.
> 
> So do locally-served zones, by this definition, use a different protocol?

As Matt Larson just pointed out, "different protocol" may turn into a 
distraction.  .homenet is asking for an entry in the special-use domain name 
registry and a specific kind of entry in the DNS root zone.  I take those 
characteristics to differentiate homenet, perhaps as an extension or variant of 
DNS.

- Ralph

> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Ted Lemon]

On Mar 23, 2017, at 5:47 PM, Ralph Droms  wrote:
> As Matt Larson just pointed out, "different protocol" may turn into a 
> distraction.  .homenet is asking for an entry in the special-use domain name 
> registry and a specific kind of entry in the DNS root zone.  I take those 
> characteristics to differentiate homenet, perhaps as an extension or variant 
> of DNS.

Is this even necessary?   The MoU uses the example of in-addr.arpa, which is 
resolved using the DNS protocol, so from the perspective of the MoU, I don't 
think it is.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Homenet implementation plans by vendors? Re: .arpa

[George Michaelson]

here we go again "because its in running code, its too late to change
so my pre-emptive decision to code to it, trumps any process you ask
we invoke now"

thats called squatting: its what other people do. and I repudiate it.

you should have coded to example.com or a nonce.

-G

On Fri, Mar 24, 2017 at 7:35 AM, Ray Bellis  wrote:
>
>
> On 23/03/2017 14:01, Ted Lemon wrote:
>> My expectation is that it will start out in open source distros, and
>> in a few high end boxes, and trickle down.
>
> AIUI, bits of the Homenet stack (including HNCP) are already available
> in OpenWRT.
>
> Ray
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Homenet implementation plans by vendors? Re: .arpa

[Ray Bellis]

On 23/03/2017 15:20, George Michaelson wrote:
> here we go again "because its in running code, its too late to change
> so my pre-emptive decision to code to it, trumps any process you ask
> we invoke now"
> 
> thats called squatting: its what other people do. and I repudiate it.
> 
> you should have coded to example.com or a nonce.

Actually, what's in the code right now is ".home".

The whole point is to get ".homenet" blessed _before_ the code gets
updated to use that, but we also want the amount of time that takes to
be minimised so that the currently baked-in use of ".home" doesn't make
that the de-facto default in perpetuity.

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Homenet implementation plans by vendors? Re: .arpa

[George Michaelson]

then I un-take my rant. apologies for ranting.

but to the sw authors of OpenWRT grr. parameterized? runtime configurable?



On Fri, Mar 24, 2017 at 8:26 AM, Ray Bellis  wrote:
>
>
> On 23/03/2017 15:20, George Michaelson wrote:
>> here we go again "because its in running code, its too late to change
>> so my pre-emptive decision to code to it, trumps any process you ask
>> we invoke now"
>>
>> thats called squatting: its what other people do. and I repudiate it.
>>
>> you should have coded to example.com or a nonce.
>
> Actually, what's in the code right now is ".home".
>
> The whole point is to get ".homenet" blessed _before_ the code gets
> updated to use that, but we also want the amount of time that takes to
> be minimised so that the currently baked-in use of ".home" doesn't make
> that the de-facto default in perpetuity.
>
> Ray
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Homenet implementation plans by vendors? Re: .arpa

[Ray Bellis]

On 23/03/2017 16:08, George Michaelson wrote:
> then I un-take my rant. apologies for ranting.
> 
> but to the sw authors of OpenWRT grr. parameterized? runtime configurable?

The option value is run time configurable, because the home owner might
have their own domain that they wish to use.

The argument is over what the default value is that takes over in the
zeroconf case when one hasn't been configured.  I haven't studied the
code to see how its value is specified.

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

[Lanlan Pan]

Hi Barry,

There are complex factors to optimize the datacenter connection of CDN.
I know every CDN need "Everything is in IP, RIPs, FIBs, AS Patch, system
load, content availability, etc." to measure better path calculations.
I understand that "Knowing that it is in Palo Alto California" is not
something useful for Data Provider path calculation, load balance
optimization, etc.
Note that, I *DON'T* mean that knowing  is
sufficient for CDN.

But, as you methioned in last mail:
*>  Once the connection to the client to the CDN is made, the CDN
operator has the full details of the client. *
CDN can known "Everything is in IP, RIPs, FIBs, AS Patch, system load,
content availability, etc." without ECS.
CDN can do the BGP optimization and datacenter load balance without ECS.

*Sperate the consideration of datacenter path calculation (Data Provider)
and dns response (AUTH).*

   - Data provider can make datacenter path calculation without ECS because
   all clients will connect.
   - ECS is help AUTH to return the satisfied dns response to client.

Therefore, the question is, *what can help AUTH to decide the response* ?
I mean that, most of time, knowing  is sufficient
for AUTH make dns response.

My statement Is, for example:
the subnets (subnet_1 ... subnet_100) in the same 
geolocation, always visit the same CDN datacenter sets (DC_1 .. DC_2) .
datacenter sets can be changed when network status is varied, network path
connection latency become larger, load balance adjustment, etc...
EIL is sufficient if AUTH make dns decison on 
geolocation pricise level.

If your operational realities is:
subnet_1 ... subnet_100 in the same  geolocation,
you apply subnet_1 ... subnet_50 visit DC_1, subnet_51 .. subnet_100 visit
DC_2
ECS is satisfied with your statement, because your AUTH make dns decision
down to subnet pricise level.

Barry Raveendran Greene 于2017年3月24日周五 上午2:06写道：

>
> > On Mar 21, 2017, at 11:38 PM, Lanlan Pan  wrote:
> >
> > However, if you know about the geolocation ,
> you can make a better response, most of time, is the best response too.
>
> Your statement is not matching the operational realities I live in. I
> understand how mapping is done in my current environment. I understand how
> it is done in many of my peer CDNs. I also understand the tools I would
> need to measure better path calculations. Everything is in IP, RIPs, FIBs,
> AS Patch, system load, content availability, etc. Knowing that it is in
> Palo Alto California is not something useful.
>
> What is needed is the allocated IP block to start the mapping
> determination. Then every CDN does their “secret sauce” to delver the best
> customer experience. Geographic location is just not one of those factors.
> ECS delivers this now.
>
>
>
>
>
> --
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Ralph Droms]

> On Mar 23, 2017, at 5:54 PM, Ted Lemon  wrote:
> 
> On Mar 23, 2017, at 5:47 PM, Ralph Droms  wrote:
>> As Matt Larson just pointed out, "different protocol" may turn into a 
>> distraction.  .homenet is asking for an entry in the special-use domain name 
>> registry and a specific kind of entry in the DNS root zone.  I take those 
>> characteristics to differentiate homenet, perhaps as an extension or variant 
>> of DNS.
> 
> Is this even necessary?

"this" == "differentiate homenet from DNS"?

>   The MoU uses the example of in-addr.arpa, which is resolved using the DNS 
> protocol, so from the perspective of the MoU, I don't think it is.
> 

I was mostly referring to the idea that DNSSEC will work because the homenet 
name resolution mechanism is "just DNS".  I thought it was important to point 
out that homenet name resolution isn't exactly DNS, so we should be careful to 
make assumptions about its behavior based on DNS.

- Ralph

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop