On Tue, Nov 05, 2024 at 02:09:44PM +, Steve Crocker wrote:
>Nick,
>Thanks. Even if the algorithm is just an encoding format, the same issue
>applies: It's important that creating new messages with that algorithm
>must stop well before the receivers stop being able to receive me
ld be best. I expect some resolvers might even prebuild their
responses so they can go out faster, so then you have to maintain more
state to shuffle at each layer.
btw: in general I think this does deserve a doc and adoption but
worry it will end up with rfc6919 section 2 or 4 language.
with less hops for MITM purposes of the actual transaction vs an
authority or someone MITM resolver <-> authority knowing more about the
query origin, and that's before one talks about all the extra state.
I've seen a few stupid DNS and routing tricks and like most
situ
TCP and the abandonment of backwards
compatability in other ecosystems really makes me wonder about the harm
from making it work vs going out and trying to address the problems.
It would be good for there to be a conversation with the IEEE
Liasons at least to think about the future.
> On Apr 3, 2023, at 4:50 PM, John Kristoff wrote:
>
> Interesting dilemmas. I'm not sure there are obvious answers. Perhaps
> lame delegation is the general concept, but specific failure modes need
> better characterization?
I suspect you could declare a definition such as
If queryall(autho
heir own way/transport/whatnot and therefore keep growing the methods
to get the same data.
But yes, as we increase the default answer size with additional
glue, signatures, validation, we should be following and sizing as
appropriate.
- Jared
--
Jared Mauch | pgp key available via
> On Jul 28, 2021, at 12:16 AM, John Levine wrote:
>
> OK, so I ask for foo.example and I get
>
> ; answer
> foo.example NS ns.bar.example
> ; additional
> ns.bar.example 2001:0DB8::000b::2
>
> Does it check that's the right value for ns.bar.example? How about with
> DNSSEC? I su
without placing it in some enterprise or other
lookup system. This helps prevent remote attacks and discoverability of
my devices and provides security this way.
- Jared
--
Jared Mauch | pgp key available via finger from ja...@puck.nether.net
clue++; | http://puck.nether.net/~jared/
gouh mutual peer
authentication to be of value, but can be broken with a persistent on-link or
on-path attacker.
I was also just providing examples of other protocols (dhcp, ra) that
share the same on-link risks.
- Jared
--
Jared Mauch | pgp key available via finger from ja...@puck.net
> On Oct 26, 2020, at 1:05 PM, Ted Lemon wrote:
>
> On Oct 26, 2020, at 12:59 PM, Toerless Eckert wrote:
>> The networks where i am worried are not home networks,
>> but something like an office park network, where supposedly each
>> tenant (company) should have gotten their disjoint L2 domain
> On Aug 8, 2020, at 12:33 AM, Paul Wouters wrote:
>
> That would require a new learning curve and in addition would be only
> describing 1 aspect of a primary server. It might work when you are
> talking about XFR, but would be very confusing otherwise.
We are fundamentally talking about cac
Exactly. Mandatory is required except when it's not. I'll think of some
improved text.
Sent from my iCar
> On Jul 22, 2020, at 10:09 PM, Mark Andrews wrote:
>
> mandatory is described thus:
>
> "In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the RR will
> not
> function c
..ZZ makes as much sense as anything else to be honest, virtually anything is
going to conflict with some acronym or name out there.
- Jared
> On Nov 21, 2019, at 2:18 AM, Alexander Mayrhofer
> wrote:
>
> Setting the basic issue aside (I'm still a bit torn) I agree with
> Warren that it would
On Fri, Mar 22, 2019 at 12:26:47PM -0700, Paul Vixie wrote:
>
>
> Jared Mauch wrote on 2019-03-22 11:59:
> > So my thoughts on this real quick: one of the reasons many people are
> > using centralized services like 8.8.8.8 (for example) is its complex
> > to run the
> On Mar 21, 2019, at 11:29 PM, Brian Dickson
> wrote:
>
> I realize, expressiveness adds complexity. However, it does avoid assumptions
> and overloading.
>
> The main criteria is agreement on client vs server (i.e. standardize this
> stuff), and possibly also add the network as another par
It’s also about DLP and other related topics. There is a deep well here we keep
tiptoeing around. Some things are mitigated by enterprise certificates and
others are far more tricky.
Doing this with DNS helps with that defense in depth. Removing that layer of
defense will increase risks on one
> On Mar 19, 2019, at 11:17 PM, Brian Dickson
> wrote:
>
>
>
> On Tue, Mar 19, 2019 at 6:42 PM Stephen Farrell
> wrote:
>
> Hiya,
>
> One individualistic data point on this sub-topic, and a real point:
>
> On 20/03/2019 01:13, Jared Mauch wrote
> On Mar 15, 2019, at 2:36 PM, Ted Hardie wrote:
>
> All of the work on encrypted DNS presumes that there is one or more parties
> who wishes to observe the flow of traffic to DNS resolvers for the purposes
> of surveillance. The conclusion of the IETF after IETF 88 was that there was
> a c
> On Mar 12, 2019, at 5:52 PM, Michael Sinatra wrote:
>
> [1] As an example, I am personally and practically opposed to inline TLS
> decryption in most enterprises. DoH gives further ammo for security
> folks to insist on inline TLS decryption, IMO. DoT, not as much, since
> the protocol can
> On Feb 13, 2019, at 4:14 PM, Paul Vixie wrote:
>
> no. they know exactly what they're doing, and it's not an accident. reporting
> it to their support team will waste their time and mine.
>
> however, i don't know yet whether they're ready to own their sh*t in public,
> or whether they'll
> On Dec 20, 2018, at 6:20 PM, Wes Hardaker wrote:
>
> 1.5 DONE encoding of the EXTRA-TEXT field
> ~
>
> In any case, I think the encoding of this field should be specified as
> either ASCII or UTF-8. I prefer UTF-8, because otherwise I won't be
> abl
> On Jun 29, 2018, at 12:38 PM, Paul Vixie wrote:
>
>
>
> Michael Sheldon wrote:
>> Breaking this out of the ANAME discussion, since it has wider use.
>>
>> I've been thinking on this one. If I was to create a record, I'd set
>> aside a byte or two at the beginning to denote family, but I'm
> On Jun 19, 2018, at 11:24 AM, Ray Bellis wrote:
>
> On 19/06/2018 15:43, tjw ietf wrote:
>
>> I find it personally appalling we can spend so many cycles injecting
>> dns into http but we can’t be bothered to fix what end users want.
>
> It's the HTTP folks that are putting most of those cyc
> On Jun 15, 2018, at 2:01 PM, Peter van Dijk
> wrote:
>
> Hello Andrew,
>
> On 15 Jun 2018, at 19:12, Andrew Sullivan wrote:
>
>> I believe that RRsets are unordered sets by definition. So I supect
>> that if people are relying on the order in which they come off the
>> wire, they're makin
> On Jun 15, 2018, at 11:45 AM, Erik Nygren wrote:
>
> A number of folks have been bitten by a bug in bind 9..12 where it silently
> changes the default sorting of rrsets to always be sorted (even if the
> authoritative response wasn't sorted). This causes problems for services
> assuming a
s=189357953
num.ednserr=307
num.udp=171926848
num.udp6=28159814
num.tcp=9107734
num.tcp6=164785
num.answer_wo_aa=703271
num.rxerr=0
num.txerr=6
num.raxfr=54
num.truncated=12595885
num.dropped=2592
zone.master=70
zone.slave=9350
--
Jared Mauch | pgp key available via finger from ja...@puck.nether
> On Dec 1, 2017, at 12:23 PM, Paul Hoffman wrote:
>
> On 1 Dec 2017, at 9:16, Ólafur Guðmundsson wrote:
>
>> We are getting into religion here, the original poster called people that
>> cap TTL's Heretics,
>
> Looking through the mail archives, no one other than you is using that term.
I th
> On Dec 1, 2017, at 11:38 AM, Ólafur Guðmundsson wrote:
>
>
> I strongly disagree with your "terminology", TTL is a hint about maximum
> caching period, not a demand or a contract.
> A resolver can at any time for any reason discard cached entries.
Agreed.
> Many Authoritative operators
see sending a secure notify
to anyone who requested the QNAME after change, but holding this state may
end up with complexity similar to what's some have seen with ECS.
- Jared
--
Jared Mauch | pgp key available via finger from ja...@puck.nether.net
clue++;
I support adoption of the document.
- Jared
> On Sep 5, 2017, at 3:25 PM, tjw ietf wrote:
>
> August is over and my self-imposed holiday is over, so it's time to get busy
> again. We have this document marked as a candidate for adoption.
>
> This starts a formal Call for Adoption for draft-
> On Aug 15, 2017, at 1:28 PM, Paul Vixie wrote:
>
>
>
> Jared Mauch wrote:
>>
>>> On Aug 15, 2017, at 3:25 AM, Mikael Abrahamsson
>>> wrote:
>>>
>>> What is the opinion of this wg on that topic?
>>
>> There has been
> On Aug 15, 2017, at 3:25 AM, Mikael Abrahamsson wrote:
>
> What is the opinion of this wg on that topic?
There has been much discussion about doing away with any/255 and I seem to
recall some discussion of a ANYA type which would return and A.
This is something I see value in being i
> On Mar 27, 2017, at 6:46 PM, Robert Edmonds wrote:
>
> Jared Mauch wrote:
>> IOn Mar 27, 2017, at 5:59 PM, P Vix wrote:
>>>
>>> I agree to review and comment. Note that I am provisionally negative to the
>>> idea itself, and my review may reflec
> On Mar 27, 2017, at 5:56 PM, Dave Lawrence wrote:
>
> Warren and I are hoping for WG adoption.
[clarification]
I support adoption when the chairs request it.
- Jared
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnso
IOn Mar 27, 2017, at 5:59 PM, P Vix wrote:
>
> I agree to review and comment. Note that I am provisionally negative to the
> idea itself, and my review may reflect that. Vixie
I will note there are other implementations out there as well, such as in
unbound. serve-expired configuration direc
break along the way.
I have my opinions about techical malpractice in this space and
have been guilty myself of it at times, but we can't let outdated
people hold back forward progress.
- Jared
--
Jared Mauch | pgp key availab
> On Feb 8, 2016, at 10:33 AM, Tony Finch wrote:
>
> Doing anything more determinate would require an extra loop over the data
> to choose, before the loop that builds the response. (Actually I can
> probably avoid two loops if I'm clever.) I didn't think I cared enough to
> do that. However som
> On Dec 28, 2015, at 2:30 PM, Paul Vixie wrote:
>
> i agree with this analysis.
>
> arguably, the moment we all agreed that DNSSEC's only purpose was to cause
> more resolution failures more often for more and new reasons, we ought to
> have said it can't be deployed and shouldn't be design
> On Dec 10, 2015, at 8:47 AM, Edward Lewis wrote:
>
> Jared,
>
> You've just made the naughty list for 2015.
>
> Santa
I know I’m permanently on that list since I was given coal as
a kid.
- Jared
___
DNSOP mailing list
DNSOP@ietf.org
https://www.i
> On Dec 9, 2015, at 3:25 PM, Hosnieh Rafiee wrote:
>
> Hi,
>
> Since DNS is a very important service on the internet, for several security
> processes, it can be used as a powerful system. So far, some resource
> records were proposed for certificates, keys and other values.
>
> I would like
> On Jun 8, 2015, at 3:11 PM, manning wrote:
>
> What do you think? Is there a reason to not do this?
DNS implementation details are much cleaner than others (e.g.: BGP) in finding
the root documents and all the additive parts.
In other words, I support pushing these out.
- Jared
_
ay as you were not here in person. It might help with the
context with what was discussed.
I will send you a link in private.
Jared Mauch
> On Mar 25, 2015, at 10:12 AM, Paul Vixie wrote:
>
>
>
> Jared Mauch wrote:
>>
>> You can read the jabber logs. Let me kn
You can read the jabber logs. Let me know if you need help finding them.
Jared Mauch
> On Mar 25, 2015, at 10:00 AM, Paul Vixie wrote:
>
>
>
>> Jared Mauch Wednesday, March 25,
>> 2015 7:56 AM
>> As mentioned in the wg yesterday an infor
> On Mar 25, 2015, at 10:16 AM, Paul Hoffman wrote:
>
> On Mar 25, 2015, at 7:42 AM, Jared Mauch wrote:
>> I have a minor nit for consideration: the examples should also include IPv6
>> loopback ::1 as well.
>
> Of what operational value is that? (This is a
As mentioned in the wg yesterday an informational document with current
behaviors may be helpful?
Jared Mauch
> On Mar 25, 2015, at 9:52 AM, Paul Vixie wrote:
>
> initiators have historically been able to assume that the responder would not
> close first. that's the operat
> On Mar 25, 2015, at 8:36 AM, Paul Hoffman wrote:
>
> Feel free to create such an infrastructure. After it is in place, we can
> update this document. In the meantime, this document describes a practice
> that many operators are already using quite successfully.
>
> --Paul Hoffman
I have a
> On Mar 10, 2015, at 8:05 PM, Paul Vixie wrote:
>
> we are, in this case, defining a protocol. our goal is to get the client to
> stop asking the ANY question. if we send is a signal that sounds right
> (REFUSED, for example) but merely has the effect of "go to next server" then
> we're losi
ht now that should collect some data
and help better study the behavior of systems. once it's ready, I will share
more data. If you are a researcher or PHD candidate interested in DNS,
please contact me off-list.
- jared
--
Jared Mauch | pgp key available via fin
> On Mar 9, 2015, at 11:16 AM, Edward Lewis wrote:
>
> On 3/9/15, 7:08, "D. J. Bernstein" wrote:
>
>> The common theme of CNAME/MX/A and A/ is that there's widepread
>> interest in being able to easily retrieve multiple record types. What
>> I'm saying is not that query type ANY is the ult
> On Mar 9, 2015, at 10:54 AM, Tony Finch wrote:
>
> D. J. Bernstein wrote:
>
>> My "qmail" software is very widely deployed (on roughly 1 million SMTP
>> server IP addresses) and, by default, relies upon ANY queries in a way
>> that is guaranteed to work by the mandatory DNS standards.
>
> T
50 matches
Mail list logo
