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
> 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
> 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 think
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 if
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 CNAM
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 proces
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 bein
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 p
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
> inc
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. My
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
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 qu
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
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
https://mailarchive.ietf.org/arch/msg/dnsop/lC2ZW0lwME-RrvkpntR
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 resolve
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 wo
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
ANAME-like
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.
Mat
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
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.
>
> __
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
> 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 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, 2018
> 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
> 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 mentio
> 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
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 vendo
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
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
wi
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 endpoin
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 poi
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
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).
B
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
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
> > col
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 deploy
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 ma
> 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 used,
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 onl
> 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 this,
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
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 ca
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
mentione
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 w
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 D
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 ve
>> > 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 (
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
___
DNS
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 27,
>> 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 not
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 zon
>> 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 DNSSEC-signing-on-the-
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
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 ma
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 do
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
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
神明達哉 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 integra
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
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 DNS
> 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
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 am
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 hint
> 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,
with
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 sibli
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 do
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 d
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 substitut
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
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
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 shorter timescale than a nsa SRV-alike.
So here's a sketch of a
71 matches
Mail list logo
