Re: [DNSOP] Fundamental ANAME problems

2018-11-09 Thread Richard Gibson
Responses inline. On 11/9/18 11:39, Tony Finch wrote: Richard Gibson wrote: First, I am troubled by the requirement that ANAME forces the zone into a dynamic zone. I don't see how it is possible to implement ANAME without some form of dymamic behaviour, either by UPDATEs on the primary, or

Re: [DNSOP] Fundamental ANAME problems

2018-11-09 Thread Tony Finch
Richard Gibson wrote: > > First, I am troubled by the requirement that ANAME forces the zone into a > dynamic zone. I don't see how it is possible to implement ANAME without some form of dymamic behaviour, either by UPDATEs on the primary, or on-demand substitution on the secondaries, or some

Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

2018-11-09 Thread Tony Finch
Ray Bellis wrote: > > does so at the expense of significant complexity in authority servers by > still requiring A and lookups to be somehow "magic", That is not the case for the -02 draft. Tony. -- f.anthony.n.finchhttp://dotat.at/ an equitable and peaceful international order

Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

2018-11-09 Thread Måns Nilsson
Subject: Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME Date: Thu, Nov 08, 2018 at 06:30:41PM -0800 Quoting Paul Vixie (p...@redbarn.org): > i am loath to create per-service record types. that's why SRV. if you really > want every client of a service to query for something

Re: [DNSOP] Fundamental ANAME problems

2018-11-09 Thread Tim Wicinski
On 11/9/18 05:03, Matthijs Mekking wrote: It seems that everyone thinks that the latest ANAME draft requires DNS UPDATE. This is just a use case that Tony provides and would help him in his daily operations. However, it is not required to do so: ANAME resolution can also happen by updating

Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME vs URI vs NAPTR

2018-11-09 Thread Brian Dickson
Patrik Fältström wrote: > Note changed subject... > > [rest of message cut from reply] There is a major semantic difference in the NAPTR/URI RDATA and how/where it is handled, which is at the HTTP application layer (i.e. 3xx rewriting). This differs from the other 4 RRTYPEs, where only the

[DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME vs URI vs NAPTR

2018-11-09 Thread Patrik Fältström
Note changed subject... Sure, I think of course the URI RR is the best thing since sliced bread, but same for each one of the proponents of the other RRs. I think we could look at the various deployment scenarios and demonstrate what design features each one of the RRs have. And with such a

Re: [DNSOP] Fundamental ANAME problems

2018-11-09 Thread Matthijs Mekking
On 11/9/18 4:27 AM, Richard Gibson wrote: I have finally reviewed the latest draft directly, and like the overall direction but have a small number of issues (however, the issues theirselves are somewhat fundamental). They broadly break down into concerns about zone transfers and TTL

Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

2018-11-09 Thread Matthijs Mekking
On 11/9/18 1:57 AM, Ray Bellis wrote: On 09/11/2018 07:14, Tony Finch wrote: But remember: the goal is to make the DNS easier to use for people who don’t know about the restrictions on CNAMEs. I'd say the goal is to make the DNS *possible* to use for people who don't know about the