Paul Hoffman writes:
> From the earlier list discussion and your presentation at DNS-OARC,
> processing dynamic zones is hard, and you might make different choices
> based on different amounts of dynamicness (dynamicity?). This should
> cause developers concern about implementing ZONEMD now
On Sat, Nov 03, 2018 at 03:12:28PM +0700, Mukund Sivaraman wrote:
> The D flag seems unnecessary. Just the presence of the EDNS option in
> query from the client should serve to indicate to a server that the
> client explicitly does not want stale answers.
I withdraw this comment. It appears that
I've reviewed older revisions of the draft and still +1 the idea. It
would be useful practically in today's world where temporary DDoS
attacks inundate authorities.
Review comments on this revision of the draft:
>This document proposes that the definition of the TTL be explicitly
>
Joe Abley writes:
> I think the wider problem space might be better described as trust
> anchor publication and retrieval.
Couldn't have said it better myself (more specifically, I didn't). The
problem space is much bigger than 5011, and 5011 is but one tool to
solve a piece of the whole
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
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
Review comments follow:
> Decreasing Access Time to Root Servers by Running One On The Same Server
> draft-ietf-dnsop-7706bis-01
> Abstract
>Some DNS recursive resolvers have longer-than-desired round-trip
>times to the closest DNS root server. Some DNS recursive
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
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
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : DNS Scoped Data Through "Underscore" Naming of
Attribute Leaves
Author : Dave Crocker
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
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : DNS Attrleaf Changes: Fixing Specifications with
Underscored Node Name Use
Author : Dave
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 to. So one could
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
> On Nov 3, 2018, at 1:33 PM, Wes Hardaker wrote:
>
> Paul Hoffman writes:
>
>> From the earlier list discussion and your presentation at DNS-OARC,
>> processing dynamic zones is hard, and you might make different choices
>> based on different amounts of dynamicness (dynamicity?). This
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
I'm also somewhat confused by the quoting in:
"In the case of the "SRV" "RR" and "URI" "RR", distinguishing among
different types" (and in "defining "RR"s that might" ) - I'm not sure if
it is intentional, but it doesn't align with much of the rest of the
formatting, and is (IMO) confusing
17 matches
Mail list logo
