Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

From: Tim Wicinski <[email-masked]>
Date: Thu, 5 Jul 2018 11:28:32 -0400

All

Thanks for this highly entertaining and also information conversation.  I
apologize for kicking up the dust but I feel this is one of those
conversations where the end-users/operators and protocol people are
disconnected.    I do know when we talked with several DNS providers about
a standard was of synthesizing names at the apex, we encountered a similar
level of pushback.  Most of them spent the time explaining how
sophisticated their method was over Vendor Y.

But I don't think it's an impossible problem to solve, and this thread is
full of very smart people attempting to do that.   I admit I look at this
problem too much through the lens of someone who thinks about operational
issues. (I am probably not the only one here who was paged in the middle of
the night when someone rolled out 9.12 without reading the fine print).

What we do know is:

 - We're not going to do SRV records (sorry Mark).
 - We're not going to ask the IAB to give a waiver on DNSSEC.
 - We still bang into each other over this.

The chairs have decided to set aside some time in Montreal and see if we
can work through this problem.  We've asked Ondřej  from ISC and Willem
from NLnetLabs to help guide the talk.

Thanks
Tim

On Mon, Jun 25, 2018 at 1:00 PM, Paul Vixie <[email-masked]> wrote:

>
>
> Tony Finch wrote:
>
>> Paul Wouters<[email-masked]>  wrote:
>>
>>> I understand, I just disagree this is the right way. I don't see why
>>> this entire problem shouldn't be resolved at the well, resolver level.
>>>
>>
>> I don't see how that can be deployed in a way that is compatible with
>> existing software.
>>
>
> there are now a half dozen x.x.x.x (where x is the same in all four
> octets) public anycast resolvers. if they can all be upgraded to handle
> dnssec or ECS, they can all be upgraded to handle something like ANAME.
>
> the "resolver" here is the recursive, not the stub. stubs believe what
> they hear, for good or ill. if we need to change what they hear, it's not
> as impossible as changing what they understand.
>
> --
> P Vixie
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 05 Jul 2018 08:43:13 -0700

On 5 Jul 2018, at 8:28, Tim Wicinski wrote:

> I admit I look at this
> issues.

Errrr, that's not a bad thing. This is DNSOP, not DNSEXT, after all.

> from NLnetLabs to help guide the talk.

Hopefully the mic line is mostly OP, not EXT, folks. We can EXT all we 
want, but the purpose of this specific work is to improve OP.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Thu, 5 Jul 2018 17:15:18 +0100

> from NLnetLabs to help guide the talk.

I was hoping that there would be another revision of the draft following
IETF 101, based on the discussions we had then.

Is there some huge problem that I haven't noticed?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
champion the freedom, dignity, and well-being of individuals

---

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Jul 2018 13:40:34 -0700

Tim Wicinski wrote:
> ...

i think you will find that there is no dnssec-compatible way to solve 
this problem without upgrades to both authority AND recursive AND stub 
dns agents, AND to the getnameinfo-or-similar API. if i'm right, it'll 
be necessary to make hard choices, such has, reconsider the constraints.

-- 
P Vixie

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 6 Jul 2018 08:22:41 +0200

> IETF 101, based on the discussions we had then.

Me too :)

https://github.com/each/draft-aname/pulls

Matthijs

---

From: "John Levine" <[email-masked]>
Date: 6 Jul 2018 12:33:15 -0400

>be necessary to make hard choices, such has, reconsider the constraints.

You're probably right, but I think that ANAME would need as many
upgrades, just in slightly different places.

Using CNAME has the (perhaps hypothetical) advantage that if we do it,
a lot of existing zone files that are now invalid will have become valid
with defined semantics.

R's,
John

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Jul 2018 17:48:47 +0100

> upgrades, just in slightly different places.

ANAME should work without upgrades, because A and AAAA queries will get
the answers they expect. ANAME support is just a performance optimization
when the ANAME target is going geodns tricks.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet: Variable mainly west 3 or 4. Slight. Fog patches developing.
Moderate or good, occasionally very poor.

---

From: Evan Hunt <[email-masked]>
Date: Fri, 6 Jul 2018 17:47:57 +0000

> https://github.com/each/draft-aname/pulls

Yes, sorry, my bad. I'll try to address the pull requests next week.
Should've done ages ago.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.