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 on
On Fri, Nov 9, 2018 at 11:39 AM 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 p
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 com
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 to query for something
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
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 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 stretchin
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
10 matches
Mail list logo
