Re: [DNSOP] Minimum viable ANAME

2019-03-28 Thread Benno Overeinder
On 26/03/2019 23:49, Dan York wrote: > 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

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread 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

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Tony Finch
> On 26 Mar 2019, at 18:23, Brian Dickson wrote: > > The options are, new RRtypes that require resolver upgrades, or RRtypes that > are handled by the client application (browser), which benefit from (but do > not require) resolver upgrades. The current draft is neither of those (and I

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Olli Vanhoja
On Tue, Mar 26, 2019 at 9:20 PM Brian Dickson wrote: > > > > On Tue, Mar 26, 2019 at 8:31 PM Olli Vanhoja wrote: >> >> On Tue, Mar 26, 2019 at 7:23 PM Brian Dickson >> > We need to start with the base requirements, which is, "I want an apex RR >> > that allows HTTP browser indirection just as

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Brian Dickson
On Tue, Mar 26, 2019 at 8:31 PM Olli Vanhoja wrote: > On Tue, Mar 26, 2019 at 7:23 PM Brian Dickson > > 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". > > Sibling records do not behave like

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Olli Vanhoja
On Tue, Mar 26, 2019 at 7:23 PM Brian Dickson > 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". > Sibling records do not behave like CNAMEs, no matter what extra hacks get > applied; CNAME

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Brian Dickson
On Tue, Mar 26, 2019 at 6:02 PM Olli Vanhoja wrote: > On Tue, Mar 26, 2019 at 5:36 PM Vladimír Čunát > wrote: > > > > I'm not convinced that the resolver parts will be important, regardless > of what exact mechanism will be chosen. My reasoning is that you can't > rely on any changes there

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Vladimír Čunát
On 3/26/19 6:01 PM, Olli Vanhoja wrote: I think it's totally wrong to*choose* here what we think is the best method to solve the issue. I think it goes the direction you'll like.  My understanding of the current plan (of open-source implementors) is to have an RFC specifying *as little* as

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Olli Vanhoja
On Tue, Mar 26, 2019 at 5:36 PM Vladimír Čunát wrote: > > I'm not convinced that the resolver parts will be important, regardless of > what exact mechanism will be chosen. My reasoning is that you can't rely on > any changes there being widely deployed soon, and there might not be enough >

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Vladimír Čunát
On 3/26/19 5:10 PM, Tony Finch wrote: I haven't seen any objections to support for ANAME in recursive servers so I'm surprised you think that is problematic enough to be removed. I'm not convinced that the resolver parts will be important, regardless of what exact mechanism will be chosen. 

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Matthijs Mekking
On 3/26/19 5:10 PM, Tony Finch wrote: Matthijs Mekking wrote: I think that would be the wrong direction. I believe there is a need to standardize the ANAME resolution process and so my suggestion would be to reduce the scope by focusing just on how to do that on the provisioning side (and

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Matthijs Mekking
I stand corrected indeed, I just went to the mailing list to find the latest version of the draft and noticed there were many fundamental arguments. Matthijs On 3/26/19 5:19 PM, Tony Finch wrote: Matthijs Mekking wrote: The last draft did not see a lot of comments. I thought there was

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Brian Dickson
I think the one proposal was very client-specific, which kind of ruled it out for a generic "aname" type. That was Ray's "HTTP" RRtype, that I did a deep dive on. Basically, you are correct; the easiest path forward would be for client software upgrades to get actual DNS records (rather than rely

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Tony Finch
Matthijs Mekking wrote: > > The last draft did not see a lot of comments. I thought there was quite a lot of very informative and robust discussion in November. https://mailarchive.ietf.org/arch/msg/dnsop/fmMGXQA0ryaJdtjSCVEsQ9ZiF2M

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Tony Finch
Matthijs Mekking wrote: > > I think that would be the wrong direction. I believe there is a need to > standardize the ANAME resolution process and so my suggestion would be to > reduce the scope by focusing just on how to do that on the provisioning side > (and leave secondary servers and

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Matthijs Mekking
Hi Tony, On 3/26/19 4:32 PM, Tony Finch wrote: I'm overloaded at the moment so I wasn't able to rev the draft in time for IETF 104. I was planning to (basically) re-focus on the meaning of the bits on the wire, and remove any requirements about how zone contents are provisioned. Instead there

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Tony Finch
I'm overloaded at the moment so I wasn't able to rev the draft in time for IETF 104. I was planning to (basically) re-focus on the meaning of the bits on the wire, and remove any requirements about how zone contents are provisioned. Instead there would be a series of examples of existing

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Matthijs Mekking
That was me on the mic. To clarify: DNS open source implementers discussed it earlier this week to see if there is still appetite for ANAME. The last draft did not see a lot of comments. To get things moving again we thought it might be a good idea to make a document with reduced scope.

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread 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

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread tjw ietf
No I said I want to reset and work toward an interim. >From my high tech gadget > On Mar 26, 2019, at 15:35, Olli Vanhoja 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. > >

Re: [DNSOP] Minimum viable ANAME

2019-03-26 Thread Olli Vanhoja
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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Minimum viable ANAME

2018-11-06 Thread Mark Andrews
> On 7 Nov 2018, at 4:54 pm, Ben Schwartz wrote: > > > > On Tue, Nov 6, 2018 at 5:53 PM Mark Andrews wrote: > > > > On 7 Nov 2018, at 9:25 am, Ben Schwartz wrote: > > > > > > > > On Tue, Nov 6, 2018 at 5:06 PM Mark Andrews wrote: > > > > > > > On 6 Nov 2018, at 5:27 am, Ben

Re: [DNSOP] Minimum viable ANAME

2018-11-06 Thread Ben Schwartz
On Tue, Nov 6, 2018 at 5:53 PM Mark Andrews wrote: > > > > On 7 Nov 2018, at 9:25 am, Ben Schwartz wrote: > > > > > > > > On Tue, Nov 6, 2018 at 5:06 PM Mark Andrews wrote: > > > > > > > On 6 Nov 2018, at 5:27 am, Ben Schwartz 40google@dmarc.ietf.org> wrote: > > > > > > On Sat, Nov 3,

Re: [DNSOP] Minimum viable ANAME

2018-11-06 Thread Mark Andrews
> On 7 Nov 2018, at 9:25 am, Ben Schwartz wrote: > > > > On Tue, Nov 6, 2018 at 5:06 PM Mark Andrews wrote: > > > > On 6 Nov 2018, at 5:27 am, Ben Schwartz > > wrote: > > > > On Sat, Nov 3, 2018 at 4:12 PM Erik Nygren wrote: > > How does draft-schwartz-httpbis-dns-alt-svc-02 with some

Re: [DNSOP] Minimum viable ANAME

2018-11-06 Thread Mark Andrews
> On 6 Nov 2018, at 5:27 am, Ben Schwartz > wrote: > > On Sat, Nov 3, 2018 at 4:12 PM Erik Nygren wrote: > How does draft-schwartz-httpbis-dns-alt-svc-02 with some changes to make it > more DNS-aligned (e.g. the name as a separate field in the record) not help > here? > > Thanks for

Re: [DNSOP] Minimum viable ANAME

2018-11-06 Thread Mark Andrews
> On 6 Nov 2018, at 11:38 pm, Matthijs Mekking wrote: > > > > On 06-11-18 12:39, Ray Bellis wrote: >> On 06/11/2018 17:58, Matthijs Mekking wrote: >>> That's the crux: A solution that depends on upgrading the resolvers is >>> considered not a (fast enough) deployable solution. >> The HTTP

Re: [DNSOP] Minimum viable ANAME

2018-11-06 Thread Matthijs Mekking
On 06-11-18 12:39, Ray Bellis wrote: On 06/11/2018 17:58, Matthijs Mekking wrote: That's the crux: A solution that depends on upgrading the resolvers is considered not a (fast enough) deployable solution. The HTTP record does not depend on resolvers being upgraded.   If the browser

Re: [DNSOP] Minimum viable ANAME

2018-11-06 Thread Ray Bellis
On 06/11/2018 17:58, Matthijs Mekking wrote: That's the crux: A solution that depends on upgrading the resolvers is considered not a (fast enough) deployable solution. The HTTP record does not depend on resolvers being upgraded. If the browser vendors implement the client side, it's not

Re: [DNSOP] Minimum viable ANAME

2018-11-06 Thread Matthijs Mekking
On 06-11-18 10:19, Ray Bellis wrote: On 06/11/2018 16:15, Matthijs Mekking wrote: As nice and clean the HTTP record draft is, without specifying how to do expansion of the record into address records it is not going to solve the CNAME-at-the-apex problem that DNS providers have, and we

Re: [DNSOP] Minimum viable ANAME

2018-11-06 Thread Ray Bellis
On 06/11/2018 17:17, Tim Wicinski wrote: In doing some digging through my data, I have instances which I have an apex of a zone, sub zone, etc that are not HTTP but actually a dynamic database endpoint. I also have solid number of instances where the apex is used mainly as an API

Re: [DNSOP] Minimum viable ANAME

2018-11-06 Thread Tim Wicinski
In doing some digging through my data, I have instances which I have an apex of a zone, sub zone, etc that are not HTTP but actually a dynamic database endpoint. I also have solid number of instances where the apex is used mainly as an API endpoint, that serves not HTTP web content. just data

Re: [DNSOP] Minimum viable ANAME

2018-11-06 Thread Ray Bellis
On 06/11/2018 16:15, Matthijs Mekking wrote: As nice and clean the HTTP record draft is, without specifying how to do expansion of the record into address records it is not going to solve the CNAME-at-the-apex problem that DNS providers have, and we will stick with the proprietary solutions

Re: [DNSOP] Minimum viable ANAME

2018-11-06 Thread Matthijs Mekking
As nice and clean the HTTP record draft is, without specifying how to do expansion of the record into address records it is not going to solve the CNAME-at-the-apex problem that DNS providers have, and we will stick with the proprietary solutions (this may solve a different use case though).

Re: [DNSOP] Minimum viable ANAME

2018-11-05 Thread Paul Vixie
Mark Andrews wrote: if the stub who asked the SRV question does not receive the addresses it needs in additional data, it will query for them. that will put those addresses in cache, so that on subsequent same-SRV questions, it will be present. And that requires 2 RTT’s from the client

Re: [DNSOP] Minimum viable ANAME

2018-11-05 Thread Tim Wicinski
I agree. We're not trying to boil the DoH Oceans. On Mon, Nov 5, 2018 at 3:42 PM Ray Bellis wrote: > > > On 05/11/2018 12:51, Brian Dickson wrote: > > > It's a lot better than ANAME, and I think we do a disservice to > > ourselves as a DNS community, if we do anything other than put our > >

Re: [DNSOP] Minimum viable ANAME

2018-11-05 Thread Ray Bellis
On 05/11/2018 12:51, Brian Dickson wrote: It's a lot better than ANAME, and I think we do a disservice to ourselves as a DNS community, if we do anything other than put our collective support into it, preferably unanimously. Thank for you the support! I see getting http adopted and

Re: [DNSOP] Minimum viable ANAME

2018-11-04 Thread Brian Dickson
Paul Vixie wrote: > Ray Bellis wrote: > > On 21/09/2018 20:12, Dan York wrote: > > > 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. > > [...] > > i think that

Re: [DNSOP] Minimum viable ANAME

2018-11-04 Thread Mark Andrews
> On 5 Nov 2018, at 2:06 pm, Paul Vixie wrote: > > > > Mark Andrews wrote: >> >>> On 4 Nov 2018, at 7:01 pm, Paul Vixie wrote: > ... >>> that would be a mistake. we are hitting for average here not power >>> -- the behaviour to optimize for is whatever's most common. if the >>> SRV is

Re: [DNSOP] Minimum viable ANAME

2018-11-04 Thread Paul Vixie
Mark Andrews wrote: On 4 Nov 2018, at 7:01 pm, Paul Vixie wrote: that would be a mistake. we are hitting for average here not power -- the behaviour to optimize for is whatever's most common. if the SRV is used, the or A RRsets will be fetched, and thus cached. if the SRV is

Re: [DNSOP] Minimum viable ANAME

2018-11-04 Thread Mark Andrews
> On 4 Nov 2018, at 7:01 pm, Paul Vixie wrote: > > > > Ray Bellis wrote: >> >> >> On 04/11/2018 08:05, Ray Bellis wrote: >> >>> AFAIK, BIND does not currently do this. That said, MarkA has a patch >>> that supports it, so we do know it's possible. >> >> Correction - BIND *does* do

Re: [DNSOP] Minimum viable ANAME

2018-11-04 Thread Paul Vixie
Ray Bellis wrote: On 04/11/2018 08:05, Ray Bellis wrote: AFAIK, BIND does not currently do this. That said, MarkA has a patch that supports it, so we do know it's possible. Correction - BIND *does* do this, but only for address records that are already in the cache. If the for the

Re: [DNSOP] Minimum viable ANAME

2018-11-04 Thread Ray Bellis
On 04/11/2018 08:05, Ray Bellis wrote: AFAIK, BIND does not currently do this.  That said, MarkA has a patch that supports it, so we do know it's possible. Correction - BIND *does* do this, but only for address records that are already in the cache. If the for the target is in the

Re: [DNSOP] Minimum viable ANAME

2018-11-03 Thread Ray Bellis
On 04/11/2018 06:53, Paul Vixie wrote: the arguments against SRV in that document are unsupported and wrong. They are something of a straw man, yes. We did hear unequivocally at the side meeting in Montreal that SRV is not acceptable to the HTTP folks, though, for the broad reasons

Re: [DNSOP] Minimum viable ANAME

2018-11-03 Thread Paul Vixie
Ray Bellis wrote: On 21/09/2018 20:12, Dan York wrote: 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. I agree, and earlier today (well, yesterday, now) I

Re: [DNSOP] Minimum viable ANAME

2018-11-03 Thread Erik Nygren
How does draft-schwartz-httpbis-dns-alt-svc-02 with some changes to make it more DNS-aligned (e.g. the name as a separate field in the record) not help here? It comes from the HTTP world and is aligned with the existing AltSvc feature and thus is useful in other ways (such as perhaps solving the

Re: [DNSOP] Minimum viable ANAME

2018-11-03 Thread Ray Bellis
On 21/09/2018 20:12, Dan York wrote: 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. I agree, and earlier today (well, yesterday, now) I wrote it up: A new

Re: [DNSOP] Minimum viable ANAME

2018-10-03 Thread Havard Eidnes
>> > except that we heard at the side meeting in Montreal (albeit from >> > browser people rather than content people) that they *don't* want >> > SRV, because it has fields that are not compatible with the web >> > security model. >> >> Can you summarize the particulars of the web security model

Re: [DNSOP] Minimum viable ANAME

2018-10-03 Thread Tony Finch
Tim Wicinski wrote: > > I do like where Mr. Finch is taking this discussion. I'll try to find some time to butcher the draft into my kind of shape. Tony. -- f.anthony.n.finchhttp://dotat.at/ the quest for freedom and justice can never end ___

Re: [DNSOP] Minimum viable ANAME

2018-10-03 Thread Tim Wicinski
To bring this dead horse back to life... What I said in Montreal is SRV works great if you are a robot, but when humans are involved it never ends well. I do like where Mr. Finch is taking this discussion. I also don't see the issue with online signing, but that is just me. Tim On Thu, Sep

Re: [DNSOP] Minimum viable ANAME

2018-09-27 Thread Havard Eidnes
>> I also feel from this discussion, we are all roughly on the same >> page. We want SRV as the long term solution ... > > except that we heard at the side meeting in Montreal (albeit from > browser people rather than content people) that they *don't* want > SRV, because it has fields that are

Re: [DNSOP] Minimum viable ANAME

2018-09-27 Thread Tony Finch
Havard Eidnes wrote: > >> If I look up foo and it has an ANAME to bar, which of these do I get > >> back? > > > > ; ANSWER SECTION > > foo. A 1.2.3.4 > > Who provides the DNSSEC proof for this record? The zone of the owner of the ANAME: the ANAME sibling address records are inserted into the

Re: [DNSOP] Minimum viable ANAME

2018-09-27 Thread Havard Eidnes
>> If I look up foo and it has an ANAME to bar, which of these do I get >> back? > > ; ANSWER SECTION > foo. A 1.2.3.4 Who provides the DNSSEC proof for this record? AIUI, there is no A 1.2.3.4 in the "foo." zone originally, but there is an ANAME. How, then, does this avoid

Re: [DNSOP] Minimum viable ANAME

2018-09-23 Thread Ray Bellis
On 21/09/2018 19:11, JW wrote: > I also feel from this discussion, we are all roughly on the same page.  > We want SRV as the long term solution ... except that we heard at the side meeting in Montreal (albeit from browser people rather than content people) that they *don't* want SRV, because it

Re: [DNSOP] Minimum viable ANAME

2018-09-21 Thread JW
Original message From: 神明達哉 > In my understanding of the discussion we all agree that it will take a> very > long time until we have B.  So, in the end, the deployability > seems to depend on how soon we can have situation A and how convenient> the > implementations are.  It

Re: [DNSOP] Minimum viable ANAME

2018-09-21 Thread 神明達哉
At Fri, 21 Sep 2018 12:03:13 +0100, Tony Finch wrote: > > Perhaps primary server implementations may eventually have some level > > of support that makes this provisioning much less painful (in a way > > other than performing on-demand resolution). If and when many popular > > implementations

Re: [DNSOP] Minimum viable ANAME

2018-09-21 Thread Matthew Pounsett
On 21 September 2018 at 09:12, Dan York wrote: > > 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. > I would still like to see something SRV-like for HTTP, but

Re: [DNSOP] Minimum viable ANAME

2018-09-21 Thread 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

Re: [DNSOP] Minimum viable ANAME

2018-09-21 Thread Tony Finch
神明達哉 wrote: > > I'm not sure how we can expect this model to deploy in practice. With > this model, the zone admin will need to develop an additional script > or something integrated into whatever the provisioning framework they > are using. Is that the assumption? I would like it to be

Re: [DNSOP] Minimum viable ANAME

2018-09-20 Thread 神明達哉
At Wed, 19 Sep 2018 14:55:45 +0100, Tony Finch wrote: > I think there's still a need to standardize ANAME, to provide at least > some level of zone file portability between the various existing > proprietary versions of this feature. And to provide something usable > by zone publisters on a much

Re: [DNSOP] Minimum viable ANAME

2018-09-20 Thread Tony Finch
Paul Wouters wrote: > > > With this model, signing only happens where it currently happens. > > Good. Although if you want to return bar's IP if it is different from > foo's IP and for resolvers that don't understand ANAME, you have to > synthesize these, but at least then it is nor worse then

Re: [DNSOP] Minimum viable ANAME

2018-09-20 Thread Tony Finch
> On 20 Sep 2018, at 07:13, Mukund Sivaraman wrote: > > I don't follow how ANAME, if resolvers have to implement it, can be > deployed within a few years, Resolvers don’t “have to” implement it: resolver support is just an optimisation that helps when the target is on a CDN. ANAME is mostly

Re: [DNSOP] Minimum viable ANAME

2018-09-20 Thread Mukund Sivaraman
Hi Tony On Wed, Sep 19, 2018 at 10:08:45PM +0100, Tony Finch wrote: > * minimal ANAME can be deployed unilaterally on the provisioning side > * 20 years ago and similar features are widely available (you are > * ahead of me on this one, John!); if resolvers implement it there > * will be useful

Re: [DNSOP] Minimum viable ANAME

2018-09-19 Thread Paul Wouters
On Wed, 19 Sep 2018, Tony Finch wrote: If I look up foo and it has an ANAME to bar, which of these do I get back? ; ANSWER SECTION foo. A 1.2.3.4 ; ADDITIONAL SECTION foo. ANAME bar. bar. A 1.2.3.4 The model is that this is a replacement for manually copying address records, with added

Re: [DNSOP] Minimum viable ANAME

2018-09-19 Thread Tony Finch
> On 19 Sep 2018, at 21:14, John Levine wrote: > If I look up foo and it has an ANAME to bar, which of these do I get > back? ; ANSWER SECTION foo. A 1.2.3.4 ; ADDITIONAL SECTION foo. ANAME bar. bar. A 1.2.3.4 The model is that this is a replacement for manually copying address records,

Re: [DNSOP] Minimum viable ANAME

2018-09-19 Thread John Levine
In article you write: >Authoritative servers / zone transfers >-- > >No special new behaviour. > > >Additional section processing >- > >This applies to auth and rec servers. In response to an A / / >ANAME query, include any

Re: [DNSOP] Minimum viable ANAME

2018-09-19 Thread Tony Finch
Paul Wouters wrote: > > The design goals of a solution in this space should be: > > - Fully supports DNSSEC > - Does not require AUTH server changes other then supporting a new > RRTYPE presentation / wire format and/or serving a new RRTYPE as > Additional Data. > - All optimization work is

Re: [DNSOP] Minimum viable ANAME

2018-09-19 Thread Paul Wouters
On Wed, 19 Sep 2018, Paul Vixie wrote: Tony Finch wrote: Anthony Eden wrote: FWIW, there's still always https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/ I get the impression that a lot of the objection to the current ANAME draft is that it specifies that auth servers

Re: [DNSOP] Minimum viable ANAME

2018-09-19 Thread Paul Vixie
Tony Finch wrote: Anthony Eden wrote: FWIW, there's still always https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/ I get the impression that a lot of the objection to the current ANAME draft is that it specifies that auth servers do ANAME target lookups and record

Re: [DNSOP] Minimum viable ANAME

2018-09-19 Thread Tony Finch
Anthony Eden wrote: > FWIW, there's still always > https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/ I get the impression that a lot of the objection to the current ANAME draft is that it specifies that auth servers do ANAME target lookups and record substitution; your draft says

Re: [DNSOP] Minimum viable ANAME

2018-09-19 Thread Anthony Eden
FWIW, there's still always https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/ (also available at https://github.com/aeden/alias-rr-type) which can be revived if there is interest. Sincerely, Anthony Eden On Wed, Sep 19, 2018 at 9:56 AM Tony Finch wrote: > I think there's still a