Tim Wicinski writes:
> This starts a Call for Adoption for Negative Caching of DNS Resolution
> Failures
Yep, definitely needed and will support by reviewing.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/m
Tim Wicinski writes:
> Please also indicate if you are willing to contribute text, review,
> etc.
I think this is an import draft and will support it by reviewing it and
suggesting text (I already have some minor things I'll likely bring up).
--
Wes Harda
cords. I don't think signing the distributed records would change the
behavior of whether or not clients cached them or whether clients
believed who was authoritative (IE, I don't think resolvers are making
caching decisions based on whether something was signed or not).
--
Wes Hardaker
USC/IS
shed update)
> This document should probably update RFC 7583 because it is giving a
> better definition of Itrp and Irev.
Probably true too. Thanks for pointing that out. I'll be honest, I've
always had a hard time reading 7583 because the acronyms fly fast a
furious and it's
eone recently:
> I mean, bring it on.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
hat can be
> used for defining the extra safety margin.
I'll have to add some text about that. I don't think we can solve the
case for broken networks, though. But it's an important point to bring up.
--
Wes Hardaker
USC/ISI
___
DNSO
f DDoS attacks. Is your opinion then that
everyone should be using a DDoS resilient cloud provider in case they
ever get attacked?
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
y to ensure
it's never assigned, to actually registering it, to...
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
see the new key after the (sig_exp + N + 30 days) mark will be at
(sig_exp + N + 30 days + remainder(30 days / 7)). So we don't need to
add in a full queryInterval to cover the offset and can calculate it
instead.
(that being said, I put "you might pick 2x for
Bob Harold writes:
> "T-29" should be "T+29"
Good catch; thank you!
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ecent version based on your review from July.
Wes Hardaker
Table of Contents
_
1 Notes / Edits from Mike StJohn on <2017-07-06 Thu>
.. 1.1 ACCEPTED Use "exclusively" rather than "only" where you can - "only" has
.. 1.2 ACCEPTED In the i
t$ as the query name, which
amounted to .018% of the total traffic.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
1.6 you have 4. You're missing the safetyMargin which you didn't
actually define completely in section 6.1.5.
+ Result: I think you mean activeRefreshOffset, as safetyMargin was defined
(though we had to change it again due to the possib
clear that the entire 32 bits are needed.
Thoughts?
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
>Please, please please just move to a wall clock value based on the
>latest expiration date plus appropriate intervals. All the minor
>twiddles you've done to try to avoid doing this have made the document
>less clear.
I've changed the wordi
gt;
> Or, neither of them are errors :-)
We'll remove the restriction in any wording that says it can only be for
errors. I think there is clear consensus to do so.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ntation without looking at the mail I sent and synchronizing the
numbering.
The preferred option in the room was the 16-bit value that would be used
in combination with the rcode to indicate the full meaning of the
extension value.
--
Wes Hardaker
USC/ISI
___
to define this as the "MUST NOT go
below this line" without trying to be precise about a value that can never be
perfectly accurate, by definition.
But, forget my opinion. What's yours? If nothing else, pick one of the
[12][ABC] options above please, even without any text defini
Wes Hardaker writes:
> After thinking about this for far far too long, I've now switched my own
> opinion to that of 2C
(errr... that should have been "2B")
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https:/
Michael StJohns writes:
> 1 something.
I think that the consensus is clearly something like that. Are you
(MSJ) interested in supplying a suggested final equation for it?
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
ht
ndling.
That being said, even with the above grumpiness, I DO SUPPORT the
creation of the document (believe it or not) as I realize we don't have
much of a choice in order to solve the very-important signaling problem
we're current stuck with. I'll review (already have; comments c
ines and rounded
all the numbers up, since resolvers won't query in a fraction of an
increment.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
l the new safetyMargin concepts proposed by MSJ. I haven't done a
complete double check on all my restructuring yet, so for the chairs
especially: there will likely be a -09 very soon ready for second WGLC,
but not this one.
--
Wes Hardaker
USC/ISI
___
DNSO
Michael StJohns writes:
> Much improved - but still some disconnects (all review is de novo):
That's Mike. All good comments. I've attached responses and actions
(or inactions) below and will push a new version shortly as well.
Wes Hardaker
Table of Contents
___
have the choice of spending time and a travel budget
toward an IETF or toward a *OG/RIPE, it's much more likely you'll head
toward the dedicated operational camps. I'm not sure that means we
shouldn't produce work out of the O&
Michael StJohns writes:
Hi Mike,
Thanks for explaining your thinking because I think, after reading it:
we're actually in agreement but using different terms for where to put
in the slop you're worried about.
Specifically:
> A perfectly operating resolver with perfect clock and perfect
> conne
rgue is incorrect. As I said last time and this time,
I'd be happy to insert a "drift" term, but lets please label it what it
is. If you agree with that, I'll make that change and push.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
monstration. Will try to work on it later today.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e.
2) "is one activeRefresh period long enough to account for network
delays and other elements, aside from 'retries and missing queries'?"
I think you and I agree on this too, that one should be sufficient to
cover network delays too.
--
Wes Hardaker
USC/ISI
_
/projects/5011/
I didn't add the re-transmit time issue that your code takes into
account, but I did add a query drift that nicely shows one of your
concerns. In particular, with various values of query drift (including
-1) you can reproduce the real world situation that you're worried
triggers at 0 for both ends
> of the problem] when what
> you want is worst case.
Try 300d in resolver query offset.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Additionally, I wrote a javascript based calculator for a single
resolver so you can try to put in "worst case" numbers into form fields
and have it calculate what happens here:
https://www.isi.edu/~hardaker/projects/5011/
--
Wes Hardak
hed document doesn't have the 2*, even though the
previous non-expanded version should have lead to it).
I'll do a final check of equations again today, as well as look to make
sure I didn't state drift can only happen for one query (though I'm sure
I didn't say that).
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Wes Hardaker writes:
>> Again:
>>
>> addWaitClockTime = lastSigExpirationTime + activeRefresh +
>> addHoldDownTime + activeRefresh + safetyMargin (which now seems to be
>> labeled retrySafetyMargin).
>
> Which is exactly what's in ... *crap* ...
to request a 2-week last call instead as I think the changes are
important enough to warrant a longer LC. Chairs? Thoughts?
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e
the flipside in 6.2.1, but again that's where we disagreed on the best
way to present it so I added both so we'd both be happy.
In the end, in this version of the document you and I both agree on the
math, but not necessarily on how it's presented. Thanks.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
and should not exist). Let's not start adding special exceptions.
We could do something crazy like "return NXDOMAIN" and don't set the
AA bit, because the DNS is not authoritative for that domain (and
others, like .onion). But I'm not sure that helps anyone, and adds
unneede
e the chairs will go forward with the last call and
consider this a part of it]
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
push out a new version. We've been collecting error codes from other
places (old drafts that we had to dig up) and hope to get something
flushed soon.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
kinds of situations. Maybe someone will author such a guide in the
future and a different model for calculating potential losses can
completed and that document can UPDATE this one.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e moment), but I have more time than I did a year ago
so the trend is right...
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Michael StJohns writes:
> I strongly object to the publication of this document as a Standards Track
> document.
I'll catch up on the rest of the thread later tonight (I've been gone),
but I agree with MSJ here: it should be informational; it's not a
protocol.
--
ng
DNS but all git, bittorrent, http, and Warren's dirty napkin), then
there is value to having a verifiable checksum. That's why software
packages are distributed in the same way: verify that what you got is
authentic before using it.
--
Wes Hardaker
USC/ISI
__
we don't collectively interpret the sentence you quote
as meaning 'this is only useful for the root zone' just because that was
the original motivation.
In fact, I'd even argue to remove that sentence if it's causing such confusion.
--
Wes Hardaker
USC/ISI
__
se case, so if
> I ignore that, we are looking at specifically the root zone only.
Please don't ignore that. We really do ourselves a disservice when we
design a solution that only works for singular or minimal instances.
This is beneficial to more than just the root zone.
DNS zone data currently doesn't exist. That's what we're trying to accomplish.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> some (boilerplate?) language about how IANA is asked to operate the
> registry: what criteria judge acceptance. Is it like the OID and
> basically open (hair oil) slather, or is it only at WG RFC documented
> request?
If there is a better templa
dentifiers supporting AXFR today (some of whom
added it specifically because of wanting to support this project)
include B, C, D, F, G, and K. Plus ICANN has their AXFR addresses, as
previously mentioned, at lax.xfr.dns.icann.org and xfr.cjr.dns.icann.org .
--
irst in order to evaluate the need to do a bis].
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
earlier implementations when
that specification is no longer used because hashtrees are so cool that
nothing else is ever needed.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
the whole space.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
internet-dra...@ietf.org writes:
> Title : Extended DNS Errors
> Authors : Warren Kumari
> Evan Hunt
> Roy Arends
> Wes Hardaker
>
houghts or opinions?
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Donald Eastlake writes:
> While it is not exactly what I would want, I am satisfied with the
> changes below and consider my comments resolved.
Thanks Donald,
Cheers and happy new year!
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ie
Patrik Fältström writes:
> UTF-8 please!
Changed!
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
You're absolutely correct, of course, and I'm changing the error code
for those to be "NOERROR" instead. That means they're also a great
reason why we need extended information even for NOERROR.
--
Wes Hardaker
USC/ISI
___
DNSOP m
(was ASCII)
The authors know of no more outstanding issues. Time for LCv2?
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
aring the reports of the conversations.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Dick Franks writes:
> There is not yet a proper IANA allocated option code for this.
>
> Might I suggest that all interested parties settle on 65015 from the
> local/experimental block until the real thing arrives.
That seems reasonable.
--
Wes Hard
at I took away (people can and should correct me where I am wrong):
Thanks for the summary! Sounds like it was a good discussion.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ing (which is one of the features in LocalRoot)
2) How does it know where to mirror from? IE, many NS don't respond to
AXFR (only ~half do in the root zone). Is it just trying to pester them all?
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@
angerous, depending on the meaning of the bits. Imagine
if the new bit for some flipped software suddenly switched to "I trust
MD5, go ahead and believe MD5 DS records".
But maybe, and hopefully, I'm just misunderstanding how this will be
u
Dick Franks writes:
> As the man said, "[semantics are] determined by bi-lateral agreement".
> If the counter-party decides to do something different, it has repudiated the
> agreement.
Yes, and that's where I see a problem: when the software doesn't know
the agreem
g very different things because one side of the "agreement" is no
longer acting the same way.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Dick Franks writes:
> Non-performance by one party to the agreement will inevitably cause something
> to fail,
> which will be directly observable by the [singular] counter-party.
How can you guarantee that a fail is never turned into a misinterpretation?
--
Wes Hardake
se
load and not yield a fresh answer, RETRY=0.
Here is a problem that this code point is applicable to NOERROR as
well as NXDOMAIN answers so I'm not sure how to categorize it. This
reinforces my unanswered question why the draft proposes to copy RCODE
into EDE.
+ Result: Added two codes, one per RCODE, per discussion above.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
being consistent between all sites.
True, an extended error code could be added after the RFC is
published, through "Specification required" but 1) it is easier to do
it now 2) it gives to the people who will implement the RFC a wider
view of the possible uses.
+ Result: added
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
estaging, etc. This is not a fatal
> error.
[and Brian agreed elsewhere]
Thanks for your comments on the draft and this discussion. You can read
the results of this particular point in my response to Petr under bullet
6.4 in that message.
--
Wes Hardaker
USC/ISI
__
PS at all times, regardless of
where I am on the planet.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Eliot Lear writes:
> Hi Wes,
>
> On 22 Mar 2019, at 00:21, Wes Hardaker wrote:
>
> If DNS privacy is a goal,
>
> It is a goal. It is not the only goal. There is a tussle here. Let’s
> recognize that.
Sorry, I knew it was a goal... Just inserted wording to dr
providing rational for each of the potential
solutions. DNS plain clearly doesn't meet the first, but likely does
the second. But you fail to provide a goal that distinguishes why you'd
prefer DOT vs DOH to meet both these goals.
--
Wes Hardaker
USC/ISI
___
ve to chat at 6am. For the past year at least, the authors of the
serve-stale document keep forgetting that I'm not on th authors list for
it. They should probably just add me to resolve the problem :-)
See ya in 30.
--
Wes Hardaker
USC/ISI
___
DN
will likely ask for next, before it knows what to ask.
--
Wes Hardaker
Parsons
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
pposed to a grand parent).
--
Wes Hardaker
Parsons
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
the DO bit was set and you understand it but
need to return non-DNSSEC protected data, I think we should be returning
the DO bit but no AD or DNSSEC data.
I suppose you could argue that since we can't do DNSSEC we shouldn't say
we're DO (DNSSEC) compliant?
--
Wes Hardaker
Parsons
_
answers greater than 1220 bytes so ideally TCP MUST be
>available.
Changed to:
However, querying many zones will result in
answers greater than 1220 bytes so DNS over TCP MUST be
available.
--
Wes Hardaker
Parsons
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
use of MAY is not appropriate.
> Change to "can" or the like.
Good catch. Fixed.
--
Wes Hardaker
Parsons
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
the
> intelligence of the authors I can't see how this was thought of as
> passable and made it through WGLC irrespective of how we collectively
> view these devices.
Thanks Terry. I've removed those words that "someone" inserted. I
agree with the problem.
--
Wes Ha
nd 6.1.
I think the world is very much at a loss as to the best thing to do in
that case. And is likely very case specific. Military installations
tend to be a bit more strict about continuing through to a unacceptable
security certificate, eg. I'm not sure we can enumerate every context,
bove tests and aggregations to avoidance
> practices; however the document does not specify exactly how to do that."
> and later "Else return an useful error code" which will make
> interoperation (API portability) complex.
I need to speak to the author
possible it SHOULD log the event and/or SHOULD warn user. In
the case there is no user no reporting can be performed thus
the device MAY have a policy of action, like continue or
fail.
h
--
Wes Hardaker
Parsons
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
point. The question is, what to do about
that? Can we list a known one? Must we list a useless one instead?
Should we pre-declare the problem? I've been waiting for this to come
up :-)
> And on s3.1.14 Will "alltypes.res.dnssecready.org" be a stable query
> point?
I
The following draft, authored by Warren and I, might be of interest to
the dnsop crowd:
https://tools.ietf.org/html/draft-hardaker-rfc5011-security-considerations-00
[it currently does not have a home]
--
Wes Hardaker
Parsons
___
DNSOP mailing list
e these days. It's not the
content owner, as that's often separated from the security dude that
signs the content (as you well know). We need a suitable term for that
role generally. I particularly like a suggestion by thesaurus.com, and
sadly it's actually the better of many of
thank you!
(the draft is far from done, but catching those early is always a good thing)
--
Wes Hardaker
Parsons
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
se security implications if you can't self-derive the values. And
judging buy our survey of experts, I don't think the average Joe will
pick a safe value (hence the need for the document).
--
Wes Hardaker
Parsons
___
DNSOP mailing list
kes the DNSKEY rollover duration even longer, it is now
> secured against the outlined attack.
I don't think we need to modify 5011 itself. Just how to use it.
--
Wes Hardaker
Parsons
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
may be possible to replace
"test.example.com" in this document with
"test.dnssec-tools.org" when performing real-world
tests.
And then everywhere that test.dnssec-tools.org exists in the document,
I'll replace it with "test.example.com".
--
Wes Hardaker
Parsons
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
6
# rfcfind -n 4034 -m | grep validation | wc -l
2
But, no, 4033 defines terminology with the "validating" thingies.
--
Wes Hardaker
Parsons
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ve a policy of action, like continue or
fail.
new: Until middle boxes allow DNSSEC protected information to
traverse them consistently, software implementations may need
to offer this choice to let users pick the security level they
require.
It's not an easy
: what if there is no user? Why not recommend telling
> some network observatory? Aren't there some for DNSSEC?
There aren't any. We do mention logging the results in section 6 though.
--
Wes Hardaker
Parsons
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
quot; with something like "report an error
to the user"? I think that's better so am making that change.
--
Wes Hardaker
Parsons
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
es not exist."
That's well worded. Thanks for providing text, and I'll use it!
--
Wes Hardaker
Parsons
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Stephen Farrell writes:
>> I've changed the text to test for both. I think that's a good suggestion.
>
> Great thanks. Happy to clear when you post an update with
> that handled.
Here's the update URL (-05):
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnsse
ely the same week as IETF.)
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ime wandering around
random streets on Berlin and the 3/2 was a sudden aha (oh no) moment if
I recall.
Anyway, we'll revamp the document again in the near future with the
terms better spelled out, because I agree they need to be.
--
Wes Hardaker
USC/ISI
___
Bob Harold writes:
> Thanks for your work on this. Some minor formatting issues:
Odd. I think *someone* wasn't using a real editor (*cough*emacs*cough*)
and it inserted some odd white space into XML components.
Thanks for the catches; fixed on all accounts.
--
Wes Hardaker
Wes Hardaker writes:
> Sadly, we had a reason and now Warren and I have to remember it.
Fortunately, after a quick conversation we've recovered the reason.
Publishing a new version with a break-out explanation shortly. The 3/2
is absolutely is needed.
--
Wes Hardaker
Warren Kumari writes:
> On Thu, Feb 16, 2017 at 11:33 AM, Wes Hardaker wrote:
>> Bob Harold writes:
>>
>>> Thanks for your work on this. Some minor formatting issues:
>>
>> Odd. I think *someone* wasn't using a real editor (*cough*emacs*cough*)
>
201 - 300 of 384 matches
Mail list logo
