The following errata report has been submitted for RFC7719,
"DNS Terminology".
--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5542
--
Type: Technical
Reported by: Scott Corcoran
Section: 1
On Fri, Nov 02, 2018 at 02:30:15PM -0400, Viktor Dukhovni wrote:
> [ Was: Fundamental ANAME problems
> Dropped In-Reply-To:, to ensure a new thread. ]
>
> On Fri, Nov 02, 2018 at 06:28:52PM +0100, Måns Nilsson wrote:
>
> > > I'll defer to other people, but it seems to me that anything that
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,
> On Nov 2, 2018, at 17:57, Dan York wrote:
>
> Are there any other publishers of websites on this list who use CDNs in front
> of their sites - and who are interested in the whole “CNAME at apex” issue?
>
> Given the ANAME discussions and other continuing “CNAME at apex” discussions,
> I
On Fri, Nov 02, 2018 at 10:16:25PM +0100, Måns Nilsson wrote:
> At the risk of sounding like a repetitive bore, what is actually needed
> is a way to say "for that domain name, apex or not, https[1] services are
> over there >". Without messing up the entire node in the tree and
> causing
Subject: Re: [DNSOP] Any website publishers who use CDNs on the list? Date:
Fri, Nov 02, 2018 at 01:11:08PM +0100 Quoting Måns Nilsson
(mansa...@besserwisser.org):
> Subject: [DNSOP] Any website publishers who use CDNs on the list? Date: Fri,
> Nov 02, 2018 at 10:57:33AM + Quoting Dan York
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
[ Was: Fundamental ANAME problems
Dropped In-Reply-To:, to ensure a new thread. ]
On Fri, Nov 02, 2018 at 06:28:52PM +0100, 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.
On Fri, Nov 2, 2018 at 1:38 PM Dan York wrote:
> During the time leading up to the Root KSK Rollover on October 11, I had
> multiple people from outside of DNS circles asking me why DNS was so hard
> to upgrade. Basically - why was this Root KSK Rollover such a big concern?
>
> I recalled the
During the time leading up to the Root KSK Rollover on October 11, I had
multiple people from outside of DNS circles asking me why DNS was so hard to
upgrade. Basically - why was this Root KSK Rollover such a big concern?
I recalled the draft a few of us wrote a bit ago with observations on the
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
>
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 :-)
Subject: [DNSOP] Any website publishers who use CDNs on the list? Date: Fri,
Nov 02, 2018 at 10:57:33AM + Quoting Dan York (y...@isoc.org):
> DNSOP subscribers,
>
> Are there any other publishers of websites on this list who use CDNs in front
> of their sites - and who are interested in the
DNSOP subscribers,
Are there any other publishers of websites on this list who use CDNs in front
of their sites - and who are interested in the whole “CNAME at apex” issue?
Given the ANAME discussions and other continuing “CNAME at apex” discussions, I
started putting together a short draft
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.
21 matches
Mail list logo
