On Mon, Jun 15, 2020 at 5:59 PM Tony Finch wrote:
> Brian Dickson wrote:
>
> > Internal-only use is not only satisfied with non-delegated name spaces,
> it
> > actually is a much better fit for everything.
>
> Yes, I agree, but why does the point of non-delegat
On Mon, Jun 15, 2020 at 3:00 PM Tony Finch wrote:
> Paul Vixie wrote:
> > On Monday, 15 June 2020 17:58:42 UTC Tim Wicinski wrote:
> > >
> > > or since domains are cheap, why not buy a new domain, and use that for
> the
> > > namespace?
> >
> > that makes internet viral, and private
On Mon, Jun 15, 2020 at 10:47 AM John Levine wrote:
> In article <
> cah1iciouffmryorewhhtbqfnnserw3rvups8pzc8cvnehys...@mail.gmail.com> you
> write:
> >E.g. use an FQDN belonging to you (or your company), so the namespace
> would
> >be example.com.zz under which your private names are
On Mon, Jun 15, 2020 at 8:34 AM Tony Finch wrote:
> Tim Wicinski writes:
>
> > This starts a Call for Adoption for draft-arends-private-use-tld
>
> I think this is cute / clever, but a very bad idea.
>
> Experience from IPv4 and IPv6 private use areas shows that there will be
> collisions and
On Fri, Jun 12, 2020 at 8:12 AM Tim Wicinski wrote:
>
> All,
>
> As we stated in the meeting and in our chairs actions, we're going to run
> regular calls for adoptions over the next few months. We are looking for
> *explicit* support for adoption.
>
>
> This starts a Call for Adoption for
On Wed, Jun 3, 2020 at 2:07 PM Tim Wicinski wrote:
>
> All,
>
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.
> We are looking for *explicit* support for adoption.
>
>
I support adoption, and am willing to review.
On Sun, May 24, 2020 at 2:51 AM Tim Wicinski wrote:
>
> All,
>
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months. We are looking for
> *explicit* support for adoption.
>
>
> This starts a Call for Adoption for
On Mon, May 18, 2020 at 10:50 AM Tim Wicinski wrote:
>
> All,
>
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.
> We are looking for *explicit* support for adoption.
>
>
> This starts a Call for Adoption for
>
On Mon, May 11, 2020 at 10:42 AM Tim Wicinski wrote:
>
> All,
>
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.
> We are looking for *explicit* support for adoption.
>
>
I support adoption of this as a WG draft. I
On Mon, May 4, 2020 at 12:10 PM Tim Wicinski wrote:
>
>
> All,
>
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.
> We are looking for *explicit* support for adoption.
>
>
> This starts a Call for Adoption for
>
On Fri, Apr 24, 2020 at 11:56 PM Paul Vixie wrote:
> mind if i cut in?
>
> On Saturday, 25 April 2020 06:23:54 UTC Vladimír Čunát wrote:
> > Original subject: New draft on delegation revalidation
> >
> > On 4/24/20 4:49 PM, Shumon Huque wrote:
> > > ...
> >
> > ...
>
> (agreeableness.)
>
> >
On Mon, Apr 27, 2020 at 3:28 PM Wes Hardaker wrote:
> Joe Abley writes:
>
> > This draft needs a more compelling problem statement, and a clear
> > description of why other controls (e.g. reputational, contractual) are
> > insufficient. [It's also possible that the draft just needs a clearer
>
On Mon, Apr 27, 2020 at 11:29 AM Tim Wicinski wrote:
>
> All,
>
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.
> We are looking for *explicit* support for adoption.
>
>
I support adoption of this as a WG item. I am
On Tue, Apr 14, 2020 at 8:48 AM Tim Wicinski wrote:
>
> This starts a Call for Adoption for
> draft-fujiwara-dnsop-avoid-fragmentation
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-avoid-fragmentation/
>
On Tue, Apr 14, 2020 at 8:44 AM Paul Vixie wrote:
> today it was proposed that NS2 be added as a new record-set type that
> could exist in either the parent or the child, similar to NS, and
> reminding several of us about the DS debacle.
>
>
Would the authors of that draft please post into this
On Fri, Apr 10, 2020 at 6:46 AM Shumon Huque wrote:
> Hi folks,
>
> Paul Vixie, Ralph Dolmans, and I have submitted this I-D for
> consideration:
>
>https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01
>
>
> Comments/discussion welcome.
>
There is one issue not addressed (here
On Wed, Apr 8, 2020 at 10:10 PM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:
>
> Section 6.1, 6.2
>
> Should we say anything about when it's safe for a new ZSK to be used to
> sign responses?
>
I think, technically speaking, it is always safe to use a new ZSK, and the
only concern
On Sat, Feb 22, 2020 at 4:01 PM Tony Finch wrote:
> Evan Hunt wrote:
> >
> > CNAME at the apex wasn't really the problem. Getting browsers to display
> > content from the right CDN server was the problem.
>
> My interest in ANAME is basically nothing to do with CDNs. I want my users
> to be
On Fri, Feb 21, 2020 at 11:05 AM Ben Schwartz wrote:
> I agree with Erik's characterization of the problem. Personally, I favor
> an _optional_, authoritative-only specification for ANAME, so that ANAME
> can be present in zone files if the server supports it, and it is processed
> 100% locally
On Wed, Jan 15, 2020 at 7:06 AM Paul Hoffman wrote:
> On Jan 15, 2020, at 12:14 AM, Shane Kerr
> wrote:
> >
> > Duane,
> >
> > On 13/01/2020 19.26, Wessels, Duane wrote:
> >>> On Jan 8, 2020, at 3:55 PM, Michael StJohns
> wrote:
> >>> There's also the case that future ZONEMD schemes may need a
On Wed, Jan 8, 2020 at 12:20 PM Paul Vixie wrote:
> [thread fork; subject changed]
>
> i've brought this up several times including in response to the very first
> draft version. i'd like to be sure it's been considered and rejected by
> the
> dns technical community, rather than merely
On Tue, Jan 7, 2020 at 6:18 PM Paul Hoffman wrote:
> On Jan 7, 2020, at 6:03 PM, Joe Abley wrote:
> > I don't object to the intended status (standards track). There are
> reports of multiple independent implementations included in the document,
> which seems pleasing and proper.
>
> Definitely
ion (all of which can already be handled by resolvers).
Brian
On Fri, Dec 27, 2019 at 12:05 PM Brian Dickson <
brian.peter.dick...@gmail.com> wrote:
>
>
> On Fri, Dec 27, 2019 at 9:55 AM Eric Orth wrote:
>
>>
>>
>> On Mon, Dec 23, 2019 at 3:57 PM Brian Dickson
o HTTPSSVC, and leave SVCB less defined, as what is
> reasonable behavior may be more varied in non-HTTPS cases.
>
> On Fri, Dec 27, 2019 at 12:54 PM Eric Orth wrote:
>
>>
>>
>> On Mon, Dec 23, 2019 at 3:57 PM Brian Dickson <
>> brian.peter.dick...@gmail
On Fri, Dec 27, 2019 at 9:55 AM Eric Orth wrote:
>
>
> On Mon, Dec 23, 2019 at 3:57 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>>> Being typically further away from results and with less caching,
>>> unlimited chain foll
On Mon, Dec 23, 2019 at 12:22 PM Eric Orth wrote:
> Maybe it would help if we scoped down any chain limiting:
>
> 1) Any chain limiting only applies to SVCB alias form, not CNAME.
>
> CNAMEs already exist without a standardized limit. Good or bad, too late
> to change that without breaking
On Mon, Dec 9, 2019 at 10:03 AM Ben Schwartz wrote:
> Changed title to reflect this thread's topic.
>
>
> SVCB is fully "mixable" with CNAME, so there's no need to use SVCB's
> AliasForm when CNAME will do. CNAME chains are followed at every step
> of SVCB resolution. AliasForm's only
On Fri, Dec 6, 2019 at 2:45 PM Eric Orth wrote:
> Been reviewing the latest draft with a bunch of relevant experts within
> the Chrome team. As has been stated in previous emails and in WG sessions,
> we generally like the HTTPSSVC approach and are very interested in trying
> out an
On Thu, Nov 28, 2019 at 2:52 PM Doug Barton wrote:
> On 11/28/19 2:20 PM, Joe Abley wrote:
>
> > - has the advice to anchor a private namespace in a registered domain in
> > the private namespace really been received and judged to be
> > insufficient?
>
> Yes.
>
> > Or has it just not been
On Thu, Nov 28, 2019 at 2:52 PM Doug Barton wrote:
> On 11/28/19 2:20 PM, Joe Abley wrote:
>
> > - does the growth in observed query traffic for names with non-existant
> > top-level labels really support the idea that squatting on arbitrary
> > undelegated TLDs is on the rise? Is it possible
On Tue, Nov 26, 2019 at 9:40 AM Matthew Pounsett wrote:
>
>
> On Tue, 26 Nov 2019 at 12:35, Paul Hoffman wrote:
>
>> On Nov 26, 2019, at 9:16 AM, Matthew Pounsett wrote:
>> > I'm also persuaded by Bill's argument that the IETF has already stated
>> that ISO 3166 has control over that bit of
On Thu, Nov 21, 2019 at 3:57 PM Vladimír Čunát
wrote:
> On 11/21/19 8:26 AM, Paul Wouters wrote:
> > for example if ICANN delegates .zzz there will be interesting typo
> attacks possible in this weird private space
>
> In this respect .zz is at least better than .xx which was among the
>
On Tue, Nov 19, 2019 at 6:39 PM Tommy Pauly wrote:
> Hello DNSOP,
>
> In the interest of getting this spec ready to go, I want to start our
> bikeshed on the RRTYPE name. We need a stable name that we all can live
> with.
>
> I'll start. Please chime in!
>
> Since it seems that many people like
Per Benno’s request:
Positive feedback++;
Good document, fits real need, good to go.
Brian
Sent from my iPhone
> On Nov 16, 2019, at 10:43 AM, Benno Overeinder wrote:
>
> Hi all,
>
> The WGLC date has passed and we think the draft is in good shape. Still
> the chairs would like to see some
Top-reply to highlight a question:
I think there may be a different rationale for using some of the novel
ideas that Ben and Neil have raised, and am wondering if putting those in a
different draft makes sense?
I think so, and am very interested in working on those. The current draft
can be
+1 to everything Joe wrote below. (There should be an automatic +1 to
things Joe writes.)
I'd like to suggest an approach to the issues of DNS forwarders + NATs of
varying depth/scope, but I think there may be some extra protocol work in
order to address these problems.
Also, I think there would
As long as we avoid 53Cr.
(One of the isotopes of chromium happens to have atomic mass of 53 - funny
coincidence, what with chrome/chromium being google things.)
(Particularly if it is hexavalent.)
Brian
On Thu, Jul 25, 2019 at 1:34 PM Tommy Jensen wrote:
> The 53U, 53T, 53UT ordering makes
Small couple of comments in a top-reply...
I think the concept of having the root zone integrated into the RDNS is
something that Paul correctly indicates as something RDNS practices have
moved away from.
I happen to agree that doing so is a mistake, with particular reasoning:
- When integrated
Sorry for the late message, but I support both the intent and the draft.
One question:
Would it be feasible for recommending that full service resolvers check for
EDNS0 bufsize compliance, and treat violations as if they were TC=1?
E.g. Suppose I am a resolver, and send my query to an authority
On Tue, Jul 9, 2019 at 2:01 PM John Bambenek wrote:
> Below
>
> —
> John Bambenek
>
> On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0
> license which means commercial use will require a license. Contact
> sa...@bambenekconsulting.com for details
>
> On Jul 9, 2019, at 15:51,
Hi, Erik,
One minor issue is that wherever CNAME is referenced, you probably want to
also include a reference to DNAME, including any implied or explicit
chaining of CNAMEs (which could be sequences of CNAME and/or DNAME modulo
their respective behavior.)
It might be a little clearer if the list
On Mon, Jul 8, 2019 at 11:47 AM Witold Krecicki wrote:
> W dniu 08.07.2019 o 19:20, Wessels, Duane pisze:>> On Jul 8, 2019, at
> 9:20 AM, Joe Abley wrote:
> >>
> >>
> >> As far as this particular idea goes, I mentioned before what had given
> me pause: we're talking about taking a protocol
On Thu, Jun 13, 2019 at 1:51 PM Bob Harold wrote:
>
> On Thu, Jun 13, 2019 at 1:50 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Wed, Jun 12, 2019 at 1:11 AM Matthijs Mekking
>> wrote:
>>
>>> Brian,
>&
On Wed, Jun 12, 2019 at 1:11 AM Matthijs Mekking
wrote:
> Brian,
>
> Thanks for the detailed background on why DNAME worked. There are a few
> things that caught my attention:
>
> > When a recursive queried an authority server, if it got back a DNAME
> but did not understand it, it ignored the
On Tue, Jun 11, 2019 at 6:35 PM Joe Abley wrote:
> On Jun 11, 2019, at 20:04, Evan Hunt wrote:
>
> > MHO, the ANAME is the real answer we're sending; the A and records
> > are just friendly hand-holding for legacy servers. It doesn't make sense
> > to me to demote the real answer into the
On Mon, May 13, 2019 at 11:21 AM Wessels, Duane
wrote:
>
>
> > On May 13, 2019, at 10:17 AM, Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
> >
> > The original RFC 8145 gives the ability to gather trust anchor signal
> data.
> >
> > T
The original RFC 8145 gives the ability to gather trust anchor signal data.
There are limitations related to inferring either reasons for behavior
observed on the aggregate volumes, or identifying originating
resolvers/forwarders versus upstream resolvers/forwarders (which could
include both NAT
I know a lot of folks are spending a lot of time working on ANAME.
At the risk of offending those well-intentioned folks, the question I have
is a follows:
Have any "closed system" implementations of non-standard apex-CNAME hacks,
committed publicly to neutral ANAME operations, presuming ANAME
>
> Also note that this is explicitly only for resolvers; we might later do a
> second protocol for authoritative servers who want to give information
> about themselves (such as if they do DoT, if that moves forward in DPRIVE).
> The reason for the split is that a resolver that doesn't know the
On Tue, Mar 26, 2019 at 8:31 PM Olli Vanhoja wrote:
> On Tue, Mar 26, 2019 at 7:23 PM Brian Dickson
> > We need to start with the base requirements, which is, "I want an apex
> RR that allows HTTP browser indirection just as if there was a CNAME there".
> > Siblin
On Tue, Mar 26, 2019 at 6:02 PM Olli Vanhoja wrote:
> On Tue, Mar 26, 2019 at 5:36 PM Vladimír Čunát
> wrote:
> >
> > I'm not convinced that the resolver parts will be important, regardless
> of what exact mechanism will be chosen. My reasoning is that you can't
> rely on any changes there
I think the one proposal was very client-specific, which kind of ruled it
out for a generic "aname" type.
That was Ray's "HTTP" RRtype, that I did a deep dive on.
Basically, you are correct; the easiest path forward would be for client
software upgrades to get actual DNS records (rather than rely
On Mon, Mar 25, 2019 at 10:31 AM Patrick McManus
wrote:
>
>
> On Mon, Mar 25, 2019 at 9:37 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>>>
>>> \Other than blocking all-but-a-few (or all, or a few) DoT servers, I do
&g
On Mon, Mar 25, 2019 at 9:52 AM Valentin Gosu
wrote:
> On Mon, 25 Mar 2019 at 09:15, Brian Dickson
> wrote:
>
>>
>>
>> On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
>> wrote:
>>
>>> I'm not pushing against DoT per se in this thread, I am
orth having an AD/WG discussion on where these should be
developed; it might be better to do in DNSOP, rather than DPRIVE or DOH, or
alternatively spinning up a new, very focused WG for this work (I would not
be in favor of the latter).
Brian
> On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson <
> brian.pete
ide is extra processing of HTTP encoding, headers,
etc., and the sum is (HTTP + common path) , compared with (common path).
HTTP is not a zero-cost flow, so HTTP + x > x. QED.
>
> On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
&g
Sent from my iPhone
> On Mar 24, 2019, at 10:42 PM, Patrick McManus wrote:
>
>
>> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson
>> wrote:
>>
>> This is important for network operators in identifying encrypted DNS traffic,
>
> not all clie
On Sun, Mar 24, 2019 at 11:25 PM Paul Wouters wrote:
> On Sun, 24 Mar 2019, Brian Dickson wrote:
>
> > There is one important difference, which is that DoT uses a unique port
> number. This is important for network
> > operators in identifying encrypted DNS traffi
Sent from my iPhone
>> On Mar 24, 2019, at 9:43 PM, Patrick McManus wrote:
>>
>>
>
>> On Fri, Mar 22, 2019 at 11:15 AM Winfield, Alister
>> wrote:
>>
>> Don't overplay the privacy provided by DoH it has no effect on the DNS
>> provider
>
> The major effect of the transport security on
On Sun, Mar 24, 2019 at 4:49 AM Warren Kumari wrote:
>
>
> On Sun, Mar 24, 2019 at 11:46 AM Paul Hoffman
> wrote:
>
>> On Mar 24, 2019, at 11:18 AM, bert hubert
>> wrote:
>> > It may be good to add a note that "DoH is the protocol as defined in
>> > [RFC8484]. The operation of this protocol by
On Sat, Mar 23, 2019 at 10:44 PM Kenji Baheux wrote:
>
>
> On Sat, Mar 23, 2019, 13:04 Wes Hardaker wrote:
>
>> Kenji Baheux writes:
>>
>> > * We are considering a first milestone where Chrome would do an
>> automatic
>> > upgrade to DoH when a user’s existing resolver is capable of it.
nd comments to the list, clearly stating your view.
>
>
I am in favor of adoption of this draft by DNSOP WG.
> Please also indicate if you are willing to contribute text, review, etc.
>
I am willing to review and contribute text.
Brian Dickson
>
> This call for adoption
On Thu, Mar 21, 2019 at 3:03 PM Jacques Latour
wrote:
> Plus!
> Is anyone looking at adding DoH and DoT servers as part of DHCP/SLAAC? So
> the local resolver and apps and browsers can go the _appropriate_ name
> resolution resource(s) using the protocol of choice. That would be much
> simpler
On Tue, Mar 19, 2019 at 8:36 PM Stephen Farrell
wrote:
>
>
> On 20/03/2019 03:17, Brian Dickson wrote:
>
> > - If a network operator has any policy that is enforceable, ONLY the
> > technical policy enforcement model scales.
>
> My mail was about my policy for my ho
This has been an excellent discussion, with lots of insightful analysis,
examples, and great context.
I apologize in advance, but I'd like to pick one particular sentence, to
use for teasing out what I think is a foundational issue:
On Fri, Mar 15, 2019 at 11:37 AM Ted Hardie wrote:
>
> This
On Wed, Mar 13, 2019 at 1:43 PM Stephen Farrell
wrote:
>
> (dropping dprive list at WG chair request)
>
> Hiya,
>
> On 13/03/2019 20:29, Brian Dickson wrote:
> > The starting place for the conversation needs to acknowledge this, and
> > accommodate it. It is entir
On Wed, Mar 13, 2019 at 12:18 PM Christian Huitema
wrote:
> But then, if the user has not opted in such system, it would be nice if
> the ISP refrained from interfering with name resolution for that user. How
> do we achieve those two goals in practice?
>
> -- Christian Huitema
>
Even that
On Tue, Mar 12, 2019 at 3:51 PM Paul Vixie wrote:
> On Tuesday, 12 March 2019 21:38:44 UTC Stephen Farrell wrote:
> > On 12/03/2019 21:11, Paul Vixie wrote:
> > > ...
> >
> > There are reasons to want confidentiality for DNS queries
> > and answers, and access patterns, for which the IETF has
>
(Apologies for top-replying)
I think, from squinting at this a bit, that what is missing is some kind of
policy/service discovery, and coming to some kind of agreement (between
DNSOP and DOH, and any/all other interested parties) on what default
behavior should be (and under what
On Thu, Feb 14, 2019 at 12:34 PM Warren Kumari wrote:
>
>
> On Thu, Feb 14, 2019 at 2:53 PM Stephane Bortzmeyer
> wrote:
>
>> On Mon, Jan 07, 2019 at 12:30:10PM -0800,
>> internet-dra...@ietf.org wrote
>> a message of 44 lines which said:
>>
>> > Title : Extended DNS Errors
I've been thinking a bit about some of the issues raised in the recent DoH
discussion.
What I am wondering about, is what the goals of different parties might be.
I am also wondering whether some available standards (or additions to some
of those standards) might be helpful.
Finding particular
On Fri, Jan 25, 2019 at 7:10 PM Davey Song(宋林健) wrote:
> Hi Brian,
>
> Thanks for your questions. Reply inline
>
> >(1) Has your testing revealed *where* the IPv6 fragmentation is
> occurring? IIRC, IPv6 requires the originating host to do so. And
> originating UDP packet size will be the
(Top-reply, apologies for those offended by this practice.)
I also oppose adoption (at least of the draft in its current form).
Very quick questions:
(1) Has your testing revealed *where* the IPv6 fragmentation is occurring?
IIRC, IPv6 requires the originating host to do so. And originating UDP
On Tue, Jan 8, 2019 at 4:21 AM Tony Finch wrote:
> Brian Dickson wrote:
>
> > I think it might be good to scope the 6761 issue, with something like the
> > following:
>
> [SNIP]
>
> > > I.e. it is necessary to recognize all special use names, and necessary
&
On Mon, Dec 31, 2018 at 4:29 PM John R Levine wrote:
> Let's assume for the purposes of argument that we have a DNS server that
> knows how to translate between A-labels an U-labels. Then I invent this
> DNS record
>
>
Can I ask you to please describe in lay-persons terms what you are trying
to
>
>
> On 27 Nov 2018, at 1:54 am, Tony Finch wrote:
> >
> > Richard Gibson wrote:
> >>
> >> I am currently going through a similar exercise in another context, and
the
> >> best current text there explicitly characterizes the non-obvious
day-based
> >> accounting of POSIX time.
> >
> >
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
On Fri, Nov 9, 2018 at 12:09 PM Paul Vixie wrote:
> Brian Dickson wrote:
> > Paul Vixie wrote:
>
i don't love the dnssec implications of this, including proof of
> nonwildcard.
>
I'm not 100% sure, but I think the generic DNSSEC response handling already
covers this.
If
On Thu, Nov 8, 2018 at 11:47 AM Dan York wrote:
> Brian,
>
> > On Nov 8, 2018, at 10:30 AM, Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
> >
> > For new RRtypes, registries, registrars, and their provisioning services
> do NOT need to support them;
I'm going to start a clean, related thread, to discuss a bunch of
questions, that I think can help with the ongoing threads.
Rationale:
I think many of the viewpoints some folks have are skewed by pre-existing
familiarity with the protocol, and implementations (including browsers,
libraries,
Paul Vixie wrote:
> 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 think that
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
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
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 to have the perspective of one
segment of the DNS ecosystem, that of the authority operators
On Thu, Nov 1, 2018 at 12:09 PM Joe Abley wrote:
> On 1 Nov 2018, at 15:06, Brian Dickson
> wrote:
>
> > Maybe signaling the algorithm(s) for which signature(s) are
> desired/understood would do the trick?
>
>> > I.e. in an EDNS option?
>>
>> I don'
On Thu, Nov 1, 2018 at 11:52 AM Joe Abley wrote:
> On 1 Nov 2018, at 14:49, Brian Dickson
> wrote:
>
> > So, giving this some tiny bit of thought:
> > When is zonemd added to a response, is that when doing an AXFR?
>
> Construction of ZONEMD RRs and responding to AXF
Joe wrote:
> On Nov 1, 2018, at 16:27, Paul Hoffman wrote:
> > The current ZONEMD draft fully supports algorithm agility. What it
> doesn't support is multiple hashes *within a single message*. Having seen
> how easy it is to screw up OpenPGP and S/MIME message processing to handle
> multiple
Sent from my iPhone
> On Aug 20, 2018, at 10:57 AM, Paul Wouters wrote:
>
>> On Mon, 20 Aug 2018, Shumon Huque wrote:
>>
>> On Sun, Aug 19, 2018 at 3:29 PM Paul Wouters wrote:
>>
>> When using DNSSEC, the resolver should follow the glue and then perform
>> a query at the child
rs of resolvers. A centralized distribution point WITH
data integrity protection that scales, provide protection against both
centralized AND decentralized (direct cache poisoning) attacks, thus
justifying the effort on doing this exact thing.
Brian Dickson
P.S. Documenting aspects of
Warren wrote:
> how do they know they
> can trust the zone file before loading it?
And Joe Abley commented about non-apex NS records and glue, not being part
of the current DNSSEC design/goals/requirements.
I'll start my questions/proposal(s) with a scope question:
- Is it a safe
Paul Vixie wrote:
> Tony Finch wrote:
>
> Paul Wouters wrote:
>
> I understand, I just disagree this is the right way. I don't see why
> this entire problem shouldn't be resolved at the well, resolver level.
>
> I don't see how that can be deployed in a way that is compatible with
> existing
[Attribution of the following quotes to Joe and Petr omitted...]
> > However, I think the more general idea that queries for internal names
> > should be leaked towards unknown AS112 operators is problematic. As an
> > end-user I would prefer my leaked queries to be jealously hoarded by one
> >
(Apologies for neither top- nor bottom- posting, i.e. not quoting any other
emails.)
There are corner cases which exist, where desired behavior of some
resolvers is not possible to achieve.
This mostly has to do with constraints where "local policy" may have more
than one scope.
I.e. Inside a
>
> Paul wrote:
> Evan Hunt wrote:
> (I do like the idea of advertising a separate expiry value though.)
> i think if we're going to put something into the 20-year deployment funnel
> we should treat the fixed costs as high and demand more benefits. that's
> where the proposal up-thread came
Sent from my iPhone
> On Aug 17, 2017, at 7:20 PM, Ted Lemon <mel...@fugue.com> wrote:
>
> El 17 ag 2017, a les 21:54, Brian Dickson <brian.peter.dick...@gmail.com> va
> escriure:
>> If you're trying to use "localhost", that means you're using s
On Thu, Aug 17, 2017 at 6:28 PM, Ted Lemon <mel...@fugue.com> wrote:
> El 17 ag 2017, a les 18:22, Brian Dickson <brian.peter.dick...@gmail.com>
> va escriure:
>
> Sorry if this isn't as clear as I intended - basically, what I'm saying,
> is that the answer might
The discussions about localhost (and 127.0.0.1 and ::1) have ben very
enlightening.
However, I wonder whether the desired use case -- reliably establishing a
connection to a host, based on information in DNS -- might be more
securely/reliably solved using other mechanisms?
Using "localhost" is
nk a defined mechanism exists,
procedure-wise.
Brian
>
> -George
>
> On Tue, Apr 4, 2017 at 11:26 AM, Brian Dickson
> <brian.peter.dick...@gmail.com> wrote:
> > In response to the latest comments by Paul Hoffman and George Michaelson,
> > I'd like to offer my
I have looked at the need for unsigned delegations required to satisfy stub
validators, and am interested in feedback to an idea I have: signal to the
stub, deliberate non-use of DNSSEC.
The presumption is that a stub's use of a recursive resolver involves some
degree of "trust", at least if it
>
> Apologies but I did not hear the full question regarding BULK RR’s and the
> perl like back-references. If you could please repeat the question we
> would be happy to comment.
>
>
>
>
>
> Thanks,
>
> John
>
Sorry for the delayed response.
The question was:
Given the use of perl-style
201 - 300 of 363 matches
Mail list logo
