Re: [DNSOP] status of the aname and svcb/httpsvc drafts

[Dan York]

On Feb 26, 2020, at 2:01 PM, Evan Hunt mailto:e...@isc.org>> 
wrote:

On Wed, Feb 26, 2020 at 03:34:55PM +0100, Vladimír Čunát wrote:
I don't think it's so simple.  The current ANAME draft specifies new
behavior for resolvers, and there I'd expect even slower overall
upgrades/deployment than in browsers.

I agree with this. Browsers often upgrade themselves these days; resolvers
sit for years. (A few years ago there were still BIND 4 instances ticking
away out there.)

Very much agree with this. A few years ago a couple of us wrote a draft about 
all the pieces of the DNS infrastructure that need to be updated to support a 
new DNSSEC algorithm: 
https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-06

While a new RR type is obviously different from a crypto algorithm, the “system 
upgrade” is similar:

- resolvers have to be upgraded to support the new behavior of the ANAME record
- authoritative servers need to upgraded to process the ANAME record
- DNS hosting providers (which can often also be registrars) need to have 
updated software to allow customers to enter ANAME records
- DNSSEC signing software may need to be updated to sign the ANAME record 
(section 4.2 in the ANAME draft notes the sibling resolution that must occur 
before signing)

All of that will take some time, and probably a long time in the case of 
resolvers and the GUIs of DNS hosting providers.

Now, some element of this will ALSO be true for rolling out the HTTPSVC record, 
(ex. DNS configuration GUIs) but it may not be quite as challenging as getting 
resolvers updated. (For example, all the resolvers found in “home routers” 
distributed by ISPs.)

Which is not to say that we shouldn’t pursue ANAME or other new RR types… we 
just have to acknowledge that it may be a l time before the 
functionality is available to a large number of users.

Dan



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

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

[Dan York]

Benno,

On Feb 21, 2020, at 4:08 AM, Benno Overeinder 
mailto:be...@nlnetlabs.nl>> wrote:

I am interested to learn what the problem is that the customer wants to
solve.  Quoting from the email from Evan Hunt in this thread: "CNAME at
the apex wasn't really the problem.  Getting browsers to display
content from the right CDN server was the problem."

If there is a specific use case for CNAME in the APEX (ANAME), I am
really interested to learn from this.

Similar to Karl’s customers, I want to use domains name without any subdomains 
to point to a CDN address and have the appropriate CDN edge node respond. I had 
outlined my perspective in a draft last year:

https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view-01

What Evan says is true… it’s not so much that I “need” to have “CNAME at apex”. 
I just need some method that becomes widely available that allows web browsers 
(and other web endpoints) to go from “example.com<http://example.com>” to a CDN 
node.

If HTTPSVC can do that, and browser vendors will implement it [1], then that 
use case can be satisfied.

Dan

[1] And, of course, to get “the DNS infrastructure” to allow domain registrants 
to get the HTTPSVC records updated with their DNS hosting operator, which often 
means upgrading those DNS operators to support the new record. But that is an 
issue with ALL of the various “new DNS record” solutions we’ve come up with.

--
Dan York, Director, Web Strategy / Project Leader, Open Standards 
Everywhere<https://www.internetsociety.org/issues/open-standards-everywhere/> / 
Internet Society
y...@isoc.org<mailto:y...@isoc.org> | +1-603-439-0024 | 
@danyork<https://twitter.com/danyork>

[cid:image001.png@01D5D03B.DF736FF0]
internetsociety.org<https://www.internetsociety.org/> | 
@internetsociety<https://twitter.com/internetsociety>

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

Re: [DNSOP] draft-hoffman-dns-terminology-ter-01.txt - some comments

[Dan York]

> On Jul 22, 2019, at 8:37 PM, Normen Kowalewski  wrote:
> 
> While I agree that “add” today covers discussion around the case described in 
> here, but the reason that it covers it  is because “add” acts as a "catch all 
> bucket" for “various DNS things not well defined”.
> If we want to cover the case of an application acts as/embed a stub resolver, 
> we may want to define a term (and draft) that covers exactly that, instead of 
> using the much wider term.
> 
> I wonder if something meant by "add" today, might have to drop from being 
> meant by “add” tomorrow after that feature becomes a well defined RFC?
> Terminology would for me have to be less prone to change its meaning over 
> time.
> 
> Thus I  propose to remove “add” from the draft.

I agree with the suggestion to remove “ADD” from the draft. “ADD” seems 
different than the other ones and, in my mind, not *yet* in common-enough usage 
where its definition would be warranted. I also agree with Norman that the 
longevity of using “ADD” isn’t clear. 

I’m fine with the draft being adopted with the other terms. (We can then 
discuss more details about those specific terms.)

My 2 cents,
Dan
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Dan York]

> On Jul 2, 2019, at 3:31 PM, Jim Reid  wrote:
> 
> 
> 
>> On 2 Jul 2019, at 19:12, Matthijs Mekking  wrote:
>> 
>> I think it is time to move the protocol to Historic status as a clear signal 
>> to
>> everyone that it should no longer be implemented or deployed.
> 
> Agreed. Kill it with fire!

Yes, please!  We can celebrate all it did to help get DNSSEC going, but that 
time is now long gone.

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

Re: [DNSOP] Minimum viable ANAME

[Dan York]

> On Mar 26, 2019, at 7:23 PM, Brian Dickson  
> wrote:
> 
> We need to start with the base requirements, which is, "I want an apex RR 
> that allows HTTP browser indirection just as if there was a CNAME there”.

Yes, THIS. 

In response to the discussion last November, I put together this draft 
outlining the views of one publisher of a set of websites (me):

https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view-01

For reasons outlined in that draft, I want to use a CDN in front of my sites, 
but I also want to retain control of operating my own DNS. (I.e. I don’t want 
to have the CDN also do the DNS hosting for me, too.).

To use a CDN while retaining DNS control, most CDNs require you to set up a 
CNAME pointing to some URL they give you.  When a person then visits that URL, 
the CDN does its own magic inside its own DNS services to provide the visitor 
with the A or  record of the edge server closest to the visitor.

This all works perfectly fine if you use a subdomain such as “www.”. You just 
use a CNAME record and all is fine.

But if you want to drop the “www.” and just use the domain name (example.com), 
then we don’t have any standardized way to do a CNAME-like function at the apex 
of the zone. 

Because this is a common business requirement, most DNS hosting providers / 
operators provide some proprietary method of doing this kind of redirection. 
Either that or a company has to create their own redirection server (something 
we did). Either way, you are locked into a proprietary system with issues I 
outlined in that draft.

As Tim Wicinski mentioned in his review of documents today in DNSOP, this is 
not a simple problem to solve and there are some fundamental (and passionate) 
disagreements about the way forward. 

Tim’s suggestion of an interim (presumably virtual?) to focus specifically on 
this issue seems to make sense to me.

As I stated in the draft, I don’t personally have an opinion (yet, anyway) 
about solutions. I just want something that works and can be rapidly deployed 
and used…. so that I can be using a standard RR type instead of proprietary 
solutions.

That’s it,
Dan  (who just last month deployed a new website and immediately had people 
asking him when it would work without the “www.” in front of it… so we had to 
rapidly go and get that set up)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Minimum viable ANAME

[Dan York]

On Mar 26, 2019, at 3:35 PM, Olli Vanhoja mailto:o...@zeit.co>> 
wrote:

Did someone say that there will be a side meeting about mvp ANAME
during this week? If so, I couldn't find that from the calendar.

I believe it was a comment from someone at the mic that the *authors* were 
going to have a side meeting to talk about simplifying the draft and providing 
a new version.

If it is a larger meeting than just the authors, then there are probably a 
number of us who would be interested.

Dan

--
Dan York
Director of Web Strategy, Internet Society
y...@isoc.org<mailto:y...@isoc.org>   +1-603-439-0024
Jabber: y...@jabber.isoc.org<mailto: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] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

[Dan York]

Brian,

> On Nov 8, 2018, at 10:30 AM, Brian Dickson  
> wrote:
> 
> For new RRtypes, registries, registrars, and their provisioning services do 
> NOT need to support them; the new types are in the zones only.

DY> (Experiencing a "DUH!" moment.)  Yes, of course. It's zone data so only 
those entities handling zone data need to care.  In my 
still-annoyingly-jet-lagged mind, I made the classic mistake of equating 
"registrars" with "DNS hosting operators" because so many registrars are *also* 
DNS hosting providers.

> New RRtypes which do not require any "additional" processing, do NOT strictly 
> speaking require resolver support, since resolvers handle unknown RRtypes. 
> (Mark A can quote you the RFC, and I think has recently.)

DY> Ah, interesting. Where the proposed HTTP RRtype has behavior similar to the 
CNAME record, my assumption would be that resolver software would need to know 
what to do once it receives the record.  For that reason, wouldn't all the 
resolvers (or at least an extremely high %) need to be upgraded to support the 
new record?

> On the plus side, I can confirm at least one hosting/authority service will 
> do this as soon as a stable spec is available (i.e. HTTP and a code point 
> early allocation).

DY> :-)   Good to know!

Dan
--
Dan York
Director, Content & Web Strategy, Internet Society
y...@isoc.org   +1-802-735-1624 
Jabber: y...@jabber.isoc.org  Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fundamental ANAME problems

[Dan York]

Olli,

> On Nov 6, 2018, at 3:23 PM, Olli Vanhoja  wrote:
> 
> In fact if you look at the DNS records some big Internet companies
> they rarely use CNAMEs for www but instead you'll see an A record, that might
> be even backed by a proprietary ANAME solution.

One detail about this is that if the CDN being used by the large Internet 
company is *also* providing the DNS hosting for the Internet company, then the 
CDN will do its resolution internally and return A /  records directly. 

I did not do the kind of large scale measurement that Thomas Peterson did, but 
in anecdotally looking at the www records for a number of sites returning 
A/ records, I often saw that the ones returning A /  records also had 
NS records pointing to name servers run by CDNs I could recognize.  (I 
mentioned this in a note currently as section 2.1 of 
https://datatracker.ietf.org/doc/draft-york-dnsop-cname-at-apex-publisher-view/ 
<https://datatracker.ietf.org/doc/draft-york-dnsop-cname-at-apex-publisher-view/>
  )

So yes, in those cases the A record is being dynamically created by whatever 
(potentially proprietary) ANAME/CNAME-like solution the CDN vendor is using 
internally in their DNS hosting operations. 

Dan

--
Dan York
Director, Content & Web Strategy, Internet Society
y...@isoc.org   +1-802-735-1624 
Jabber: y...@jabber.isoc.org  Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] FYI - in v6OPS today - IPv6-Ready DNS/DNSSSEC Infrastructure

[Dan York]

FYI, in the v6ops working group right now in Meeting 1 on the 7th floor, there 
is a draft that will be discussed (after two other drafts are discussed) that 
is:


IPv6-Ready DNS/DNSSSEC Infrastructure

https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00

Abstract:

   This document defines the timing for implementing a worldwide
   IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate the
   global IPv6-only deployment.

   A key issue for this, is the need for a global support of DNSSEC and
   DNS64, which in some scenarios do not work well together.  This
   document states that any DNSSEC signed resources records should
   include a native IPv6 resource record as the most complete and
   expedient path to solve any deployment conflict with DNS64 and DNSSEC.

Slides: 
https://datatracker.ietf.org/meeting/103/materials/slides-103-v6ops-ipv6-ready-dnsdnssec-infrastructure-00

The key point is the conflict between DNS64 and DNSSEC, as described in the 
draft here:

DNS64 ([RFC6147]) is a widely deployed technology allowing hundreds
   of millions of IPv6-only hosts/networks to reach IPv4-only resources.
   DNSSEC is a technology used to validate the authenticity of
   information in the DNS, however, as DNS64 ([RFC6147]) modifies DNS
   answers and DNSSEC is designed to detect such modifications, DNS64
   ([RFC6147]) can break DNSSEC in some circumstances.

I'm passing it along in case others were, like me, not paying attention to this 
draft.

Dan

--
Dan York
Director, Content & Web Strategy, Internet Society
y...@isoc.org<mailto:y...@isoc.org>   +1-802-735-1624
Jabber: y...@jabber.isoc.org<mailto: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

[DNSOP] FYI - in v6OPS today - IPv6-Ready DNS/DNSSSEC Infrastructure

[Dan York]

FYI, in the v6ops working group right now in Meeting 1 on the 7th floor, there 
is a draft that will be discussed (after two other drafts are discussed) that 
is:

IPv6-Ready DNS/DNSSSEC Infrastructure

https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00 
<https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00>

Abstract:

   This document defines the timing for implementing a worldwide
   IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate the
   global IPv6-only deployment.

   A key issue for this, is the need for a global support of DNSSEC and
   DNS64, which in some scenarios do not work well together.  This
   document states that any DNSSEC signed resources records should
   include a native IPv6 resource record as the most complete and
   expedient path to solve any deployment conflict with DNS64 and DNSSEC.

Slides: 
https://datatracker.ietf.org/meeting/103/materials/slides-103-v6ops-ipv6-ready-dnsdnssec-infrastructure-00
 
<https://datatracker.ietf.org/meeting/103/materials/slides-103-v6ops-ipv6-ready-dnsdnssec-infrastructure-00>

The key point is the conflict between DNS64 and DNSSEC, as described in the 
draft here:

DNS64 ([RFC6147]) is a widely deployed technology allowing hundreds
   of millions of IPv6-only hosts/networks to reach IPv4-only resources.
   DNSSEC is a technology used to validate the authenticity of
   information in the DNS, however, as DNS64 ([RFC6147]) modifies DNS
   answers and DNSSEC is designed to detect such modifications, DNS64
   ([RFC6147]) can break DNSSEC in some circumstances.

I'm passing it along in case others were, like me, not paying attention to this 
draft.

Dan

--
Dan York
Director, Content & Web Strategy, Internet Society
y...@isoc.org <mailto:y...@isoc.org>   +1-802-735-1624 
Jabber: y...@jabber.isoc.org <mailto:y...@jabber.isoc.org>  Skype: danyork   
http://twitter.com/danyork <http://twitter.com/danyork>

http://www.internetsociety.org/ <http://www.internetsociety.org/>


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] CNAME at apex - a website publisher perspective - Re: Fundamental ANAME problems

[Dan York]

> 
> On Nov 4, 2018, at 8:02 PM, Ray Bellis  wrote:
> 
>  A lot of the whole "CNAME at the Apex" issue arises because lots of 
> marketing people don't want end users to have to type *or see* the www prefix.


Exactly. As many of us traveled through various airports to get to Bangkok, 
there were many large advertisements on walls, banners, and everywhere else. 

The people who make those ads have a limited amount of space in which to put 
the companies contact info. If they remove "www." and just use "example.com", 
they can make the font size larger and the text more visible. This is just one 
of the reasons people in marketing / communications teams want to drop the 
"www".  (A similar reason of spacing is why you almost never see anyone 
including "http(s)://" in advertisements.)

As someone managing a team responsible for multiple websites, and who has 
people asking about dropping the "www" on different sites, I tried to capture 
the business requirements as they relate to CDN usage in this draft I just 
submitted today:



Name:   draft-york-dnsop-cname-at-apex-publisher-view
Revision:   00
Title:  CNAME at apex - a website publisher perspective
Document date:  2018-11-05
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/internet-drafts/draft-york-dnsop-cname-at-apex-publisher-view-00.txt
 
<https://www.ietf.org/internet-drafts/draft-york-dnsop-cname-at-apex-publisher-view-00.txt>
Status: 
https://datatracker.ietf.org/doc/draft-york-dnsop-cname-at-apex-publisher-view/ 
<https://datatracker.ietf.org/doc/draft-york-dnsop-cname-at-apex-publisher-view/>
Htmlized:   
https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view-00 
<https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view-00>
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-york-dnsop-cname-at-apex-publisher-view
 
<https://datatracker.ietf.org/doc/html/draft-york-dnsop-cname-at-apex-publisher-view>

Abstract:
  There has been a large amount of discussion about the "CNAME at apex"
  issue within the DNSOP Working Group.  This draft provides the
  perspective of one publisher of multiple websites about why CNAME-
  like functionality is desirable at the apex of a domain zone.



Dan

P.S. Right now we do have "internetsociety.org" redirecting to 
"https://www.internetsociety.org;, which uses a CNAME to go out to a CDN. In 
our case we are okay with people seeing "www" in the address bar.  Other 
organizations want the www to disappear completely - and I have had that 
request for some of our other sites.

--
Dan York
Director, Content & Web Strategy, Internet Society
y...@isoc.org   +1-802-735-1624 
Jabber: y...@jabber.isoc.org  Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Interest in moving forward with draft-york-dnsop-deploying-dnssec-crypto-algs ?

[Dan York]

During the time leading up to the Root KSK Rollover on October 11, I had 
multiple people from outside of DNS circles asking me why DNS was so hard to 
upgrade. Basically - why was this Root KSK Rollover such a big concern?

I recalled the draft a few of us wrote a bit ago with observations on the 
challenges of deploying DNSSEC cryptographic algorithms:

https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-06

While we originally wrote that draft to feed into some of the KSK rollover 
design discussions that were happening, it occurred to me that it might be 
useful to have out there and available in some public form for people to be 
able to find and refer to.

Is there interest from this group in moving this draft forward?  And if so, do 
people have comments on what is in the draft?

Thanks,
Dan

P.S. There are certainly other places this kind of document could be published. 
For instance, I could turn that into a short paper we publish on the Internet 
Society's website in the Deploy360 section. But there is also a logical value 
to including it along with the other DNSSEC documents in the RFCs.

--
Dan York
Director, Content & Web Strategy, Internet Society
y...@isoc.org   +1-802-735-1624 
Jabber: y...@jabber.isoc.org  Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Any website publishers who use CDNs on the list?

[Dan York]

DNSOP subscribers,

Are there any other publishers of websites on this list who use CDNs in front 
of their sites - and who are interested in the whole “CNAME at apex” issue?

Given the ANAME discussions and other continuing “CNAME at apex” discussions, I 
started putting together a short draft clearly stating the problem statement of 
why we who publish websites want something like CNAME at apex (and why we 
aren’t happy being locked into proprietary solutions).

The issue has been stated multiple times in different email threads (including 
by Paul Vixie just yesterday) … but I thought it would be useful / helpful to 
formally write it down in a draft during these discussions.

Since I’m just one publisher of sites, I’d appreciate anyone else who might 
want to give a sanity check to what I’m writing (and/or potentially sign on as 
a co-author).

I’m about to head to the airport to begin 29 hours of travel to Bangkok, so I 
probably won’t see any responses until I get on the ground there Sunday morning.

See (some of) you in Bangkok,
Dan

P.S. The “short draft” I mentioned currently exists only on my laptop, so it’s 
not something you can see anywhere yet.

--
Dan York
Director, Content & Web Strategy, Internet Society
y...@isoc.org<mailto:y...@isoc.org>   +1-802-735-1624
Jabber: y...@jabber.isoc.org<mailto: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] Minimum viable ANAME

[Dan York]

On Sep 20, 2018, at 2:13 AM, Mukund Sivaraman 
mailto:m...@mukund.org>> wrote:

SRV is most elegant. IMO we should push the resolver-side CNAME handling
change through so one day in the future it is available widely.

+1

I do think this is a path we need to go.  We need *something* like CNAME at the 
apex.  Either CNAME itself or something that works in the same way but might 
have a different name.

Otherwise, those of us out there publishing sites using CDNs but wanting to use 
an apex domain name are stuck using whatever proprietary options DNS operator X 
is offering us… which will be different from DNS operators Y and Z.  This locks 
us in to a specific DNS operator.  (Who may or may not also be the CDN 
operator.)

Given the long deployment timeline, I do think we need to start on this sooner. 
 I’m glad to help.

My 2 cents,
Dan


--
Dan York
Director, Content & Web Strategy, Internet Society
y...@isoc.org<mailto:y...@isoc.org>   +1-802-735-1624
Jabber: y...@jabber.isoc.org<mailto: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] abandoning ANAME and standardizing CNAME at apex

[Dan York]

Mukund,

Thank you for reviving this conversation. I was just asked last week about the 
status of this whole debate by someone who was seeking to set up “CNAME at 
apex”-style records for a variety of domains, all of which would be pointed 
over to links within various CDNs.

His challenge is that, for a variety of reasons not within his control, his 
domains are spread across several different CDNs / DNS hosting providers, all 
of whom do “CNAME at apex” in different ways. (And, if I recall correctly, one 
provider did NOT support this capability, citing RFC 1035 as their rationale.) 
The added complexity, and having to be sure he is doing it correctly for each 
of the different services, is quite frustrating and time consuming.  Meanwhile, 
he has communications people asking him very strongly for the ability to drop 
the “www” and just refer to their website addresses as 
“example.com<http://example.com>/”.

Hence his question to me about if this was ever going to be “fixed” by the IETF 
with some kind of standard.

I do think something needs to be done to standardize CNAME (or something very 
similar) at the apex. For the person with whom I was speaking, all of this 
websites are set up using various CDNs. So all he can provide is a DNS address 
in the CDN’s network.  He has no way to get an A or  address as I 
understand the ANAME proposal would require.

So this is a lengthy way of saying that I would agree with moving ahead with a 
proposal to allow CNAME at apex, and to start to get resolvers to implement 
that.  I realize that updating the whole DNS infrastructure is incredibly 
challenging (we wrote about this with regard to crypto algorithms at 
https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs ).  
And so this may not be something widely available for some time.  But if we 
could get it started, it would definitely help the many people out there trying 
to configure domains to point to CDNs from their apex.

Dan

--
Dan York
Director, Content & Web Strategy, Internet Society
y...@isoc.org<mailto:y...@isoc.org>   +1-802-735-1624
Jabber: y...@jabber.isoc.org<mailto:y...@jabber.isoc.org>  Skype: danyork   
http://twitter.com/danyork

http://www.internetsociety.org/

On Sep 16, 2018, at 5:56 AM, Mukund Sivaraman 
mailto:m...@mukund.org>> wrote:

Hi Petr

Apologies for the delayed reply.

On Tue, Jun 19, 2018 at 03:18:22PM +0200, Petr Špaček wrote:
Hello dnsop,

beware, material in this e-mail might cause your head to explode :-)

This proposal is based on following observations:
- It seems that DNS protocol police lost battle about CNAME at apex,
 is is deployed on the Internet.
- Major DNS resolvers like BIND, Unbound, PowerDNS Recursor, dnsmasq
 already have code to cope with the "impossible" case of CNAME at the
 apex and deal with it in ways which do not break stuff on resolver
 side.
- Authoritative servers of vendors named above refuse to serve CNAME at
 apex.
- There are CDNs etc. which allow users to create CNAME at apex
 no matter what the standards and "normal" servers say and do.
(We have found out this because Knot Resolver is missing hacks for CNAME
at apex and users complain that "it works with every other resolver".)


Take a deep breath!


Given that resolver side somehow works already ...
could we standardize this obvious violation of RFC 1035?

It is very clear violation of the standard, but almost everyone found
his way around it using different hacks. These hacks are not going away
because all the CDNs just don't care about standards so we will have
to maintain this code no matter what a great solution we will invent for
future. I.e. adding ANAME will just increase complexity because CNAME at
apex will be there for a long time (if not forever).

I personally do not like this but it seems better to think though
corner cases in code we already have in production (i.e. think through
current hacks for CNAME at apex) instead of inventing new things like ANAME
(or whatever else).

Opinions? Tomatoes? Can it work? If not, why not?

To me it seems it can work, and it sounds like a good idea. To relax DNS
protocol for CNAME to co-exist with other RR types, we'd need resolver
support, authoritive support and a time when it is practially usable.



Adding resolver support (to resolvers that don't have it, i.e., vs. RFC
1035) does not appear to break current DNS, i.e., it can be proposed
now.

1. When a resolver looks up a RR type in cache, and finds any positive
type match, it serves it.

2. If it does not find a positive type match, but finds a CNAME, it
looks for a negative cache entry for that RR type.

2.a. If a negative cache entry is found (or if it can synthesize one),
it returns/follows the CNAME chain.

2.b. If no negative cache entry is found (and it cannot synthesize one),
it starts a fetch for that type from upstream.

2.b.i. If the fetch returns a CNAME or NODATA, it means that the 

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

[Dan York]

+1. Support adoption.

> On Jul 19, 2018, at 8:42 AM, Sara Dickinson  wrote:
> 
> I also support adoption of this draft - it is attempting to address a genuine 
> impediment to deploying DNSSEC and I think this group is the right place to 
> work on it.
> 
> As mentioned at the mic in Montreal, I’d like to see it additionally reflect 
> how the proposals here feed into the process for moving vendors after 
> deployment. 
> 
> Sara.
> 
>> On 18 Jul 2018, at 11:13, Yoshiro YONEYA  wrote:
>> 
>> I support this draft to be WG I-D.
>> 
>> -- 
>> Yoshiro YONEYA 
>> 
>> On Fri, 6 Jul 2018 20:26:59 -0400 Tim Wicinski  wrote:
>> 
>>> We've had some interest in moving this document forward, and the chairs
>>> wanted to kick off this Call for Adoption before Montreal so if there
>>> are concerns there will be some meeting time to address.
>>> 
>>> This document is label as: Informational.  The document is attempting
>>> to document operational deployment models on deploying DNSSEC signed
>>> zones across multiple platforms.
>>> 
>>> This starts a Call for Adoption for: draft-huque-dnsop-multi-provider-dnssec
>>> 
>>> The draft is available here:
>>> https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-provider-dnssec/
>>> 
>>> Please review this draft to see if you think it is suitable for
>>> adoption by DNSOP, and comments to the list, clearly stating your view.
>>> The authors will be at the next meeting to address questions or concerns.
>>> 
>>> Please also indicate if you are willing to contribute text, review, etc.
>>> 
>>> This call for adoption ends: 20 July 2018
>>> 
>>> Thanks,
>>> Tim
>> 
>> ___
>> 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



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QNAME minimisation on the standards track?

[Dan York]

> On Jul 18, 2018, at 9:46 AM, Sara Dickinson  wrote:
> 
>> On 17 Jul 2018, at 17:35, Paul Wouters  wrote:
>> 
>> On Tue, 17 Jul 2018, tjw ietf wrote:
>> 
>>> Subject: Re: [DNSOP] QNAME minimisation on the standards track?
>>> I’d like to see a more fleshed out operational considerations section.

>> 
>> But I do believe qname minimisation is an important privacy enhancing
>> technology that we should strongly promote as a standards track
>> document.
> 
> +1
> 
> Sara.

+1. I think this is a valuable tool in our privacy toolbox and should be 
standardized.

Dan



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New terminology for root name service

[Dan York]

On Apr 6, 2017, at 11:25 AM, Matthew Pounsett 
<m...@conundrum.com<mailto:m...@conundrum.com>> wrote:



On 15 March 2017 at 13:31, Paul Hoffman 
<paul.hoff...@vpnc.org<mailto:paul.hoff...@vpnc.org>> wrote:
Greetings again. RSSAC has published a lexicon of terms that are commonly used 
with respect to the root of the public DNS, but are not in RFC 7719. I have 
opened an issue for the terminology-bis document at 
https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/17 and would 
be intereted to hear what people think about including those terms in our 
document.


Hi Paul.  Noting there hasn't been any actual feedback on your question ... I 
think the -bis document should at least reference RSAAC026, but I think 
importing those terms (particularly the ones that are not root-specific: 
instance, publish, serve) would be useful.

Agree with Matthew (and others) that RSAAC026 should be referenced. Also agree 
that "instance", "publish" and "server" would be useful additions. I don't know 
that the specific root zone terms need to be incorporated.

I guess a general question would be (and I don't know the answer): do we 
anticipate creating RFCs that define operations and protocols used within the 
root zone?  If yes or "maybe", we should incorporate the terms.  If "probably 
not" or "no", then there could just be a new section about "Root Zone 
terminology" that specifically directs people to view RSAAC026 (and successor 
documents).

My 2 cents,
Dan

--
Dan York
Senior Manager, Content & Web Strategy, Internet Society
y...@isoc.org<mailto:y...@isoc.org>   +1-603-439-0024
Jabber: y...@jabber.isoc.org<mailto: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] New draft for ALIAS/ANAME type

[Dan York]

I very much like the idea of this draft, given that I use multiple DNS hosting 
providers who all have their own unique (and proprietary) way of doing "CNAME 
flattening at the apex". I think the reality of today's user experience with 
domain names is that we are increasingly dropping the "www" or any other kind 
of second-level domain. So we want to talk about our sites as 
"example.com<http://example.com>" ... but as the publisher we want to use CDNs, 
load balancers and other systems that need us to use a CNAME. A standardized 
way of doing this would be helpful.

One comment...

On Mar 30, 2017, at 7:13 PM, Evan Hunt <e...@isc.org<mailto:e...@isc.org>> 
wrote:

(Incidentally, I'm working on a somewhat more ambitious ANAME draft with
Peter van Dijk and Anthony Eden, who has kindly agreed to merge his efforts
with ours. I expect to post it in a few days, stay tuned.)

... I think it would be helpful for the new draft to have a few examples of 
what the RR would look like in a zone file.  (This was the one component I 
found missing from Anthony's ALIAS draft.)

Thanks for doing this,
Dan

--
Dan York
Senior Manager, Content & Web Strategy, Internet Society
y...@isoc.org<mailto:y...@isoc.org>   +1-603-439-0024
Jabber: y...@jabber.isoc.org<mailto: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

[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 <p...@nohats.ca> 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] Heads-up - draft about "letting localhost be localhost" in SUNSET4 that really should be in DNSOP

[Dan York]

Ted,

> On Nov 17, 2016, at 12:46 PM, Ted Lemon  wrote:
> 
> Just to play the devil's advocate here, what does this have to do with DNS?

>From the abstract:

   This document updates RFC6761 by requiring that the domain
   "localhost." and any names falling within ".localhost." resolve to
   loopback addresses.  This would allow other specifications to join
   regular users in drawing the common-sense conclusions that
   "localhost" means "localhost", and doesn't resolve to somewhere else
   on the network.

It's an update to RFC 6761 and all about resolution of "localhost".

To me that seems like a DNS issue... and since we already have a heap of open 
issues with 6761, this would seem to be one more thing to consider.

I should mention that Terry Manderson (INT AD) and Joel Jaeggli (OPS AD) were 
both in the SUNSET4 room and agreed they would have a discussion about which WG 
this document should live in. Both agreed that DNSOP should at least definitely 
look at it.

Peter Koch and I both recommended from the mic that it be brought to DNSOP 
(which I guess I then did by posting it here).

Peter also mentioned that there was a long history with the resolution around 
"localhost" and that this topic had been discussed at length multiple times. (I 
took it that he was not saying it should NOT be brought up again, but rather 
that the authors should be aware that it had a good bit of history.)

Dan




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

[DNSOP] Heads-up - draft about "letting localhost be localhost" in SUNSET4 that really should be in DNSOP

[Dan York]

DNSOP,

In SUNSET4 right now, Emily Stark from Google presented a draft from Mike West 
(also Google) asking to update the language in RFC 6761 around the resolution 
of localhost:

Draft: https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-02

Slides: 
https://www.ietf.org/archive/id/draft-west-let-localhost-be-localhost-02.txt

It was brought to SUNSET4 because they are interested in stopping the 
proliferation of IPv4 addresses.

Dan

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.org<mailto:y...@isoc.org>   +1-802-735-1624
Jabber: y...@jabber.isoc.org<mailto: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] DNSSEC operational issues long term

[Dan York]

Mark,

I agree that a physical solution could be a workable option (and a nice one), 
BUT

On Nov 17, 2016, at 6:46 AM, Mark Andrews <ma...@isc.org<mailto:ma...@isc.org>> 
wrote:

Is it that hard to add a sim or sd card reader?  This is the solution
the cable industry uses for its crypto issues but with bigger form
factor cards.

... the home CPE market is extremely LOW-margin right now. Service providers 
and regular home users are looking for the cheapest options out there. Adding 
in a card reader adds cost and complexity - and a potential tech support issue 
- and the reality is that I suspect the *vast* majority of users will not ever 
run into this issue.  Most users will buy the box and connect it to their 
network and have the trust anchors just work.

Given the low margin, my suspicion is that most CPE manufacturers would NOT 
want to add in any additional components to solve what for them would be an 
edge case in terms of volume.

Just my 2 cents,
Dan

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.org<mailto:y...@isoc.org>   +1-802-735-1624
Jabber: y...@jabber.isoc.org<mailto: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] DNSSEC operational issues long term

[Dan York]

On Nov 16, 2016, at 10:18 PM, Mikael Abrahamsson 
<swm...@swm.pp.se<mailto:swm...@swm.pp.se>> wrote:

As a whole, nobody seems to be interested in actually coming up with a viable 
solution that actually fixes peoples problems. Everybody's just punting the 
problem elsewhere or waving their hands and says "not our problem".

Do you have a suggestion for a solution?

Dan

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.org<mailto:y...@isoc.org>   +1-802-735-1624
Jabber: y...@jabber.isoc.org<mailto: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

[DNSOP] Would you please review our draft on deploying new DNSSEC crypto algorithms?

[Dan York]

As mentioned at the very end of DNSOP, Olafur Gudmundsson, Ondrej Sury, Paul 
Wouters and I have a draft published that aims to document the steps involved 
with deploying a new cryptographic algorithm for DNSSEC. The overall goal is to 
make it easier to get new DNSSEC crypto algorithms deployed, both through 
documenting existing steps - and then potentially building off of this  work 
with new documents to improve some of the steps.  Right now we'd like to get 
ECDSA out, but EdDSA is coming out soon and it would be great to get that 
deployed sooner rather than later.

As I said in the session, we'd like to get reviewers and then get the document 
adopted by the WG and moved along toward publication.

The draft is at either of:

https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/
https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-04

Please send any comments to the list or to us as authors.

I also am maintaining this over in Github at: 
https://github.com/danyork/draft-deploying-dnssec-crypto-algs  If you are a 
Github user you are welcome to file an issue there or send text in a pull 
request.

Regardless, we'd just like any feedback (even if to say that it looks good).

Thanks,
Dan



--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.org<mailto:y...@isoc.org>   +1-802-735-1624
Jabber: y...@jabber.isoc.org<mailto: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] WGLC on draft-ietf-curdle-dnskey-eddsa-01

[Dan York]

Daniel,

On Nov 2, 2016, at 11:55 PM, Daniel Migault 
> wrote:
If you believe that the document is ready to be submitted to the IESG for 
consideration as a Standards Track RFC please send a short message stating this.
>From a DNS perspective I support the draft as it seems very much in line with 
>other similar drafts and RFCs specifying DNSSEC algorithms. I believe this 
>adds useful capabilities to DNSSEC and should proceed.

That said, I will need to defer to others to confirm the details of the EdDSA 
usage as I do not have experience with those crypto algorithms.

One minor editorial nit. In section 4 there are multiple references to the 
"Chapter" of another draft. Example:


The Ed25519 signature algorithm is described in Chapter
   5.1.6 in 
[I-D.irtf-cfrg-eddsa].




In US English a "chapter" is typically reserved for a "book". I think the 
better term here might be "Section", but I don't know if there is specific 
guidance anywhere on what to call areas of another I-D.


Thank you to the authors for moving this forward.


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

[DNSOP] FYI - Added note about ECDSA resolver issue in Sweden - Fwd: New Version Notification for draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt

[Dan York]

FYI, I submitted a new version of this draft that added some text in the 
section about "Resolvers" that mentions the case Mikael Abrahamsson brought to 
us about how they had to disable DNSSEC validation in the CPE they deployed to 
their customers because the resolver software was not following RFC 4035 and 
was not ignoring signatures with unknown algorithms.

Comments are of course welcome.

For those who are interested in writing I-D's with markdown, I also 
transitioned the source of this version of the document to the flavor of 
markdown that works with Miek Gieben's 'mmark' processor. Paul Jones nicely 
packaged mmark and xml2rfc into a Docker container that works extremely well. 
This document and other links can be found in my Github repo at: 
https://github.com/danyork/draft-deploying-dnssec-crypto-algs

Dan

Begin forwarded message:

From: <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>
Subject: New Version Notification for 
draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt
Date: October 30, 2016 at 11:37:13 PM EDT
To: Ondrej Sury <ondrej.s...@nic.cz<mailto:ondrej.s...@nic.cz>>, Olafur 
Gudmundsson <olafur+i...@cloudflare.com<mailto:olafur+i...@cloudflare.com>>, 
Dan York <y...@isoc.org<mailto:y...@isoc.org>>, " 
y...@isoc.org<mailto:y...@isoc.org>" <y...@isoc.org<mailto:y...@isoc.org>>, 
Paul Wouters <pwout...@redhat.com<mailto:pwout...@redhat.com>>


A new version of I-D, draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt
has been successfully submitted by Dan York and posted to the
IETF repository.

Name: draft-york-dnsop-deploying-dnssec-crypto-algs
Revision: 02
Title: Observations on Deploying New DNSSEC Cryptographic Algorithms
Document date: 2016-10-31
Group: Individual Submission
Pages: 9
URL:
https://www.ietf.org/internet-drafts/draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/
Htmlized:   
https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-02
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-york-dnsop-deploying-dnssec-crypto-algs-02

Abstract:
  As new cryptographic algorithms are developed for use in DNSSEC
  signing and validation, this document captures the steps needed for
  new algorithms to be deployed and enter general usage.  The intent is
  to ensure a common understanding of the typical deployment process
  and potentially identify opportunities for improvement of operations.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat


--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.org<mailto:y...@isoc.org>   +1-802-735-1624
Jabber: y...@jabber.isoc.org<mailto: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] ECDSA woes

[Dan York]

Mikael,

On Oct 15, 2016, at 11:22 AM, Mikael Abrahamsson 
<swm...@swm.pp.se<mailto:swm...@swm.pp.se>> wrote:

These kinds of migration scenarios to newer algorithms MUST be hashed out, 
because otherwise we're never going to be able to deploy new algorithms (and 
per previous experience, it seems we want to change them every 5-10 years).

Agreed! To capture this kind of information, a group of us wrote a draft in 
DNSOP about new crypto algorithms:

https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-01

In section 2.1.1 we mention the situation with resolvers and unknown 
algorithms. However, we assume compliance with RFC 4035. Your case study here 
shows that we need to add some text about the challenge that can happen if the 
resolver does the wrong thing and fails the validation.

I'll add that. Thank you for bringing this case to the list.

It seems to me there is a larger issue of whether a system will "fail insecure" 
(or "fail open") or "fail secure".

RFC 4035 has the "fail insecure" view where the DNS info is still passed along, 
thus allowing the deployment of new algorithms to NOT break things, although 
with a lower level of security until the new algorithms are supported.

It seems the dnsmasq developers chose to "fail secure" thus potentially 
"protecting" the end user from insecure data, although in this case the data is 
secure, just not understood to be secure.

This is one of the tougher points of algorithm change, particularly when so 
many of the resolvers may be in commodity customer-premises equipment (CPE) 
that may or may not be easily updated or replaced.

Dan


--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.org<mailto:y...@isoc.org>   +1-802-735-1624
Jabber: y...@jabber.isoc.org<mailto: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] draft-ietf-dnsop-terminology-bis-01

[Dan York]

Paul,

The new -01 draft looks good.  I need to do a deeper read but I'll point out 
one additional term we found in the development of 
https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/

DNS server deployments today that deploy DNSSEC often have an additional 
component which we called the "signing software" in our draft (section 2.3). 
This signing software *is* part of the "DNS infrastructure" but it may be 
separate from the actual authoritative DNS server.  An obvious example of this 
is OpenDNSSEC. I am also aware of some "signing services" offered by vendors 
that will sign zones for you.

I don't know whether "signing software" (or something we can agree on) *needs* 
to be in the terminology document, but I would point out that it is something 
that exists within DNS deployments today.

Dan


On Jul 8, 2016, at 5:25 PM, Paul Hoffman 
<paul.hoff...@vpnc.org<mailto:paul.hoff...@vpnc.org>> wrote:

Thanks for the comments. We are actually turning in a new draft today (with a 
bunch of changes), and intend to get much more active on this starting right 
about... now.

--Paul Hoffman

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

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.org<mailto:y...@isoc.org>   +1-802-735-1624
Jabber: y...@jabber.isoc.org<mailto: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

[DNSOP] Anyone else want to join the DNS group at the IETF 96 Hackathon?

[Dan York]

DNSOP members,

FYI, we've got 20+ people gathering at the IETF 96 Hackathon on Saturday and 
Sunday, July 16-17, in Berlin to work on various "DNS / DNSSEC / DPRIVE / DANE" 
projects.

Anyone else who is around on the weekend is welcome to join us.

There are some projects that could use some additional help (including 
non-coding help such as documentation and user testing). You are also welcome 
to bring other projects to the Hackathon.

More info at:  http://ietf.org/hackathon/96-hackathon.html

You can see the list of projects and ideas at (scroll down to find the DNS 
area) on the IETF wiki at:
https://www.ietf.org/registration/MeetingWiki/wiki/96hackathon

The GetDNS crew has a number of projects underway, including TLS interfaces, a 
Universal Acceptance review and RFC5011 testing. Rick Lamb plans to make BIND 
work with smartcards without patches.  I plan to work on the code behind the 
weekly DNSSEC deployment maps.  I'm sure others will bring some projects, too, 
by the time it begins.

If you want to join us (on one or both days), you are asked to register for the 
Hackathon at: https://www.ietf.org/registration/ietf96/hackathonregistration.py

This is separate from the main IETF 96 registration.  In fact, you do NOT need 
to be attending IETF 96 to participate in the Hackathon. Other developers from 
the region are welcome to join in and help.

There's a group of us who have now done this for the past several IETF meetings 
and it's been a great experience and moved a number of DNS-related projects 
forward.  We would definitely welcome anyone else who wants to join us.

See (some of) you there,
Dan



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

[DNSOP] New I-D on DNSSEC crypto algorithm agility - Fwd: New Version Notification for draft-york-dnsop-deploying-dnssec-crypto-algs-00.txt

[Dan York]

DNSOP members,

Today a group of us submitted a draft starting to document the operational 
steps (and issues) around deploying new crypto algorithms within DNSSEC.  This 
builds off of a couple of sessions we've had at DNSSEC Workshops at ICANN 
meetings as well as various mailing list discussion.  This overall discussion 
about deploying new DNSSEC crypto algorithms will continue with a session 
organized by Ondrej Sury at DNS-OARC on April 1 in Buenos Aires and then 
another one at RIPE in Copenhagen.

The goal right now is to document the deployment steps so that there is a 
common understanding and operational guidance can be provided. Ideally in the 
process we may also highlight opportunities for improvement of operational 
processes.

Comments and feedback are definitely welcome.

Thanks,
Dan

Begin forwarded message:

From: <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>
Subject: New Version Notification for 
draft-york-dnsop-deploying-dnssec-crypto-algs-00.txt
Date: March 21, 2016 at 2:29:57 PM EDT
To: "y...@isoc.org<mailto:y...@isoc.org>" 
<y...@isoc.org<mailto:y...@isoc.org>>, Ondrej Sury 
<ondrej.s...@nic.cz<mailto:ondrej.s...@nic.cz>>, "Olafur Gudmundsson" 
<olafur+i...@cloudflare.com<mailto:olafur+i...@cloudflare.com>>, Dan York 
<y...@isoc.org<mailto:y...@isoc.org>>, "Paul Wouters" 
<pwout...@redhat.com<mailto:pwout...@redhat.com>>


A new version of I-D, draft-york-dnsop-deploying-dnssec-crypto-algs-00.txt
has been successfully submitted by Dan York and posted to the
IETF repository.

Name: draft-york-dnsop-deploying-dnssec-crypto-algs
Revision: 00
Title: Observations on Deploying New DNSSEC Cryptographic Algorithms
Document date: 2016-03-21
Group: Individual Submission
Pages: 9
URL:
https://www.ietf.org/internet-drafts/draft-york-dnsop-deploying-dnssec-crypto-algs-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/
Htmlized:   
https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-00


Abstract:
  As new cryptographic algorithms are developed for use in DNSSEC
  signing and validation, this document captures the steps needed for
  new algorithms to be deployed and enter general usage.  The intent is
  to ensure a common understanding of the typical deployment process
  and potentially identify opportunities for improvement of operations.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat


--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.org<mailto:y...@isoc.org>   +1-802-735-1624
Jabber: y...@jabber.isoc.org<mailto: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] MEETING LOGISTICS-- notetakers, scribes, slides

[Dan York]

On Jul 18, 2015, at 12:24 PM, Suzanne Woolf 
suzworldw...@gmail.commailto:suzworldw...@gmail.com wrote:

Jabber scribe: ?

I'll jabber-scribe.   Someone else as a backup would be appreciated.

Dan

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.orgmailto:y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/http://www.internetsociety.org/deploy360/



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

[DNSOP] .KEY - a new example of a non-DNS use

[Dan York]

As we've been having this thread around TLDs, I noticed this item in Hacker 
News this morning of a new overlay network that is designed to use hashes of 
public keys for addressing:

https://github.com/zrm/snow
https://news.ycombinator.com/item?id=9843373
http://trustiosity.com/snow/how-it-works.html

The developer has decided for name resolution **within the overlay network** to 
use hash-of-public-key.key.

I see this as similar to what the Tor folks do with .onion.

I point this out only to show another instance of a developer seeking to use 
DNS-like names (and even DNS tools)... only outside the scope of the regular 
DNS system.

Dan

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.orgmailto:y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/http://www.internetsociety.org/deploy360/



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

[DNSOP] Want to join the IETF 93 Hackathon to work on DNSSEC, DANE or DNS Privacy?

[Dan York]

DNSOP participants,

Will you be in Prague on the weekend before IETF 93? (Or could you get there?)  
A number of us will be involved with the hackathon happening on Saturday and 
Sunday:

https://www.ietf.org/registration/MeetingWiki/wiki/93hackathon

Our intent is to work on some tools/services related to DANE, DNSSEC and/or DNS 
privacy - either adding support to existing tools or projects, or developing 
something new that is useful in some way (and is not a duplicate of something 
else).   We don't have specific projects lined up yet  (we need to meet and 
decide what we're going to do)...  but any suggestions are certainly welcome.

If you'd like to join for either one or both days, the link to sign up is on 
that hackathon page.   Here's what we wrote as an abstract:

  *
DANE / DNS Privacy / DNSSEC
 *
Contribute to access of end-systems to new developments in DNS
 *
Protocols: DANE support for webmail, DNS-over-TLS (application uses), 
DNS-over-DTLS (stack and uses), TLSA client certs, client privacy election for 
EDNS client-subnet, getdns language bindings, etc.
 *
Tools: portable tool for creating and adding DANE RR’s to zones, changes to 
existing tools to support new crypto algorithms, etc.
 *
Measurement: New tools or sites for measuring DNSSEC or DANE deployment
 *
Available open source libraries: https://github.com/verisign/smaug, 
https://github.com/getdnsapi
 *
Available environment, support, and diagnostic tools: https://dnssec-tools.org, 
https://www.opendnssec.org
 *
Champions
*
Dan York, Internet Society y...@isoc.orgmailto:y...@isoc.org
*
Allison Mankin, Verisign Labs aman...@verisign.commailto:aman...@verisign.com
*
Willem Toorop, NLnet Labs
*
Sara Dickinson, Sinodun
*
Others, TBA

Anyone is welcome to join with us.  The current list of participants is here:  
https://www.ietf.org/registration/ietf93/hackathonattendance.py?sortkey=3login=%0Ahttps://www.ietf.org/registration/ietf93/hackathonattendance.py?sortkey=3login=
  (you can see that some people have listed that they will join in for 
DNS-related topics...)

See (some of) you in Prague,
Dan

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.orgmailto:y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/http://www.internetsociety.org/deploy360/



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

Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material

[Dan York]

I’ve been reading this whole discussion with great interest over the past while 
and do intend on joining today’s call.  In the midst of all of this I think two 
points from Andrew and Ed have been helpful to my thinking:

 On May 11, 2015, at 9:06 PM, Andrew Sullivan a...@anvilwalrusden.com wrote:
 
 It seems to me that making new reservations solely on _policy_ grounds
 is overstepping our role, because we actually gave that management
 function away to someone else many years ago.  But if there are
 additional protocol-shift registrations, it would be appropriate to do
 that.

I’m not sure I’m 100% on board with Andrew’s use of the term “protocol-shift” 
to explain the difference, but I do agree with his statement that reservations 
should not be made based *solely* on policy grounds and that there needs to be 
some true protocol-based reason for the reservation.

Even better, I like Ed’s distinction:

 On May 9, 2015, at 7:29 AM, Edward Lewis edward.le...@icann.org wrote:
 
 The problem (the topic of discussion here) I see is that there are class
 of strings that are intended to not be active in the DNS and further more,
 the DNS isn't even meant to be consulted.  


This to me is the key point.  Reserving names like .ONION makes sense to me 
because there is existing Internet infrastructure that is widely deployed and 
uses that TLD-like-name in its operation…. but has no expectation that the name 
would be active in DNS.   Were such a TLD ever to be delegated in DNS, it could 
conceivably *break* these existing services and applications.   Those are the 
kind of names that make sense to be reserved.

I do realize that there is a challenge with determining when something is 
“widely deployed” enough to merit this consideration.  Just because I may have 
some service I created that uses a pseudo-TLD of “.YYY”[1] probably doesn’t 
really rise to the level if only I and 5 other friends use it.  What number 
makes sense?  I don’t know because as others have commented such numbers can be 
easy to game with automated scripts, bots, etc.

My 2 cents,
Dan  (as an individual, not as any statement from ISOC)

[1] I was going to use “.FOO” here but of course someone (Google, in this case, 
maybe at Warren’s request!) did actually register .FOO through the newgTLD 
process.


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

Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case

[Dan York]

Matthijs,

On Jan 15, 2015, at 5:13 AM, Matthijs Mekking 
matth...@pletterpet.nlmailto:matth...@pletterpet.nl wrote:

IXFR with DNSSEC is suddenly not so small anymore. Do you recognize
this? Olafur and I have some ideas on keeping those zone transfers
small. Your feedback is appreciated.

 http://www.ietf.org/internet-drafts/draft-mekking-mixfr-01.txt

I support this draft.  Steps that can improve the efficiency of DNS are good in 
my mind (where reduced packet size is to me being efficient).

In the Security Considerations section you are asking what you should include 
in there.  I think what you say about using MIXFR over a secure channel and 
with TSIG is a good recommendation.

The question would really be to me - can an attacker do anything different with 
MIXFR than with IXFR?  Could an attacker, for instance, use MIXFR to delete 
RRSIGs so that portions of a zone were then unsigned?   Could multiple MIXFR 
records be sent at the same time to create confusion?  Could a MIXFR be used 
for a DoS attack?

And is any of that different from IXFR?  (Or should you then just reference the 
Security Considerations for IXFR?)

I don’t know the answers… but those are the kinds of things I think would be 
good to discuss in the Security Considerations area.

Dan



--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.orgmailto:y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/



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

Re: [DNSOP] More work for DNSOP :-)

[Dan York]

On Mar 6, 2015, at 1:20 PM, Paul Vixie 
p...@redbarn.orgmailto:p...@redbarn.org wrote:

i now realize that the draft should cover meta queries in general, including 
RD=0 to a recursive server, AXFR and IXFR, and ANY of course, and whatever else 
we can come up with. and the recommendation should be to place these query 
types behind some access control mechanism, to prevent them from being used in 
normal DNS operations, but to support their use for diagnostic or other 
close-relationship activities (zone transfers).

While I agree with this idea, I wonder if from a clarity of deployment point of 
view, as well as a speed point of view, it would be easier to divide this into 
two different documents:

1.  Deprecate the ANY query

2. “Meta queries” should be behind some access control mechanism

Is there anyone arguing that the ANY query should still be around?  Or can we 
agree that ANY is now a query that has outlived its usefulness and needs to 
fade away?

I say that because I think if we agree ANY should go, we should be extremely 
clear about that and, as Simon said, break ANY significantly so that people 
stop relying on it and stop supporting it in DNS clients and applications.  Get 
rid of it.

And provide that guidance in an extremely simple and clear manner.
(Realizing, of course, that all we can do is make the recommendation and 
encourage operators and app developers to follow that recommendation.)

Separately, we can also provide guidance that other meta queries should be put 
behind some kind of access control mechanism.   My worry about grouping ANY 
with the other meta queries is that it may indicate to people that it is still 
okay to implement the ANY query.

My 2 cents,
Dan

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.orgmailto:y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/



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

Re: [DNSOP] Using PTRs for security validation is stupid

[Dan York]

Lee,

Warren, in his own unique style, made a point that I was wondering about...

On Nov 11, 2014, at 9:30 PM, Warren Kumari 
war...@kumari.netmailto:war...@kumari.net wrote:

I heard applause during the WG meeting in response to these statements;
sounded like consensus to me. I said I would check that consensus on list.

I think that there is consensus that it is stupid. There is also
consensus that using a fork to get the stuck toast out of the toaster
is a bad idea -- however

... namely that I think probably all of us on the list can agree 100% that 
having SSH servers reject connections from IP addresses without PTRs is stupid. 
  I haven't seen anyone chime in publicly that they think it *is* a good 
idea... and I doubt we will.

But now what?

I'm not sure that there's necessarily a whole lot of value in us coming out 
with a document Using PTRs To Reject SSH Connections Considered Harmful - I 
don't know that our doing so will necessarily motivate the authors of SSH 
servers to change anything. Certainly I think the SSH case could be listed in 
your document of bad things people do with PTRs in IPv4 that will break in IPv6.

Where are you trying to go with this note about consensus?

A bit puzzled,
Dan

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.orgmailto:y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

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

Re: [DNSOP] Fwd: New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt

[Dan York]

Many others have made the points I would have made about the operational value 
of NTAs so I won't repeat those... but I want to just say that I think Paul 
Ebersman nails it here:

On Oct 26, 2014, at 12:09 PM, Paul Ebersman 
list-dn...@dragon.netmailto:list-dn...@dragon.net
 wrote:

 I see NTA as a tool that we should try to never use but which is
invaluable when we do need it.

Exactly!  Hopefully everything just works 99% of the time... but in the event 
something doesn't work right the operators have a narrow scalpel tool in 
their toolbox that they can pull out rather than resorting to more drastic 
measures such as, for example, disabling all DNSSEC validation.

Ideally NTAs never get used and as DNSSEC deployment moves along and DNS 
operators get increasingly familiar with the operational practices required of 
DNSSEC then the need for NTAs will eventually fade away.

My agenda in pushing this draft is not to advocate wide spread use but
to guarantee that all of my vendors have an RFC to code against so that
I have consistent behavior and plenty of server choices for server
diversity.

Yes!   If we have an operational need to have a way to generate DNSSEC 
validation exceptions, let's please have *one* way that we can collectively 
agree upon rather than having every different operator come up with some custom 
mechanism that works only for them.  This will make the overall deployment that 
much easier if the one method is spread across multiple software vendors and 
systems.

My 2 cents,
Dan

P.S. Nice quote, Warren!

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.orgmailto:y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/


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

Re: [DNSOP] Call for Adoption: draft-bortzmeyer-dns-qname-minimisation

[Dan York]

On Oct 7, 2014, at 12:04 AM, Tim Wicinski 
tjw.i...@gmail.commailto:tjw.i...@gmail.com
 wrote:

Please review this draft to see if you think it is suitable for adoption by 
DNSOP, and comments to the list, clearly stating your view.

I support adoption of this draft.

Please also indicate if you are willing to contribute text, review, etc.

Yes, I will.

Regards,
Dan

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.orgmailto:y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

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

Re: [DNSOP] scribes, notetakers

[Dan York]

Suzanne,

I'll be glad to be a jabber scribe.  If there's someone else who wants to help 
with that, too, the assistance would be great as I do sometimes find myself at 
the microphone. ;-)

Dan

On Jul 22, 2014, at 7:12 AM, Suzanne Woolf suzworldw...@gmail.com
 wrote:

 As usual…..desperately needed. Any volunteers in advance will be welcome.
 
 thanks,
 da chairs
 ___
 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] draft-wkumari-dnsop-dist-root-01.txt

[Dan York]

I would suggest there is also a third angle here:

On Jul 8, 2014, at 11:30 PM, yzw_iplab 
yzw_ip...@163.commailto:yzw_ip...@163.com
 wrote:

Hi, all,
There are currently two solutions proposed to distrbute the DNS root service 
more widely.In my opinion, we should work on this issue following the two steps:
1) we should discuss their feasibility from technological aspects. the 
technological requirements of them should be gathered and listed ,and then 
analyzed one by one.
2) these two solutions consider the similar issue from different levels: one is 
the recursive-level and another one is the authorative-level. (if both of them 
are feasible) we should figure out respective scenarios and requirements 
suitable for each of them.
3) we should discuss how easily the solutions can actually be *deployed* and 
used.

I realize this is perhaps a subset of #1, but I want to call it out 
specifically because this step seems to be sometimes overlooked.  If, for 
instance, a solution requires changes to the way stub resolvers work and 
requires updates to the zillions of devices out there that now provide embedded 
DNS resolvers, the chances of that solution being *widely* deployed are 
significantly less than a solution that requires changes at only, say, 
authoritative name servers.  Not to say the first solution *couldn't* be 
deployed, but we just need to be realistic up front about what it might take to 
get the solution out there.

My 2 cents,
Dan  (who spends his days looking at how to get DNSSEC more widely deployed)

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.orgmailto:y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

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

[DNSOP] CNAMEs at Zone Origin - Re: call to work on edns-client-subnet

[Dan York]

Tim,

On May 16, 2014, at 9:31 AM, Tim Wicinski 
tjw.i...@gmail.commailto:tjw.i...@gmail.com
 wrote:

On 5/16/14, 8:18 AM, Andrew Sullivan wrote:

Second, the Internet is actually working today using those kinds of
CDN tricks.  Indeed, some of the most important and most successful
nodes on the Internet rely very heavily on various DNS tricks, and
without them wouldn't be operating.  If we are serious about making
the Internet better, surely we ought to have an opinion on how to
offer (as well as can be achieved given other strictures) the
functionality that is in fact ubiquitous. snip Either those who understand 
how the
DNS works will document what to do, or else people who have no clue
will make more improvements.

In this bucket you can put in all the 'CNAMEs at Zone Origin work done by both 
the CDN vendors and the commercial DNS vendors in this space.

I was thinking once the Charter had been finished being blessed, I would put my 
toe in that water and see what lies beneath the surface.

On a personal level I'd love to see some work done on CNAMEs at Zone Origin 
as the issue just bit me with one of my own sites. For a good number of years 
I've been giving out just the domain name as the web address and that worked 
fine with me providing an A and  record pointing over to the hosting 
provider (all DNSSEC-signed, of course).Then recently the hosting provider 
got slammed with a massive DDoS attack and in fighting off that attack they put 
up a CDN in front of all the hosted web sites.

We customers were then told to ensure we were using CNAMEs instead of direct 
addresses... for me this has meant unfortunately having to switch to using 
www.domainname for that site and setting the CNAME there.  I'm still 
working out which of the various DNS tricks from different providers that 
I'll have to use to get the raw domain name to point correctly over to the web 
hosting provider and given that I have many years of posts out there with 
links to the raw domain name this is kind of important to me.

For some time now I've been seeing in the marketing/communication space an 
increasing usage of dropping the www and just promoting the raw domain name.  
I think with the many hundreds of newgTLDs coming out we'll probably see people 
there seeking to use only the domain name for their website.

And many of them will want to use hosting providers or CDNs where the desired 
configuration is to point a CNAME over to the hosting/CDN provider which 
leaves them stuck - or resorting to DNS tricks - if they want to use the zone 
name itself as their web site address.

So yes, I think this is very definitely a current operational problem that 
needs to be worked on.

My 2 cents,
Dan


--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.orgmailto:y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

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

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

[Dan York]

On Apr 16, 2014, at 8:02 AM, Warren Kumari 
war...@kumari.netmailto:war...@kumari.net
 wrote:

I think I made it even clearer:
The first time a DNS operator signs a zone, they need to communicate
the keying material to their parent through some out-of-band method to
complete the chain of trust. Depending on the desires of the parent,
the child might send their DNSKEY record, a DS record, or both.

Good?

Looks good to me.The whole document is looking very good.  I've been 
reading the conversation and initially had some concerns but others already 
addressed the points (and so I felt no need to add to the queue of messages).

Dan

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.orgmailto:y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/


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

Re: [DNSOP] Changes to Charter

[Dan York]

Tim,


I support these changes as they seem to be logical modifications to the
charter, particularly given the closing of the DNSEXT wg.  I personally
don't know that DNSSEC needs to be added to point #5, as I do see it as a
natural extension of DNS.  However, I could see that for clarity for other
people it might be useful.  Perhaps just adding DNSSEC into the list of
options would work such as:

 5. Address possible minor changes or extensions to the DNS Protocol,
 initially with a focus on the operational impacts of these changes. Act
 as clearinghouse or providing advice to ADs and other WGs on EDNS0
 options, new RRTYPEs, record synthesis, DNSSEC, or other mechanics of
extending
 DNS to support other applications.


Again, I don't know that this is 100% required, but it may be a simple
change to help things be 100% clear to all.

I agree with Warren that the wording of the last sentence of point #6
isn't clear, and thank you for your explanation, Tim.  What about this?
--
6.  Publish documents that address DNS-related issues, by identifying
and documenting the problem space around the issue. The group will then
identify whether these issues should be addressed within DNSOP or
within another appropriate working group.
--

Or perhaps starting it differently:
--
6. Serve as a clearinghouse for DNS-related issues where people can bring
drafts that document the problem space around DNS issues.  The group will
then decide whether those issues belong in DNSOP or will work with the
authors 
and appropriate ADs to determine the appropriate group for the work.
--

It sounds like you are trying to do something sort of like what the RAI
area did with the DISPATCH working group where people could bring work
ideas that related to real-time communications and that working group
would dispatch the issues to the appropriate existing working group - or
create a new working group to take on that new work.In the case of
DISPATCH, that group exists solely to serve as this clearinghouse and is
not chartered to perform specific work itself (
http://datatracker.ietf.org/wg/dispatch/charter/ ).

In this case, it sounds like you are looking for this to be a *part* of
what DNSOP is to be about.  (And I can see that being a useful function as
it is not clear where else someone would bring new DNS-related questions
*except* to DNSOP.)

Dan



On 3/19/14 3:42 PM, Tim Wicinski tjw.i...@gmail.com wrote:


Hello

This is a conversation I've scheduled a few times and I did poor time
mangement.  After some discussion we're proposing adding two items to
the DNSOP charter:

---

5. Address possible minor changes or extensions to the DNS Protocol,
initially with a focus on the operational impacts of these changes. Act
as clearinghouse or providing advice to ADs and other WGs on EDNS0
options, new RRTYPEs, record synthesis, or other mechanics of  extending
DNS to support other applications.

6.  Publish documents which address DNS-related issues, by identifying
and documenting the problem space around the issue. The group will then
discuss these issues and decide if which group should address the
solution space.

--

We welcome your feedback either on the items, the wording, or anything
you wish to comment on.

thanks

tim

___
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] housekeeping for DNSOP meetings: volunteers needed

[Dan York]

Suzanne,


On 3/6/14 10:51 AM, Suzanne Woolf suzworldw...@gmail.com wrote:

DNSOP now has two meetings to manage, both with packed agendas. This
means your chairs will really appreciate early volunteers for note-takers
and jabber scribes.

Please drop us a note if you can do either job for either session.

I am glad to help with Jabber for both sessions. As we're in some larger
rooms, I would welcome someone else to help, too (and, for example, to sit
near another microphone to help capture people's names).

Pitch: you might get more out of the session if you're forced to ignore
your email,

That's a large part of why I *do* volunteer for Jabber scribing.  It
forces me to pay attention to exactly what is going on.  Plus, it forces
me to learn people's names. :-)

Dan

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

[DNSOP] DNS privacy and Team Cymru's report on 300, 000 SOHO routers with compromised DNS settings

[Dan York]

DNSOP members,

Given our session today talking about protecting DNS privacy, I found an 
interesting bit of synchronicity upon going back to my room and seeing this 
article in my feeds about a compromise of at least 300,000 small office / home 
office (SOHO) home routers  by a variety of attacks in which their DNS server 
values were changed and consumers were redirected to other pages as a result:

http://www.circleid.com/posts/widespread_compromised_routers_discovered_with_altered_dns_configurations/
(and 
http://www.circleid.com/posts/20140305_dynamic_dns_customers_check_your_router_settings/
 )

The actual report from Team Cymru was announced just this past Monday - 
https://twitter.com/teamcymru/status/440488571666198528  and is available at:

https://www.team-cymru.com/ReadingRoom/Whitepapers/2013/TeamCymruSOHOPharming.pdf

Now, in this case the attackers compromised the local network devices and took 
over control of the local recursive resolvers.  In this case of the attacker 
controlling the recursive resolver, I don't know that any of the various 
solutions thrown around today would do anything to help with this.  I don't 
even see DNSSEC helping much here, either, given that the attacker could just 
strip out the DNSSEC info (unless, perhaps, the home computers were running 
full (vs stub) recursive resolvers that also did DNSSEC-validation).

I just thought it was an interesting example of a type of attack against DNS 
that is out there now.

Dan

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.org mailto:y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.org mailto:y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

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

Re: [DNSOP] [Uta] dnse related docs.

[Dan York]

On 3/4/14 8:00 PM, Joel Jaeggli joe...@bogus.com wrote:

If we created a new session in the thursday evening 18:40-20:40 slot to
accommodate expanded discussion of the Drafts discussed during DNSE and
deconflicted that discussion with UTA on friday morning would that be a
significant imposition? it seems unlikely that more than a 1/3 of the
slot would be required.

I think this would be useful if it enables folks proficient with TLS who
want to go to UTA Friday morning to weigh in on the DNS confidentiality
discussion and ideas and issues around the potential use (or not) of TLS.

Having said that, I think the usefulness of the session will depend upon
how many people who were part of the DNSE BOF can attend a Thursday night
session.  Do we have a sense yet of how many DNSE presenters and authors
of related drafts would be able to attend? (And people who asked questions
during the DNSE BOF?)

My 2 cents,
Dan

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

[DNSOP] Moving parent-child-update documents forward

[Dan York]

Peter  Tim,

Unfortunately we ran out of time in the DNSOP session yesterday and I don't
feel we left with a plan to move forward on the various
parent-child-update documents and scenarios.  However I think it is
*critical* that we DO move forward with these documents as this issue is
one of the big barriers for smoother operation of DNSSEC.

I think there was a strong sense in the room that we definitely need to
work on this overall issue and I think at the end we were getting hung up
on some process points (and I admit that *I* was contributing to that
confusion)... and then we simply ran out of time.

What do you see as a path forward here?  How can we progress these
documents?

The point I was trying to make in the final minutes was that we need
something *more* than just these documents to help get these solutions
actually out there and deployed.  I think we need to provide operational
guidance to registrars and registries on the different mechanisms for
updating these type of DNS records and explain the options that we have
available.  We need to make it easy for them to understand how the
mechanisms fit together and can be used in different situations.

But I think that kind of document can be written separately from moving the
other documents forward (and yes, I'm willing to help with text and not
just say that someone should write a doc).

I don't see why we can't adopt the CDS/CDNSKEY and CSYNC drafts as working
group documents and continue to move them along - we've had significant
discussion on these over the past several meetings and also on the lists:

http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds-05
http://tools.ietf.org/html/draft-hardaker-dnsop-csync-01

Similarly, I think Mark's draft could be another one to consider adopting
for situations where people want to operate the push-style model:

http://tools.ietf.org/html/draft-andrews-dnsop-update-parent-zones-00

I think we need some more discussion on that document before we adopt it (I
haven't seen any on the list, or did I miss it?) but I don't see any issue
with ALSO having a document like it as a working group document.  There
will be multiple models for different situations.

Additionally, I think Paul's document on use cases is one that we should be
bringing back into circulation (thanks, Matthijs, for the pointer after
Paul mentioned it yesterday):

http://tools.ietf.org/html/draft-wouters-dnsop-secure-update-use-cases-00

Anyway - I think we do need to move this whole area of work forward as
rapidly as we can.

My 2 cents,
Dan

--
Dan York, dan-i...@danyork.org
http://danyork.me   http://twitter.com/danyork
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop