t;
>>
>>
>> Regards
>>
>>
>>
>> * I realise that I could have added . My presumption is that the top
>> 10k websites are not v6 only and at least have an A record in place.
>>
>>
>>
>> *From: *DNSOP on behalf of Olli Va
Follow-up.
tldr:
- The first argument is just an issue of wording.
- Authoritative servers or provisioning scripts that do ANAME processing
should honor the target address records TTL.
- Sibling address records should be used as a default if ANAME
processing fails.
On 11/9/18 6:54 PM,
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
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
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
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
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 stretching, and ultimately seem to
stem from a
On 6 Nov 2018, at 22:30, Ray Bellis wrote:
> You can have wildcard support, or you can have prefixes (hence
> delegation), but you can't have both.
Thats exactly my point. URI solves "the other problem".
Patrik
signature.asc
Description: OpenPGP digital signature
Ray Bellis wrote:
> On 06/11/2018 20:44, Tony Finch wrote:
>
> > If you are using an _prefix without any meaning of its own but only to
> > move a record away from the apex (so that it can be delegated or CNAMEd)
> > and also using a specific RR type or an RDATA prefix, then wildcards do
> > not
On 06/11/2018 20:51, Joe Abley wrote:
Ray has wider aspirations than just the apex. This may well be
sensible, but I think it's worth calling out the scope creep.
It's in the intro text:
"This document specifies an "HTTP" resource record type for the DNS to
facilitate the lookup of the
On 06/11/2018 20:44, Tony Finch wrote:
My understanding is that wildcards don't work for SRV because the
_prefixes are used to disambiguate which service you are asking for,
effectively to extend the RR TYPE number space. So if you wildcard a SRV
record then the target port has to support
On 06/11/2018 20:58, Patrik Fältström wrote:
We should also remember that there is a different goal as well, and
that is to be able to delegate the zone within which "the records
dealing with web" is managed so that the administrative
responsibility is separated between the one which run the
Olli,
> On Nov 6, 2018, at 3:23 PM, Olli Vanhoja wrote:
>
> In fact if you look at the DNS records some big Internet companies
> they rarely use CNAMEs for www but instead you'll see an A record, that might
> be even backed by a proprietary ANAME solution.
One detail about this is that if the
On 6 Nov 2018, at 17:51, Joe Abley wrote:
>> On Nov 6, 2018, at 20:44, Tony Finch wrote:
>>
>> Joe Abley wrote:
>>>
>>> Specifically, I s the wildcard owner name a real problem in the grand
>>> scheme of things?
>>
>> My understanding is that wildcards don't work for SRV because the
>>
Hi Tony.
> On Nov 6, 2018, at 20:44, Tony Finch wrote:
>
> Joe Abley wrote:
>>
>> Specifically, I s the wildcard owner name a real problem in the grand
>> scheme of things?
>
> My understanding is that wildcards don't work for SRV because the
> _prefixes are used to disambiguate which service
Joe Abley wrote:
>
> Specifically, I s the wildcard owner name a real problem in the grand
> scheme of things?
My understanding is that wildcards don't work for SRV because the
_prefixes are used to disambiguate which service you are asking for,
effectively to extend the RR TYPE number space. So
Date: Tuesday, 6 November 2018 at 08:24
To:
Subject: Re: [DNSOP] Fundamental ANAME problems
In fact if you look at the DNS records some big Internet companies
they rarely use CNAMEs for www but instead you'll see an A record, that might
be even backed by a proprietary ANAME solution
> > The semantics is exactly like a CNAME + HTTP Redirect.
>
> The latter part is what I expected, and why I think it's a non-starter.
>
> HTTP Redirects cause the URI in the address bar to be changed. A lot of
> the whole "CNAME at the Apex" issue arises because lots of marketing
> people don't
On 06/11/2018 04:07, Joe Abley wrote:
Specifically, I s the wildcard owner name a real problem in the grand
scheme of things? I understand that wildcards are used by some people
for names that feature in HTTP URIs, but I'm struggling to imagine
using a wildcard at a zone cut; [...]
You're
Hi Ray,
> On Nov 5, 2018, at 22:38, Ray Bellis wrote:
>
> There *is* a big failing of SRV that's independent of the CNAME apex use
> case, and that is its lack of support for wildcards. Since my proposal
> doesn't use underscore prefix labels, wildcards will work, and this is an
> important
On 3 Nov 2018, at 23:32, Måns Nilsson wrote:
> _http._tcp.example.org. IN URI10 20
> "https://example-lb-frontend.hosting.namn.se:8090/path/down/in/filestructure/;
Btw, this is sort of what I am thinking of for URI, cooked up directly after
dinner. Could be a wrapper around curl that
You can measure when to stop publishing A/ records with HTTP by pointing
the HTTP record at a different address. Clients that are HTTP record aware
will use one address and legacy clients will use the other address.
Mark
--
Mark Andrews
> On 6 Nov 2018, at 05:16, Tony Finch wrote:
>
>
Joe Abley wrote:
> On Nov 5, 2018, at 15:35, Måns Nilsson wrote:
>
> >> I think a resolver-side or client-side alternative (like the various
> >> web-specific record types we have been discussing) is defintely soemthing
> >> we should aim for in the long term, but that isn't what this work is
>
People don’t want CNAME at the apex. They want a pointer to a server for a
service at the apex.
CNAME provided a pointer to a server when the prefix was www.
This can be done a number of ways.
1) Prefix + name in rdata.
2) Service specific type + name in rdata.
3) Generic type + service and
Ray Bellis wrote:
On 06/11/2018 00:36, Paul Vixie wrote:
second reply, on a more general topic:
the "HTTP URI" ...
The additional data is not mandatory.
then, according to marka, the web people won't use it.
--
P Vixie
___
DNSOP mailing
On 06/11/2018 00:32, Paul Vixie wrote:
please don't think this way, and don't do the right thing for the wrong
reasons. the paragraph above is how the camel came to be -- one draft at
a time, all well-meaning.
The front running alternative (ANAME) shifts the entire and far more
considerable
second reply, on a more general topic:
the "HTTP URI" will require a change to bert's teaching resolver (tres),
which correctly handles unrecognized code points and thus would need no
changes at all if the additional data weren't mandatory. i think in
modern terminology, if your proposed
there were several pro-HTTP-URI comments in this thread; i picked the
one with the most technical meat. brian, jim, paul: thank you for your
comments.
Ray Bellis wrote:
On 05/11/2018 18:55, Joe Abley wrote:
2. Find a client-side solution to this, and try really hard not to
invent something
> On 5 Nov 2018, at 15:38, Ray Bellis wrote:
>
> The cost to the DNS community of *trying* my proposed HTTP record is pretty
> negligible. Worst case, as Brian put it, is we burn a code point, add a
> trivial amount of code to DNS servers, but the browsers don't adopt it. It
> wouldn't
mansaxel> IMNSHO _any_ work on "fixing CNAMES at apex" that gets
mansaxel> traction is a spanner in the works for what we seem to agree
mansaxel> is a better solution. A interim fix will be deployed and stall
mansaxel> every attempt at DTRT.
While I agree with this approach in principle, the
On 05/11/2018 18:55, Joe Abley wrote:
2. Find a client-side solution to this, and try really hard not to
invent something new that is really just SRV with a hat and a false
moustache.
There *is* a big failing of SRV that's independent of the CNAME apex use
case, and that is its lack of
the transition phase.
Manu
On Mon, Nov 5, 2018 at 3:35 PM Måns Nilsson
wrote:
> Subject: Re: [DNSOP] Fundamental ANAME problems Date: Fri, Nov 02, 2018 at
> 04:39:09PM + Quoting Tony Finch (d...@dotat.at):
> > It's really good to see more discussion about ANAME.
>
> I agree.
>
&
On Nov 5, 2018, at 15:35, Måns Nilsson wrote:
>> I think a resolver-side or client-side alternative (like the various
>> web-specific record types we have been discussing) is defintely soemthing
>> we should aim for in the long term, but that isn't what this work is
>> about.
>
> IMNSHO _any_
Subject: Re: [DNSOP] Fundamental ANAME problems Date: Fri, Nov 02, 2018 at
04:39:09PM + Quoting Tony Finch (d...@dotat.at):
> It's really good to see more discussion about ANAME.
I agree.
> I think a resolver-side or client-side alternative (like the various
> web-specific record
On 04/11/2018 23:02, Paul Ebersman wrote:
Have you confirmed with the large CDNs doing geo-ip, load-balancing, etc
that this is what they want, since they are largely driving all of this?
I'd guess that they would prefer this in the auth layer, where they own
or have contractual
ray> Architecturally, the important part of my proposal is that
ray> resolution of the A and records is done *at the recursive
ray> layer* of the DNS, with no interference with how authoritative
ray> resolution works.
Have you confirmed with the large CDNs doing geo-ip, load-balancing, etc
ray> HTTP Redirects cause the URI in the address bar to be changed. A
ray> lot of the whole "CNAME at the Apex" issue arises because lots of
ray> marketing people don't want end users to have to type *or see* the
ray> www prefix.
ray> Those folks aren't going to stand for their nice clean
ray>
On 04/11/2018 18:16, Brian Dickson wrote:
Is the apex thing an optimization only (i.e. is it acceptable that
the mechanism for apex detection not be 100% effective)? I think
that's the input needed before it makes sense to go down any
particular branch of design work, by either the http folks
On 04/11/2018 18:31, Patrik Fältström wrote:
The semantics is exactly like a CNAME + HTTP Redirect.
The latter part is what I expected, and why I think it's a non-starter.
HTTP Redirects cause the URI in the address bar to be changed. A lot of
the whole "CNAME at the Apex" issue arises
On 4 Nov 2018, at 11:10, Ray Bellis wrote:
> -1
:-)
> What are the semantics of this?
The semantics is exactly like a CNAME + HTTP Redirect.
Provisioning is like any provisioning in the DNS, with the advantage that you
can delegate the prefix:ed domain just like you can do with any _tcp and
Ray Bellis wrote:
>
> I don't think that either SRV or URI are usable for the primary use
> case, i.e. allowing a domain owner to put a record at the apex of
> their zone that points at the hostname of the web provider they want to
> use.
>
>
Is the apex thing an optimization only (i.e. is it
Ray Bellis wrote:
> ... "URI RR" ...
I see absolutely zero chance of the web community embracing this.
as evidenced by RFC 8484, the web community seems to regret basing their
work on the Internet System, and is now moving independently. this may
mean that offering them something like
On 04/11/2018 15:05, Paul Vixie wrote:
as evidenced by RFC 8484, the web community seems to regret basing
their work on the Internet System, and is now moving independently.
this may mean that offering them something like "HTTP RR" which can't
work better than SRV or URI already works,
On 04/11/2018 12:53, Patrik Fältström wrote:
On 3 Nov 2018, at 23:32, Måns Nilsson wrote:
_http._tcp.example.org. IN URI 10 20
"https://example-lb-frontend.hosting.namn.se:8090/path/down/in/filestructure/;
We already have this. We need not build a new mechanism.
+1
-1
What are the
On 3 Nov 2018, at 23:32, Måns Nilsson wrote:
> _http._tcp.example.org. IN URI10 20
> "https://example-lb-frontend.hosting.namn.se:8090/path/down/in/filestructure/;
>
> We already have this. We need not build a new mechanism.
+1
Patrik
signature.asc
Description: OpenPGP digital
Subject: Re: [DNSOP] Fundamental ANAME problems Date: Sat, Nov 03, 2018 at
12:04:18PM -0700 Quoting Joe Abley (jab...@hopcount.ca):
> On Nov 3, 2018, at 03:20, Bob Harold wrote:
>
> > My preference would be a *NAME record that specifies which record types it
> > applies
On Nov 3, 2018, at 03:20, Bob Harold wrote:
> My preference would be a *NAME record that specifies which record types it
> applies to. So one could delegate A and at apex to a web provider, MX
> to a mail provider, etc. That would also be valuable at non-apex names. But
> I am happy
Brian Dickson 于2018年11月2日周五 上午9:38写道：
> On Thu, Nov 1, 2018 at 5:14 PM John Levine wrote:
>
>> I can't help but note that people all over the Internet do various
>> flavors of ANAME now, and the DNS hasn't fallen over. Let us not make
>> the same mistake we did with NAT, and pretend that since
Subject: Re: [DNSOP] Fundamental ANAME problems Date: Fri, Nov 02, 2018 at
04:03:50PM +0800 Quoting John R Levine (jo...@taugh.com):
I'll defer to other people, but it seems to me that anything that depends on
recursive DNS servers being updated isn't a realistic solution. We're still
waiting
On Nov 3, 2018, at 12:28 AM, Måns Nilsson wrote:
>> I'll defer to other people, but it seems to me that anything that depends on
>> recursive DNS servers being updated isn't a realistic solution. We're still
>> waiting for DNSSEC, after all.
>
> Be as pessimistic as you like, but in Sweden,
for the love of god, please, do not add more complexity, logic,
computation, or network fetching to recursive name servers. if it's your
belief that a static solution can't work, push for SRV.
___
DNSOP mailing list
DNSOP@ietf.org
I haven't reviewed the full draft yet, but am happy to see some people
echoing my sentiments from earlier versions [1]. I particularly wanted
to agree with some statements from Bob Harold.
On 11/2/18 15:20, Bob Harold wrote:
Another option to give users is a non-updating fallback A record,
My thoughts at the bottom...
On Thu, Nov 1, 2018 at 6:34 PM Brian Dickson
wrote:
> Greetings, DNSOP folks.
>
> First, a disclaimer and perspective statement:
> These opinions are mine alone, and do not represent any official position
> of my employer.
> However, I will note that it is important
On Thu, Nov 1, 2018 at 6:34 PM Brian Dickson
wrote:
> ...
>
> Third, there is an issue with the impact to anycast operation of zones
> with ANAMEs, with respect to differentiated answers, based on topological
> locations of anycast instances.
>
> There is currently an expectation on resolving a
Subject: Re: [DNSOP] Fundamental ANAME problems Date: Fri, Nov 02, 2018 at
04:03:50PM +0800 Quoting John R Levine (jo...@taugh.com):
> I'll defer to other people, but it seems to me that anything that depends on
> recursive DNS servers being updated isn't a realistic solution. We're
It's really good to see more discussion about ANAME.
The current draft doesn't discuss scaling issues because my main concern
was to get the rewrite done, so there are a number of gaps, e.g. I deleted
the "operational considerations" section. But that doesn't mean I was
unaware of the problem :-)
Hi Brian,
Thanks for your feedback on ANAME. Comments inline.
On 01-11-18 23:34, Brian Dickson wrote:
Greetings, DNSOP folks.
[...]
First, there is the issue of imposed update frequency.
The requirement on update rate, is imposed externally by whichever
entity operates the ANAME target.
i think an ANAME whose only purpose was to inform some outer process that
and A RRsets should be copied from somewhere periodically using RFC 2136
UPDATE messages, could be useful if some name server implementors decided to
offer the feature of doing this internally, "as if UPDATE had been
Did you not read my full message?
I didn't say don't do that, I said let's do it in an elegant way.
Then I provided a few examples of how to do that.
I'll defer to other people, but it seems to me that anything that depends
on recursive DNS servers being updated isn't a realistic solution.
On Thu, Nov 1, 2018 at 5:14 PM John Levine wrote:
> I can't help but note that people all over the Internet do various
> flavors of ANAME now, and the DNS hasn't fallen over. Let us not make
> the same mistake we did with NAT, and pretend that since we can't find
> an elegant way to do it, we
I can't help but note that people all over the Internet do various
flavors of ANAME now, and the DNS hasn't fallen over. Let us not make
the same mistake we did with NAT, and pretend that since we can't find
an elegant way to do it, we can put our fingers in our ears and it
will go away.
In
61 matches
Mail list logo
