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
__
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 t
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 A/AAA
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 des
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 restric
On Fri, Nov 9, 2018 at 12:09 PM Paul Vixie wrote:
> Brian Dickson wrote:
> > Paul Vixie wrote:
>
i don't love the dnssec implications of this, including proof of
> nonwildcard.
>
I'm not 100% sure, but I think the generic DNSSEC response handling already
covers this.
If the response does not inc
Brian Dickson wrote:
Paul Vixie wrote:
...
i regret not adding ANY as an RR type (not just a Q type) back when
the DNS was small and i supported 90% of it. what we actually needed
is a wildcard on types so that if there's no more-specific type you
get thatone, which would
Paul Vixie wrote:
> 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
On 09/11/2018 09:30, Paul Vixie wrote:
i regret not adding ANY as an RR type (not just a Q type) back when
the DNS was small and i supported 90% of it. what we actually needed
is a wildcard on types so that if there's no more-specific type you
get that one, which would have an rdata of the
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 restrictions on CNAMEs.
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 restrictions on CNAMEs.
I concede that ANAME pe
> On 8 Nov 2018, at 20:13, Mark Andrews wrote:
>
>> On 9 Nov 2018, at 5:27 am, Tony Finch wrote:
>>
>> HTTP RRs risk adding a third option, where the web provider has to have
>> documentation asking whether the DNS provider supports HTTP RRs and if so
>> the site admin needs both these address
> On 9 Nov 2018, at 5:27 am, Tony Finch wrote:
>
> Ray Bellis wrote:
>> On 08/11/2018 11:47, Dan York wrote:
>>
>>> For that reason, wouldn't all the resolvers (or at least an extremely high
>>> %) need to be upgraded to support the new record?
>>
>> They don't _have_ to be, but performance
Ray Bellis wrote:
> On 08/11/2018 11:47, Dan York wrote:
>
> > For that reason, wouldn't all the resolvers (or at least an extremely high
> > %) need to be upgraded to support the new record?
>
> They don't _have_ to be, but performance is improved when they are (since only
> an upgraded resolver
Subject: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME Date:
Thu, Nov 08, 2018 at 09:30:44AM +0700 Quoting Brian Dickson
(brian.peter.dick...@gmail.com):
> I'm going to start a clean, related thread, to discuss a bunch of
> questions, that I think can
> On 8 Nov 2018, at 2:30 pm, Brian Dickson
> wrote:
>
>
>
> On Thu, Nov 8, 2018 at 10:06 AM Dan York wrote:
> Brian,
>
> DY> Upgrading our DNS infrastructure is VERY difficult. Because it is still
> massively distributed and decentralized (even though we do have ongoing
> centralization/
On Thu, Nov 8, 2018 at 11:47 AM Dan York wrote:
> Brian,
>
> > On Nov 8, 2018, at 10:30 AM, Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
> >
> > For new RRtypes, registries, registrars, and their provisioning services
> do NOT need to support them; the new types are in the zones only.
On 08/11/2018 11:47, Dan York wrote:
For that reason, wouldn't all the resolvers (or at least an extremely high %)
need to be upgraded to support the new record?
They don't _have_ to be, but performance is improved when they are
(since only an upgraded resolver will include the A and
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 enti
On Thu, Nov 8, 2018 at 10:06 AM Dan York wrote:
> Brian,
>
> DY> Upgrading our DNS infrastructure is VERY difficult. Because it is
> still massively distributed and decentralized (even though we do have
> ongoing centralization/consolidation), getting a new RRTYPE deployed means:
>
> - upgrading
Brian,
> On Nov 8, 2018, at 9:30 AM, Brian Dickson
> wrote:
>
> I'm going to start a clean, related thread, to discuss a bunch of questions,
> that I think can help with the ongoing threads.
DY> Thank you for doing so.
> What we may be forgetting are the USERS of these systems, and the use c
If additional data is optional, so most resolvers can just pass it through, the
DNS techs will say yes but the HTTP techs will say no.
- Original Message -
From: Brian Dickson
Sent: 2018-11-07 - 18:30
To: "dnsop@ietf.org WG"
Subject: [DNSOP] Root reasons (aka "why&quo
I'm going to start a clean, related thread, to discuss a bunch of
questions, that I think can help with the ongoing threads.
Rationale:
I think many of the viewpoints some folks have are skewed by pre-existing
familiarity with the protocol, and implementations (including browsers,
libraries, stubs
23 matches
Mail list logo
