Oh – and to clarify the QRT reduction – these measurements are happening while
load is being generated on the connection – so it is a test of ‘working
latency’ for DNS in this case.
Jason
From: "Livingood, Jason"
Date: Saturday, September 30, 2023 at 09:37
To: dnsop
Subject: Off-T
For those of you that have missed work happening in TSVWG – there are recent
L4S and NQB docs that specify a method to achieve low latency via a 2nd network
queue at bottleneck links. That depends on a client marking traffic using ECN –
via ECT(1) or CE – and/or DSCP-45.
I am in the midst of le
Since it is in WGLC – are you able to close out the issues in Github?
(https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues)
Jason
From: DNSOP on behalf of Tim Wicinski
Date: Tuesday, January 24, 2023 at 21:55
To: Daniel Migault
Cc: Florian Obser , dnsop
Subject: Re
I support adoption.
I also suggest the authors take a look at two long-ago-expired I-Ds that are
related to this subject:
https://www.ietf.org/archive/id/draft-livingood-dns-malwareprotect-02.html
https://www.ietf.org/archive/id/draft-livingood-dns-redirect-03.html
Lastly, to the contents of th
Good idea, and I volunteer to assist if you'd like. Some stuff that may be good
to consider including:
- Negative Trust Anchors - https://datatracker.ietf.org/doc/rfc7646/
- In case of DNSSEC validation failures, don't switch resolvers -
https://datatracker.ietf.org/doc/draft-livingood-dnsop-dont
On 7/21/19, 4:27 PM, "DNSOP on behalf of Puneet Sood":
> Running the experiment from locations which are further away from cloud
> providers would provide another interesting set of data.
[JL] +1. I understand the US FCC is considering running DoH tests from their
Measuring Broadband America end
DoT and DoH seem fine. But maybe skip the acronym for Do53 - just call it
conventional DNS or unencrypted DNS, or DNS over Port 53. Compared to
RDoT/ADoT/DaT/DaO however, Do53 is the least offensive IMO.
I don’t think you do much for clarity with RDoT and ADoT - seems mostly to be
used because
On 3/22/19, 3:53 AM, "Doh on behalf of Vittorio Bertola" wrote:
> letting each application pick its own default resolver, creates a fragmented
> mess of a network
[JL] Troubleshooting also becomes potentially more complicated. I can't ask a
user to run dig or nslookup and tell me what it says
Last week I did a draft agenda at
https://github.com/jlivingood/IETF-104-SideMtg/blob/master/draft-agenda.txt but
to some extent large parts may have been overcome by events and need major
changes. Maybe it is sufficient to have the various drafts presented and let
discussion flow from that? It
On 3/12/19, 11:40 PM, "Doh on behalf of Christian Huitema"
wrote:
> Why do you think you can filter content? Who made you king?
[JL] End users may have opted into / subscribed to such a parental control
system. An enterprise may say we'll only connect to the Internet and allow
traffic of X or
A few years ago I had somehow succeeded in getting WG adoption of 2 documents
that addressed some pet peeves I had as a recursive DNS operator. Things got
busy and my attention wandered elsewhere and I did not advance them. Since
these issues continue to haunt RDNS operators, I have decided to u
On 8/19/18, 1:02 PM, "DNSOP on behalf of Doug Barton" wrote:
> Personally I see securing the path from the stub to the resolver as a
good step in the ultimate goal of encrypting all of the things. :)
[JL] No disagreement here. I think the issue may be more to do with choice over
the r
On 8/18/18, 7:03 PM, "DNSOP on behalf of bert hubert" wrote:
Especially when such a move will incidentally kill intranets, VPNs, split
horizon, DNS monitoring & DNS malware detecion and blocking.
It seems to me that the underlying protocol is separable from the operational
implementatio
In a DOCSIS network, for whatever that's worth, the link from the home (cable
modem) to the next hop (CMTS) is encrypted. It is then usually just one or two
hops within the ISP's regional network to the recursive DNS (in some cases
DNSSEC-validating, as in our case). So I suppose that the threat
On 7/9/15, 11:56 AM, "Evan Hunt" wrote:
>Valid point. When the NTA for a name expires, the cached data at and
>below that name can also be discarded, so TTLs aren't a major concern
>when the cache and the validator are coresident,
Yeah, in my experience when we remove a NTA we do a cache flush fo
On 5/7/15, 10:41 AM, "Ted Lemon" wrote:
>I think this is an unfortunate way to look at the issue.
FWIW, it is not necessarily my opinion. I could just see people asking
about it in that way - in which case the IETF needs to have a firm and
logical response. I think some of the emails already sen
On 5/6/15, 2:07 PM, "Suzanne Woolf"
mailto:suzworldw...@gmail.com>> wrote:
c) The requests we're seeing for .onion and the other p2p names already
in use are arguing that they should get their names to enable their
technologies with minimal disruption to their installed base. While the
On 2/13/15, 9:05 AM, "Livingood, Jason"
mailto:jason_living...@cable.comcast.com>>
wrote:
we've got running code in bind. and no doubt other product.
Should be also in Nominet’s resolver.
BTW, I meant NomiNUM not NomiNET. Darned
Fair point. IMO whitelisting is a common tactic used early on in deployment of
new stuff to help manage deployment risk. It was also used in early IPv6 days
where query access to RRs was whitelisted (see
http://tools.ietf.org/html/rfc6589). I suspect it would be similar here; that
the need
On 2/12/15, 2:54 PM, "George Michaelson"
mailto:g...@algebras.org>> wrote:
we've got two agencies who do DNS, and probably have > 20% worldwide eyeball
share in DNS (I don't know, thats a guesstimate) now doing edns0_client_subnet
albiet with whitelist, so its a permit-list, but its functionall
On 2/12/15, 2:51 PM, "Mark Delany" wrote:
>Tap tap tap. Is this thing turned on?
>
>I think 3-4 people made some well-considered feedback on this draft, but
>there has been zero discussion or author feedback for some six weeks now.
>
>Does that mean there is insufficient interest in progressing t
Unfortunately, I won’t be able to attend this workshop.
I understand the need and desire for many geographic area and networks to run a
local anycast node associated with one of the existing root letters. I have
heard that in some cases the root operator is willing to enable a local anycast
nod
On 10/25/14, 10:12 PM, "Warren Kumari"
mailto:war...@kumari.net>> wrote:
On Sat, Oct 25, 2014 at 9:50 PM, Paul Hoffman
mailto:paul.hoff...@vpnc.org>> wrote:
On Oct 25, 2014, at 6:43 PM, Olafur Gudmundsson
mailto:o...@ogud.com>> wrote:
We want humans in the loop, I would love to see a twitter fe
On 10/24/14, 6:06 PM, "Doug Barton" wrote:
>But worse yet, in the operator error case you make such errors painless.
>Instead, if they are painful (as in, screw up DNSSEC and you go off line)
>then it leads to more people taking DNSSEC seriously, and doing it right.
>Of course I realize that the
On 2/18/13 4:56 PM, "Mark Andrews" wrote:
>In message <51228dfb.3070...@ogud.com>, Olafur Gudmundsson writes:
>> Jason, in section 10 you talk about possible early removal the NTA when
>>validation succeeds but there may be instances where validation succeeds
>>when using a sub-set of the authori
On 2/20/13 1:52 PM, "Joe Abley" wrote:
>
>On 2013-02-20, at 14:50, Richard Lamb wrote:
>
>> FWIW: The -04 draft looks good. It is clear and well written and I
>>think it is a valuable resource.
>> As I am late to looking at this draft please take this only as a
>>comment from a narrow minded e
On 2/18/13 3:24 PM, "Olafur Gudmundsson" wrote:
>Jason, in section 10 you talk about possible early removal the NTA when
>validation succeeds but there may be instances where validation succeeds
>when using a sub-set of the authoritative servers thus NTA should only
>be removed if all servers ar
On 2/20/13 1:50 PM, "Richard Lamb"
mailto:richard.l...@icann.org>> wrote:
As I am late to looking at this draft please take this only as a comment from a
narrow minded engineer ;-) After the rationale, explanations and caveats I
kept looking for how to implement a NTA. After initially thinkin
Ack. Tracking the need for examples in the open issues log for the I-D.
On 2/19/13 4:21 PM, "Warren Kumari" wrote:
>
>On Feb 16, 2013, at 7:43 PM, Paul Hoffman wrote:
>
>> Ted's misunderstanding of what you are proposing is a valid one. You
>>don't actually say what a negative trust anchor is,
Thanks for catching that - will correct this in -05.
Jason
On 2/18/13 10:57 AM, "Marco Davids (SIDN)" wrote:
>Jason,
>
>On 17/02/2013 10:22, Livingood, Jason wrote:
>>> Based on feedback yesterday on the list, I did a quick 04 update
>
>Personally I would a
Inline below (and some proposed text for you to give feedback on).
- Jason
On 2/17/13 10:19 AM, "Ted Lemon" wrote:
>On Feb 17, 2013, at 9:57 AM, "Livingood, Jason"
>
> wrote:
>> A Negative Trust Anchor should IMO be locally configured and not rely
>>up
Based on feedback yesterday on the list, I did a quick –04 update, which is now
at https://datatracker.ietf.org/doc/draft-livingood-negative-trust-anchors/.
The are seven open issues documented at the end of the I-D. But the most
important questions for this WG are:
1 – Is this worth considerat
On 2/16/13 7:43 PM, "Paul Hoffman" wrote:
>Ted's misunderstanding of what you are proposing is a valid one. You
>don't actually say what a negative trust anchor is, and what it is a
>trust anchor for, until section 7. Readers such as Ted (and myself!) will
>have strong prejudices by then.
Yeah,
On 2/16/13 6:21 PM, "Joe Abley" wrote:
>Jason: you didn't ask directly, but if the working group was polled to
>determine support for adopting this document, I would say yes and
>volunteer to review it.
Thanks, Joe, for prodding me to be more explicit! ;-) Yes, that is indeed
one of my questions
On 2/16/13 6:32 PM, "Ted Lemon" wrote:
>> I'm confused where you drew the reference to 5280 from (or X.509). I
>>don't see anything in the draft that concerns publication or automatic
>>retrieval of NTAs from elsewhere; which section did I miss?
>
>Sorry, I was one RFC deeper in the reference tr
I just posted (finally, I know) an update to
draft-livingood-negative-trust-anchors, which you can find at
https://datatracker.ietf.org/doc/draft-livingood-negative-trust-anchors/.
This update incorporates feedback from Paul Vixie, Antoin Verschuren, Patrik
Wallstrom, Patrik Falstrom, Marc Lamp
Seems a really interesting idea.
Jason
On 1/21/13 10:37 AM, "Paul Hoffman" wrote:
>On Jan 21, 2013, at 3:02 AM, Stephane Bortzmeyer
>wrote:
>
>> I already mentioned this service here, but it is now officially in
>> production:
>>
>> http://www.bortzmeyer.org/dns-lg.html
>>
>> What is of spe
effects on recursive resolvers (system shocks where QPS load may
go up 100% - 200% in a few minutes)
Jason
On 1/18/13 11:03 AM, "Livingood, Jason"
wrote:
>If there is anyone out there interested in doing research into DNS
>recursive resolvers and are seeking either (1) access to d
If there is anyone out there interested in doing research into DNS
recursive resolvers and are seeking either (1) access to data (stripped of
PII of course) and/or (2) modest funding support, please let me know
off-list.
- Jason
On 2/20/12 2:27 PM, "Emiliano Casalicchio"
wrote:
>John,
>may be
em.
Scott
On Apr 19, 2012, at 10:39 AM, Livingood, Jason wrote:
In case anyone knows the domain admins…
Jason
On 4/11/12 5:58 PM, "Szymanski, Todd M [NTK]"
mailto:todd.szyman...@sprint.com>> wrote:
For those who can’t see pictures, it’s identitytheft.gov. Looks like
On 4/15/12 10:42 AM, "Joe Abley" wrote:
>Patrik,
>
>Nobody is talking about creating NTAs. NTAs already exist. The question
>for this group is whether or not they are worth standardising.
>
>Joe
Quite true, Joe! We'll keep using NTAs as needed. But I've had enough
people ask me to document what
On 4/14/12 9:23 PM, "Warren Kumari" wrote:
>Yes, but AT&T, Verizon, Cox, BestWeb, RR, TW, etc are currently *not*
>doing validation, and currently don't have much in the way of incentives
>to start -- yes, NASA was an unusual event, but what was the standard
>advice that kept popping up on twitte
On 4/13/12 9:51 PM, "Doug Barton" wrote:
>The problem, and I cannot emphasize this highly enough, is that there is
>absolutely no way for an ISP (or other end-user site doing
>recursion/validation) to determine conclusively that the failure they
>are seeing is due to a harmless stuff-up, vs. an
On 4/13/12 5:18 PM, "Patrik Fältström"
mailto:p...@frobbit.se>> wrote:
On 13 apr 2012, at 22:44, Nicholas Weaver wrote:
Because practice has shown that it is the recursive resolver, not the
authority, that gets blamed.
As you saw in my mail, I completely disagree from my own personal experienc
On 4/13/12 5:00 PM, "Patrik Fältström"
mailto:p...@frobbit.se>> wrote:
In a private chat I am asked to explain my "+1".
Let me explain why.
Today, before negative trust anchors, the responsibility for whether a the
resolution that is basis for a connection establishment is with the zone owner.
On 4/13/12 1:43 PM, "Paul Vixie" wrote:
>we need to move quickly to the point where lots of large eyeball-facing
>network operators are validating, such that any failure to properly
>maintain signatures and keys and DS records, is felt most severely by
>whomever's domain is thus rendered unreach
>Joe Abley writes:
>
>> On 2012-04-11, at 12:09, Wes Hardaker wrote:
>>> NTA example.com Thu Apr 12 09:06:42 PDT 2012
>>
>> I realise this is just a thought experiment
>
>Well, true it certainly is. And in fact the above thought experiment
>wasn't meant to imply a resource record, but rather a c
Inline
On 4/11/12 10:16 AM, "Tony Finch" wrote:
>Griffiths, Chris wrote:
>> On Apr 10, 2012, at 8:11 PM, Wes Hardaker wrote:
>>
>> > Suggested rewrite:
>> >
>> > Furthermore, a Negative Trust Anchor MUST only be used for a
>> > short duration, perhaps for a day or less.
>>
>> Agr
Inline.
- JL
On 4/12/12 8:21 AM, "Marc Lampo" wrote:
>The draft of Negative Trust Anchors does not mention anything about
>informing the operator of the failing domain.
I'll make a note to call this out in the next version. Something about
making reasonable attempts to notify the domain of the
Had a double copy & paste error! Here is the 2nd domain:
http://dnsviz.net/d/www.bitcoinica.com/T4pqsA/dnssec/
>http://dnsviz.net/d/www.bayfieldelectric.com/T4wofg/dnssec/
>
>
>http://dnsviz.net/d/www.bayfieldelectric.com/T4wofg/dnssec/
>
___
DNSOP ma
Inline below.
- JL
On 4/10/12 10:06 AM, "Shane Kerr" wrote:
>Jason,
>
>On Tuesday, 2012-03-27 15:19:23 +,
>"Livingood, Jason" wrote:
>> I posted a 01 a short time ago
>> (http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01)
&
I am an author of the document and am just back from vacation today. I will
start to read and respond to the many emails now – did not want anyone to think
I was ignoring the discussion. :-)
Jason
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.
I posted a –01 a short time ago
(http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01) and
listed this in open items for the next version. I may have some questions on
the best way to include that.
Jason
On 3/27/12 2:04 PM, "Antoin Verschuren"
mailto:antoin.verschu...@sidn.nl>
>I read the draft and like the direction of it.
>It looks like you are proposing turning off a validation for domain by
>the negative trust anchor.
Correct
>An alternative is to insert a negative trust anchor for a particular
>trust anchor.
Do you mean when an alternative trust anchor is used by
I just posted a –00 of a draft that may be of interest to this WG. It covers an
issue we have found in our DNSSEC deployment. My co-author is doing some markup
of the doc now so I am hoping to post a –01 before the end of this week. (I've
already found some minor typographical and grammatical er
At the last IETF meeting I presented my individual I-D on IPv6 DNS
whitelisting. This was subsequently adopted as a WG item in v6ops. Yesterday, I
posted a new -01 version of this draft for WG feedback by v6ops and dnsop at
http://tools.ietf.org/html/draft-ietf-v6ops-v6--whitelisting-implica
+1 (from the 'something is better than nothing' school of thought) :-)
On 10/19/10 7:01 AM, "Tony Finch" wrote:
>On Tue, 19 Oct 2010, Jim Reid wrote:
>> On 19 Oct 2010, at 09:26, Johan Ihren wrote:
>> >
>> > B. "Better to publish what we have and initiate work on a -bis
>>document
>> > immediat
Hi -
I am soliciting feeback on this new draft, available at
http://tools.ietf.org/html/draft-livingood-dns-whitelisting-implications. This
was a subject that was touched on during the DNSOP WG session at IETF 77. In
particular, I am looking for more text to add in the justifications / rational
legal mandate and one for content filtering. I plan to hold off on
investing time in either of those for now, unless the WG would like to see
those specified in a new document.
Jason
On 9/6/10 2:30 PM, "Livingood, Jason"
wrote:
>It's been a little over a year since the firs
It's been a little over a year since the first draft on this subject was
submitted. I received a lot of feedback on that draft from the WG, including a
request to remove all forms of redirect mentioned other than web error
redirection (such as malware protection) and to add a much more pointed
Good points, all. One of the things I noted from the WG meeting was the
desire to separate the different types of redirect into distinct I-Ds, which
I plan to do. That should help avoid conflating what are very different
sort of redirect in practice.
Thanks
Jason
On 7/28/09 5:02 AM, "Alissa Co
Great feedback, Dave. Thank you and we¹ll take it into account as we work
on a revision.
Jason
On 7/17/09 1:02 PM, "Dave CROCKER" wrote:
>
>
> Jason, et al,
>
> This note suggests changes in both style and detail in
> draft-livingood-dns-redirect-00. All of the points made here have been
>> FWIW, I think most ISPs that introduce such services see around a
>> 0.1% opt-out rate.
>
> What does it prove? Most ISP that introduces lying resolvers as an
> opt-in service see a 0.1 % opt-out rate, too. It proves only that most
> users do not dare to change the settings or are not informed
> TLDs, including your own zones. This is indeed not just Site Finder
> all over again - it's far worse, and breaks far more applications than
> Site Finder did.
Please do send me that list of applications. I would very much like to
describe these use cases in the next version of the draft.
Tha
>> SSAC's Report on DNS Response Modification
>> http://www.icann.org/en/committees/security/sac032.pdf
>
> Indeed. Good document. There is no need to discuss about
> draft-livingood-dns-lie,
Is that really necessary?
> all the issues raised here in this WG were
> already in the SSAC document
>> > I'll speak for my parents here: a DNS resolver that reduces the chance that
>> they'll get a drive-by malware
>> > infection is something they would happily use. Having said that, a DNS
>> resolver that gives them a page of
>> > search results instead of the browser's error page when they mist
On 7/16/09 3:22 AM, "Stephane Bortzmeyer" wrote:
>
>> > I did not hear them so this sort of users is obviously not in the
>> > dnsop WG :-) More seriously, noone mentioned here any survey about
>> > this. So, we can just guess and speculate.
>
> You can probably safely assume that any large I
Thanks for your detailed review. We¹ll reply when we start to work on the
01 update.
Regards
Jason
On 7/14/09 7:21 PM, "SM" wrote:
> Hello,
>
> When I first read draft-livingood-dns-redirect-00, my first thought
> was about how would it be received if the author was from some
> country in t
On 7/14/09 8:58 AM, "Suzanne Woolf" wrote:
> In this case, we're talking about resolvers replacing
> authoritative server data with their own.
Actually, I thought the case was resolvers providing an alternate response,
where NO authoritative data exists. ??
> To the draft specifically: the
t 11:23:48AM -0400, Livingood, Jason
> wrote:
> If anyone is interested and has time before IETF 75, I¹m happy to
> take
> feedback before then obviously. Please note that there is a list of
> open
> items at the end, which we plan to address in subsequent versions.
I
> have read d
Thanks for the suggestion, Tony. I will add that to my tracking list for
the next revision (and may email you to confirm what I have might be
satisfactory). I think we probably also need to address the fact that mail
servers should not use resolvers that perform DNS redirect (this was assumed
but
> On Jul 9, 2009, at 5:23 PM, Livingood, Jason wrote:
>
>> > I submitted this draft, which you can find at
>> http://tools.ietf.org/html/draft-livingood-dns-redirect-00
>> > , before the 00 cutoff on Monday, and it will be discussed in the
>> > DNSOP
Thx for the **very detailed** and thoughtful feedback. I will review &
respond in detail when I start working on the 01 revision.
Jason
On 7/12/09 4:30 AM, "Florian Weimer" wrote:
> * Jason Livingood:
>
>> > If anyone is interested and has time before IETF 75, I¹m happy to take
>> > feedbac
Thx for the feedback. I will try to address your concern in the 01
revision. If you have any specific textual recommendations, let me know.
Jason
On 7/12/09 3:34 AM, "Florian Weimer" wrote:
> * Stephane Bortzmeyer:
>
>> > Unless I'm wrong, the I-D about lying resolvers do not discuss the
>
Good guidance on Informational vs. BCP. We may get there eventually, but I
thought that starting as a draft BCP might provoke more detailed and useful
debate. ;-)
On the topic of lying resolvers¹ though, that seems a bit strong IMHO. But
perhaps I have missed a strong MUST statement (per RFC 2
I submitted this draft, which you can find at
http://tools.ietf.org/html/draft-livingood-dns-redirect-00, before the 00
cutoff on Monday, and it will be discussed in the DNSOP WG meeting at IETF
75 (it is listed on the agenda).
If anyone is interested and has time before IETF 75, I¹m happy to tak
Yesterday, we attended a DNSSEC policy meeting in Washington, where we
announced that we've started a DNSSEC technical trial at Comcast. We
tend to be rather hands-on learners, so we implemented a DNSSEC-capable
resolver in our production network. Anyone on the public Internet is
welcome to point
77 matches
Mail list logo
