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
>expande
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
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 r
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 w
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 ve
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 to
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 delega
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 D
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
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 Croc
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 w
Nit:
Section 1.5:
"For "TXT" records, there is no consistent, internal syntax that to permits
distinguishing among the different uses."
Spurious 'that' or 'to'.
I'm also somewhat confused by the quoting in:
"In the case of the "SRV" "RR" and "URI" "RR", distinguishing among
different types" (and
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
mentione
> 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 should
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 around
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 s
On 04/11/2018 08:05, Ray Bellis wrote:
AFAIK, BIND does not currently do this. That said, MarkA has a patch
that supports it, so we do know it's possible.
Correction - BIND *does* do this, but only for address records that are
already in the cache. If the for the target is in the ca
17 matches
Mail list logo
