[DNSOP] Re: Lifecyle and deprecation of draft-buraglio-deprecate7050
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 messages in >that format. >The point of the proposed life cycle model is that doing this smoothly >takes multiple steps, not just one. After signalling to the community >that an algorithm, encoding choice, etc. needs to be phased out, there >needs to be some way to determine when usage has tailed off before >removing the functionality for processing such messages is removed from >the receiving systems. My big concern when it comes to these things is losing access to historical systems that perhaps don't support something more modern. My iPhone1 (for example) still can connect to wifi etc but may not do TLSv1.3, so even if I'm looking up the location of something that the privacy folks would agree isn't sensitive, I still can't access that, let alone use some of this historical software which may still work fine. I worry about not getting the badly behaving software out of the core is a problem, but I also worry about if we can or should provide an interop translation layer. I see a lot of what is going on to be related or similar to that. - Jared ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: New draft: DNS Servers MUST Shuffle Answers
On Tue, Nov 05, 2024 at 09:15:15PM +0800, Mukund Sivaraman wrote:
> Hi Shane
>
> On Tue, Nov 05, 2024 at 11:56:37AM +, Shane Kerr wrote:
> > Dear dnsop,
> >
> > I wrote a quick draft to specify that answers returned should be returned in
> > a random order:
> >
> > https://datatracker.ietf.org/doc/draft-kerr-everybodys-shuffling/
> >
> > This comes out of recent experience we had where a customer saw significant
> > bias in how their servers were used until we randomized the order where
> > returned our answers. I confirmed that in many cases neither authority
> > servers nor recursive resolvers shuffle the answers; customer reports
> > indicate that the actual clients just use the first answer returned.
>
> As you are aware, this is an old problem and a config option was added
> in DNS implementations for RRset ordering (random, cyclic, etc.).
>
> The problem is in applications that use data such as address RRsets in
> the order that they're given to them. It may be best to suggest
> strongest action closest to the application layer, e.g., in the
> application itself or in stub resolvers ->
> getaddrinfo(). Random-ordering (specified as MUST in this draft) in
> responses from the resolver can be reordered up the stack and have no
> effect. For example, does POSIX require that addresses returned by
> getaddrinfo() not be reordered from how they were received by a stub
> resolver?
And when there's some other software meddling in the middle, eg:
VPN, systemd (ick), nscd
> If a customer faces a problem due to ordering, it's easier said than
> done to change applications. Perhaps by default stub resolvers can
> randomize. E.g., does glibc already randomize by default (and why not if
> it is a good idea)? I see no mention of RR ordering in resolv.conf's
> manpage. I wonder if there would be any side effects due to that.
This sounds like a change towards the stub or in the OS/stub
would 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.
- jared
--
Jared Mauch | pgp key available via finger from ja...@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Side Meeting - DNS Load Balancing
On Mon, Jul 01, 2024 at 11:49:10AM +0800, Davey Song wrote: >People add tricks to DNS when DNS does not fit their needs. However, my >customers complained about the difficulties of deploying their DNS on >multiple platforms with different DNS tricks (GeoDNS for example) or >switching from one another. >I agree with Joe. DNS is a layer of indirection. If one indirection can >not solve the problem in a good manner, another indirection is needed. If >we do it in resolver like Paul suggest, another indirection protocol >should be introduced. You can name it anything other than "DNS"... > > > Names as a layer of indirection between applications and addresses > represent dynamic data by design, and the idea that the manner by which > that data can be managed must be rigidly constrained seems unnecessary > and a bit out of touch with reality. > > >Davey I'm not sure which is worse, morphing DNS answers or TTL=0 that i've seen in the past as well from different systems. As anyone that has done anycast knows, it works but also has numerous corner cases to mitigiate. So do other "stupid dns tricks". I understand why folks don't want to accept/pass ECS along, but the interesting thing is that privacy tradeoff isn't necessarily what they think it is, they may be missing out on a more localized answer 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 situations, nobodys hands are quite clean :-) - jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt
On Fri, Jul 05, 2024 at 02:14:19PM +0200, Petr Špaček wrote:
> On 05. 07. 24 12:50, Nick Hilliard wrote:
> > Philip Homburg wrote on 05/07/2024 11:01:
> > > Can we go back to reality? There is no PMTU discovery for DNS replies
> > > over UDP that works at scale. It doesn't work, it never worked.
> >
> > specifically, short of implementing end-to-end circuits, it can't work
> > reliably. There is no way for an endpoint to detect intermediate
> > topology changes between itself and another endpoint, short of heuristic
> > and/or post-hoc interpretation of what's going on in the data plane.
>
> I understand why Paul Vixie does not like 1400 set in stone.
There's a lot of hidden legacy inside IP around the various
frame sizes from FDDI, POS/SDH and this current layer driven out of IEEE
that many of us are familar with.
> Having said that I think it's in fact _not_ set in stone because the text
> says RECOMMENDED.
Yes, my concern is we slowly end up on the rfc6919 slope.
> My interpretation is that it means "if you don't know any better use 1400",
> but RECOMMENDED is more concise.
There is overall guidance missing in the IETF around how to
handle this, and we're watching portions play out again and again, be it
around nameservers, transports and here with MTU where we are more
strictly defining these beavhiors. If I see NDP with MTU of a future
value, what should my application use? Should each application have
it's own system for clamping this?
https://datatracker.ietf.org/doc/html/rfc4861#section-4.6.4
We continue to have a problem whereby we know the problem exists
and keep shifting it, so now it's not a firewall problem anymore, it's a
UDP problem or Protocol/application over UDP problem (ie: QUIC).
There's likely no easy way for an application to know what the expected
MTU is for a given destinaton even if it's discoverable via EOPNOTSUPP
errno.h
MSS clamping for 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.
- Jared
--
Jared Mauch | pgp key available via finger from ja...@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
Re: [DNSOP] Meaning of lame delegation
> 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(authorities(QNAME)).aa != 1: Lame = True Else: Lame = False Perhaps with the referral/loop detection logic also embedded. Seems pretty clear to me, but that’s just my historical thoughts and view. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt
On Thu, Jul 29, 2021 at 11:45:28AM +1000, Geoff Huston wrote: > > > > On 29 Jul 2021, at 10:33 am, Mark Delany wrote: > > > > On 29Jul21, Geoff Huston allegedly wrote: > > > >> For me it appears to depend on the actions of the resolver as to whether > >> this would be faster > >> or not. If all resolvers blindly re-query using TCP for all UDP responses > >> where TC=1 is seen in > > > > I'm not sure I follow this bit. Are you merely implying that the resolver > > should first > > consider a larger edns0 bufsize before resorting to TCP? > > Seems that the DNS Flag Day 2020 precluded that option, so I don’t think its > available. I think we should simplify the number of ways we do something, be it edns0 or tcp. We are seeing the difference in everyone wanting their 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 finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt
> 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 suppose > > I still don't see the benefit of trying to make some loops work when we know > that we > can't make cross-zone loops work. I think this is honestly a bit about, should we make the computers more strict (and possibly more secure) vs more likely to workaround something that is mostly-broken. Much of the flag day activities were about reducing cruft around workarounds for older code out there. I don’t like breaking existing stuff but am leaning towards John in that if people are putting semi-broken glue out there, the operator should fix their NS config. We have been explicitly driving up DNS queries (eg: QNAME minimization for longer zones, like ip6.arpa) for the sake of privacy and reduced performance as a result. I think breaking a few people who have poorly configured systems isn’t the end of the world, they will eventually fix their NS records. Also, trying to define relationships without knowing where the zone cuts may exist in a domain is interesting for terminology but not something I believe goes in this work. I think calling out that it’s possible people will create situations where a name won’t resolve, is similar to what happens with routing that isn’t deterministic as well. We should be defining how to determinsticly resolve a name and highlight that it’s flexible enough you can configure it so it won’t work. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP: question about hardening "something like mDNS" against attacks
On Mon, Oct 26, 2020 at 04:39:10PM -0400, Ted Lemon wrote: > What actually hardens mDNS is that it’s a link-local protocol. > It doesn’t work across links. This limits the attack surface. Exactly. > But there’s no way to eliminate the attack surface. If I were in Ben’s > shoes, > I’d be asking you to change the protocol to support authentication and > ToFU as a hardening strategy, with some better trust establishment mechanism > as future work based on the existing presence of crypto signatures. But > the current consensus of the IETF is apparently that ADs aren’t allowed to > insist on things like that. :( We must also consider that mDNS is meant to provide that on-link communication for devices that are perhaps not professionally managed, such as my home where I may want to talk to raspberrypi.local or my printer or other on-link device 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/ My statements are only mine. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP: question about hardening "something like mDNS" against attacks
On Mon, Oct 26, 2020 at 06:42:21PM +0100, Toerless Eckert wrote: > Thanks, Jared > > Somehow everybody tries to escape answering the question asked by giving > their correct but orthogonal pet problem space answer. Ted correctly claims > the protocols suck security wise, and you correctly claim that there are a > lot more > deployment considerations in face of risky underlays. > > At this point in time i am just trying to get an RFC out the door, and Bens > security review was asking for options how to operationalize the choosen > protocol > to be hardened. My answer was the heuristic. > > If the anwer of the experts is "do not harden implementations of existing > protocols", > but only improve protocols or eliminate security risks from underlays, i think > that is not a good strategy to show to implementors trying to understand how > to best harden existing protocols, but i will happily take that guidance > and remove the text about the suggested heuristics. I think we often forget several things about the security aspects of devices, like physical access == root (for example), on-link or on-network attackers will always have an advantage available to them. Things like mDNS are only as secure as their local link, and if an attacker is on-link there are risks that can be controlled for and those that can't. We have had problems elsewhere as md5/tcp-md5 provide engouh 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.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP: question about hardening "something like mDNS" against attacks
> 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 domains, ... and then >> they didn't. And one of the tenants has a "funny" network engineer/hacker. > > That’s pretty clearly the thing to fix. > There’s plenty of bad engineering out there, but when on a shared lan without client isolation enabled (Eg: wireless) many bad things can be done. I think explaining that the threat domain is the layer-2 and that administrators should consider what services are available, eg: do you accept dhcp server on the network, what devices are permitted to send RA’s etc all become part of the question.. Much of this is just operational guidance in how to run a good network which prevents these types of bad behaviors and consequences from exceeding their blast radius. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Question regarding RFC 8499
> 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 caching of the content. In the squid or CDN cases this would be parent/child, but the child is a versioned clone :-) It may be worthwhile to look at the replicated data techniques amongst other protocols and services with an open mind if the WG is still thinking about the terminology. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS
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 correctly for clients that ignore this SvcParamKey. Each SVCB
> protocol
> mapping SHOULD specify a set of keys that are "automatically mandatory", i.e.
> mandatory if they are present in an RR. The SvcParamKey "mandatory" is used
> to
> indicate any mandatory keys for this RR, in addition to any automatically
> mandatory keys that are present.
>
> A ServiceMode RR is considered "compatible" with a client if the client
> implements
> support for all its mandatory keys. If the SVCB RRSet contains no compatible
> RRs,
> the client will generally act as if the RRSet is empty.
>
> In presentation format, "mandatory" contains a list of one or more valid
> SvcParamKeys,
> either by their registered name or in the unknown-key format
> ({{presentation}}). Keys
> MAY appear in any order, but MUST NOT appear more than once. Any listed keys
> MUST also
> appear in the SvcParams. To enable simpler parsing, this SvcParam MUST NOT
> contain
> escape sequences.
>
> For example, the following is a valid list of SvcParams:
>
> echconfig=... key65333=ex1 key65444=ex2 mandatory=key65444,echconfig
>
> In wire format, the keys are represented by their numeric values in network
> byte order,
> concatenated in ascending order.
>
> This SvcParamKey is always automatically mandatory, and MUST NOT appear in
> its own
> value list. Other automatically mandatory keys SHOULD NOT appear in the list
> either.
> (Including them wastes space and otherwise has no effect.)”
>
> I don’t see how, after reading that, one can conclude that all ServiceMode
> records
> MUST include the key “mandatory”.
>
> Mark
>
>> On 23 Jul 2020, at 11:47, Wellington, Brian wrote:
>>
>> If your interpretation of this comes down to “mandatory is optional”, then
>> that shows how confusing this is.
>>
>> Brian
>>
On Jul 22, 2020, at 6:45 PM, Mark Andrews wrote:
>>>
>>> This is a case of reading a sentence out of context.
>>>
>>> The first paragraph describing “mandatory” ends with:
>>>
>>> The SvcParamKey "mandatory" is used to indicate any mandatory keys for this
>>> RR, in addition to any automatically mandatory keys that are present.
>>>
>>> It also has:
>>>
>>> In presentation format, "mandatory" contains a list of one or more valid
>>> SvcParamKeys,
>>>
>>> I think there is already plenty of context to show that mandatory is
>>> optional.
>>>
On 23 Jul 2020, at 11:31, Tim Wicinski wrote:
Brian
I agree on clarity, and their git repo has been more recently updated.
I've been poking the authors on some better examples in the spec as well.
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_MikeBishop_dns-2Dalt-2Dsvc&d=DwIFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bPfM-kVBGNE2d_r6kVQw1V-urTv21fSHLYeFhReKf5w&m=KbZDXTLvNOxENtFWCMdggAhJaRvABzLIoje-QspoFCM&s=NAnMW9xGWQVnYnS9I88YowKyWxHMrEM3ACuElx9IB5Y&e=
On Wed, Jul 22, 2020 at 9:20 PM Wellington, Brian
wrote:
ok. So, what this means is that keys listed in the “mandatory” parameter
must be included as parameters, and are required to be understood by
clients. The set of “automatically mandatory” keys are required to be
understood by clients, but are not required in the RR.
I’m a native English speaker, and have been working with DNS for over 20
years. If I’m having trouble understanding this, perhaps the spec should
be a bit clearer.
Brian
> On Jul 22, 2020, at 5:56 PM, Tommy Pauly
> wrote:
>
>
>
>> On Jul 22, 2020, at 5:46 PM, Wellington, Brian
>> wrote:
>>
>> I attempted to start implementing support for SVCB and HTTPS, and
>> discovered that the data being served by Cloudflare does not conform to
>> the current spec.
>>
>> Assuming my decoder is correct, the response below decodes to:
>>
>> 1 . alpn=h3-29,h3-28,h3-27,h2 echconfig=aBIaLmgSGy4=
>> ipv6hint=2606:4700::6812:1a2e,2606:4700::6812:1b2e
>>
>> and does not include a “mandatory” parameter. But section 6.5 of
>> draft-ietf-dnsop-svcb-https, which is talking about the “mandatory” key,
>> says:
>>
>> This SvcParamKey is always automatically mandatory,
>>
>> which implies that there MUST be a “mandatory” parameter. Is this an
>> oversight in the Cloudflare implementation, or is the Cloudflare
>> implementation not implementing the current version?
>
> The Cloudflare record does conform correctly.
>
> The “mandatory” key does NOT need to be included. "automatically
> mandatory” keys do not need to be included. Mandatory just indic
Re: [DNSOP] On .ZZ
..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 need a string that has a meaning. > > ..ZZ would remind me of long beards and loud motorcycles for the rest > of my life.. https://de.wikipedia.org/wiki/ZZ_Top > > best, > Alex > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
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 these servers properly. > > i think those optics are the motive, as you say. > > however, it is not complex, as you also say. > > the optics have been encouraged. > > they are misleading. I think for you and I it's less complex. When I discuss things with smaller ISPs running DNS isn't even on their list of things anymore, similar to e-mail and other things where to run the service requires some scale. I've seen some quite large providers be unable to configure some simple DNS settings properly. You have to also look no further than the research that Mark Andrews and others have done about standards compliance. I don't think it's as hard as it could be, but it's not as easy either. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
> 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 party involved (for > upstream transit ISP vs local ISP), if they have differing policies for > allowing offsite/third-party DoH or DoT. 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 these servers properly. I’m worried about this additional complexity breaking the camels back, or deployment being relegated to those of us that may have overly complex home networks. The options and matrix add in complexity when a simple approach is likely desired or needed. The small networks that do not run their own servers won’t change. The medium where it’s on the bubble will further centralize. Is this what is needed in the community? - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
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 side while decreasing them on the other. You also have a hard time telling employees why you have a MITM box and it reduces your talent pool. People here may not worry about it but the insurance carriers for the businesses do. Sent from my iCar > On Mar 20, 2019, at 4:08 PM, Matthew Pounsett wrote: > > I can't afford to probe every IP address on the planet on a regular basis, > and dynamically modify my blocking based on that. It's far, far less > expensive to just automatically MitM all web traffic on my network, even > though that is far more expensive than what I have to do today. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
> 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:
> > My impression is there are people who will not be satisfied until all
> > traffic looks
> > identical and you have zero way to protect your home,
>
> I do not claim that everyone ought do the same, but I absolutely
> do claim that encouraging voluntary policy adherence by dealing
> with the people using the n/w is preferable to many egregiously
> invasive attempts to force technical policy enforcement on
> unwilling serf-like users.
>
> So, this is the problem:
> - If a network operator has any policy that is enforceable, ONLY the
> technical policy enforcement model scales.
> - In such an environment, there are only, ever, "willing users", because, in
> order to use the network, they are required to agree to the policies.
>
> This makes the argument you have above, a vacuously defined one.
> You want to encourage voluntary policy adherence for a non-existent set of
> otherwise unwilling users.
>
> I understand your position: you would prefer that {some,all} networks were
> not employing policies that {you,some people} disagree with.
> I sympathize, but I disagree. What we need are mechanisms that scale.
> My position (personally) is that we find ways to have scalable, technical
> mechanisms.
> They should allow users (or machine administrators) to be as compliant as
> they are willing, and no more.
> They should allow networks to enforce their policies, while treading as
> lightly as possible.
> It should be possible to use technical means to handle this negotiation with
> little to no user input required.
> The analogy is roughly that of escalation-of-force in law enforcement,
> starting at a level of "polite requests".
>
> You can disagree, but I implore you: please don't stand in the way of those
> wanting to find consensus on scalable, flexible, technical solutions that
> encompass a wide range of network policies and enforcement needs.
>
> The main point is, I believe the end result will be mechanisms that allow you
> to deploy networks that meet your needs, and software that you can configure
> to bypass such controls, but that neither of those should ever be the default
> configurations.
>
> If the results allow you to do what you want/need, and also allow others to
> do what they want/need, everyone should be happy enough with the result.
>
> Can we at least agree on this as a desired goal for this work?
Often as an industry we may discuss various solutions that are great for
oneself but don’t scale when looking at the big picture. I’m of the feeling
that not everything should be a standard, even things that look like they might
be standard-ish. I could encode many things over TCP over TLS over QUIC over
HTTP. I’ve seen unencoded data stored in DNS TXT records that have
sorted/ordered information so you can do interesting things.
Just because one can do these things doesn’t mean one should, or that the
entirety of the industry should (or even will).
Goals and motivations are key here, if the goal is to make it such that
dissidents whose lives may be threatened (this is an example a co-worker always
uses on me in these types of conversations to support their position) by the
local regime may face a threatening situation or die as a result of using
technology, it’s not the fault of the protocol. Should we improve for every
corner case like this? As vixie has pointed it, it may be an innocuous device
like a chromecast where the ISP provided DNS is horrible. (I can think of many
bad devices in the consumer space that break the DNS spec in really unique
ways). It’s entirely possible that the appliance works best when not using
that ISP service, but it is also data leakage to a large global company that
for reasonable or unreasonable purposes he doesn’t want to transact with.
When we create technologies that can bypass and traverse the existing security
posture of networks (evil foreign telecoms, where’s my pitchfork) or a coffee
shop, library, home or large enterprise… expect the work to be held to a higher
standard.
It may be that there’s not consensus on this topic. It may be I’m an outlier
and have been subverted by , but the most
likely case is there be dragons here and we should tread carefully to not burn
down the entire place.
- Jared
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
> 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 class of that, pervasive public surveillance, that was so damaging to the > trust of the users in the Internet that it amounted to an attack on the value > of the Internet as a whole. The plenary where that was discussed is online > here: IETF 88 Technical Plenary: Hardening The Internet - YouTube . In a path > with multiple links, in other words, we have a condition where we believe > there is likely to be an attacker on one or more of those links that would > like to see this data and to use it for purposes not approved by the user or > the operator of the service to which the user is directing her flows (or any > of the network operators through which the flow passes). > > The response to that has been first to encrypt the flows which carry the user > data. That's not an effort championed not only by the IETF or the IAB; see > the US Government's HTTPS Only standard for one example of the many other > efforts going on to make that the case. In addition to that primary effort, > there have been efforts to reduce the amount of metadata about the flows. > Some of that has been in updating transport protocols (e.g. QUIC, TCPINC) to > reduce their disclosure of state. Some of it has been in reducing the data > revealed by the handshake (e.g. the updates in TLS 1.3 and eSNI). And some > of it has been to reduce the data disclosed across those links by the use of > the DNS. That's the point of DNS over TLS and DNS over DTLS; it's also the > point of DNS over HTTPS: to protect the data in those flows from a known, > pervasive attacker. > > You would like your use of similar surveillance techniques to be > differentiated from their use by that set of attackers. The IETF cannot do > that on moral grounds, much as we might like you and appreciate your desire > to protect your network and your children. We need technical mechanisms. If > you review the discussion to date, you'll see a number of such mechanisms > proposed. They fall into two broad classes: trusting the local network > infrastructure and trusting the local configuration. > Once you make all traffic look the same, expect it to be treated the same as possibly malicious by network operators. Do you know why software has options like avoid-v4-udp-ports as a config directive? Expect that to happen regardless of where you move the transport to. I’m writing this from my own machine that I own, purchased and paid for with my own $$. If you’re writing from a corporate owned machine, or reading on a corporate owned machine they likely have their own rules for them. I believe in the open internet, but I also don’t believe in the absolutes people see this in. You aren’t entitled to all communication in the world. The IETF can try to carve out a moral high ground that you are referring to. It may be sound footing, but if you’re in a place where a DNS query for example.com is problematic, one of the solutions is to NOT look up example.com. It may not be “right” in your mind, but it is a way to prevent being jailed or otherwise which we may both morally agree is the wrong outcome but those other locations that made example.com bad may not care and no writing to/in an IETF WG will change that a single bit. That change lives outside the IETF WG process. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
> 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 be easily identified on the wire and any necessary > actions taken. Manipulating DoT transactions is a far cry from > manipulating/decrypting all TLS... My impression is there are people who will not be satisfied until all traffic looks identical and you have zero way to protect your home, enterprise or similar. (The lack of protection is a side-effect, not a design criteria of making it harder to detect variation in endpoint behavior) I don’t support efforts to offer standards that make everything look the same when they are not the same. Next someone is going to show up in IDR saying how we must TLS all the routing data because reasons. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my chromecast ultra would not start until i began answering 8.8.8.8
> 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 enjoy being named and shamed. so, here i am. And ours as well. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-03.txt
> 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 > able to send back 🤯 emoji in error messages (and the authors won't be > able to use the 🍄 emoji that they clearly want). > > + Resolution: we're proposing ASCII to keep the protocol simple and to >match TXT records. These are not intended to be end user messages >but rather administrative hints for operators. > > + resulting text: > >A variable length, ASCII encoded, EXTRA-TEXT field holding >additional textual information. It may be zero length when no >additional textual information is included. > We went through some of this in IDR about routing protocols and how to leave a partner device a message. UTF-8 is the supported method. 7-bit ASCII lacks language support. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Creating a query/record for A and AAAA
> 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 just >> paranoid and OCD that way. > > that seems like the long way around. > > for QTYPE=A, add as a desired additional data type. > > for QTYPE=, add A as a desired additional data type. > > advantages: > > no fork-lifts. incremental. opportunistic. no protocol changes. start today. > > any server which does it will give better time-to-first-ad benchmarks, and > will therefore outcompete any server who doesn't do it in all bakeoffs. > I guess this depends on how the vendors implement the various minimal response bits. I’ve turned this on because in ye olden days (I think it was the 2nd half of the 90s) you could poison a cache by dumping in additional data, sometimes even out of the zone additional and cause this trouble. This is also documented as a performance gain, either due to less time packing the response or other wins. As a longtime ANY (ab)user, I welcome an approach where we get + A at the same time. This can be done by just returning the additional but it really depends on if the clients or stubs will use it. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
> 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 cycles into DNS into > HTTP. > > It's also their intransigence re: SRV which has caused the CNAME at the > Apex issue. CNAME was *never* the right answer for doing application > level indirection in HTTP space. Throw some shade at SMTP as well, if I send mail to ja...@cname.nether.net and that pointed to @nether.net it would end up as @nether.net in the messages :-) Part of it is just the human nature of how we debug things. I can speak HTTP because it was easy to type telnet localhost 80. These days I have to do the same thing but with openssl s_client etc.. If these methods to debug weren’t so hard, it would have gone much further to helping. Developers/users want easy debugging steps and what we give them is things like the ednscomp tool, which is technically awesome but not very user friendly. Instead of doing a dig on the port test tool, it’s much easier to visit https://cmdns.dev.dns-oarc.net/ instead. I also may not have dig on my phone.. (ok, well I do). I think a lot can be learned from how Apple (as an example) made simpler APIs to do connections vs doing gethostbyname()^wgetaddrinfo(). It makes it easier to build tools if you don’t have to learn how to do all these things. I really like Unix, the simplicity of many calls in C, but sometimes hiding the internal layers is what’s needed. This is why https://developer.apple.com/documentation/foundation/nsurlconnection?changes=_2 is a thing. This is why folks are doing what tjw says, “meh, go to route53 because it does what I expect”. This doesn’t mean the internals aren’t important, but many application developers and end-users can’t be expected to know/care about how a CNAME at apex differs from an A record w/ redirector. One thing that SMTP got right was MX records, so it’s easier to say “go over here”. While I’m sure someone will say that HTTP should have it’s own (eg: SRV) but the barn door is still open, etc.. - jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)
> 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 making a mistake. > > This. One hundred million times, this. Yes, so because they’re unordered, they could also be ordered, and that should be seen as a version of unordered vs strictly ordered. Just because the last 10m times I asked it came in the same order doesn’t mean that for 10m+1 it will be or should be. I’m reminded of some large content providers telling me how they routed their ICMP bits differently than their non-ICMP because they had dedicated hosts to just respond to the ICMP requests of www.example.com folks used as a measurement point to see if their connectivity was working :-) - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)
> 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 at least some degree of round-robin behavior by clients as now many > clients would sent all traffic to only the lowest IP. Bug details: > https://gitlab.isc.org/isc-projects/bind9/issues/336 If you are upgrading > to or have upgraded to bind 9.12 you likely want to take a fix or override in > config. > > > This raises the question of whether there would be value in a more modern BCP > covering round-robin expectations for recursive resolvers? I suspect many > (most?) service operators take at least some degree of DNS round-robin > behavior by recursive resolvers as a default. > > I suspect starting assumptions are roughly in the range of: > > * Recursive (and stub?) resolvers (SHOULD/MUST?) do some form of round-robin > in RRset responses. Stub is in your desktop (and possible application, but may vary depending on OS, etc). > * There are a variety of ways to implement round-robin (randomize, permute, > etc). Sure, but services should also be sufficiently robust should there be some amount of polarization in the hash algorithm. I recall when the entropy went into bind4 to assist with balancing of some web services as well as mail/ftp stuff. Perhaps this is something that could be done better with a flavor of happy-eyeballs in the client application, whereby you race not just v4 vs v6 but also some limited subset of answers the application gets back as part of getaddrinfo() > * Server operators need to be aware that round-robin may be a part of a load > balancing scheme (especially if capacity is far greater than average demand) > but should not be relied on exclusively. (Perhaps with examples of why...) > > Am I missing something in-terms of an existing BCP to this effect? There's > RFC 1794, but I couldn't find much else (but given the sheer number of DNS > RFCs it's very likely I missed one). Have you checked the DNS Camel :-) https://powerdns.org/dns-camel/ I didn’t find anything else looking real quick, and it gave me a reminder of some of the folks that I used to interact with at ANS back in the day, so at least for a Friday it’s a fun and quick re-read to hit up 1794. - Jared > > Best, Erik > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
On Fri, Mar 23, 2018 at 06:32:07PM +, Ondřej Surý wrote: > What’s so wrong of using TYPExxx for these if you absolutely need them to run > the ancient technology while at the same time running the latest version of > BIND (or your favorite DNS server)? > > Your argument feels like strawman to me. And I am not the one sitting on a > pile of passive DNS data, so I can’t pull the numbers... > > We are not taking the ability to put random TYPEnnn records into the zone, we > are just saying the tools just won’t understand them anymore. Again nothing > is going to break on the day one. Ondrej, I think the issue here is just because it's not commonly seen on the public internet, doesn't mean it's not used. We don't use DHCP to configure p2p links on routers, this doesn't mean that DHCP can go away, it's used elsewhere. I think what Paul is trying to point out is the same thing, some enterprises may still be using it internally. Just because we don't use the RR type in isc.org, nether.net, akamai.com doesn't mean nobody is using it for their internal networks. We should attempt to determine who may be using it. This can be done by logging or a survey of folks doing slave zones, etc. isc/bind can and perhaps should implement logging for these rrtypes that say they may be going away so folks can see the impact. ISC/bind also have a history of doing this with the warn & fail directives in the named.conf file, which would be a great way to expose these types of items. check-old-rrtype (warn|fail|ignore) or something similar would be useful to an actual operator. here's some data on rrtypes seen in my nameserver. - Jared server0.queries=109159256 server1.queries=100199925 num.queries=209359181 num.type.TYPE0=27 num.type.A=98905962 num.type.NS=3428038 num.type.MD=0 num.type.MF=0 num.type.CNAME=949771 num.type.SOA=807788 num.type.MB=0 num.type.MG=0 num.type.MR=0 num.type.NULL=28 num.type.WKS=0 num.type.PTR=8847792 num.type.HINFO=1178 num.type.MINFO=0 num.type.MX=4110956 num.type.TXT=1164968 num.type.RP=0 num.type.AFSDB=2018 num.type.X25=0 num.type.ISDN=0 num.type.RT=0 num.type.NSAP=0 num.type.SIG=0 num.type.KEY=0 num.type.PX=0 num.type.=64526576 num.type.LOC=2288 num.type.NXT=780 num.type.TYPE31=108 num.type.SRV=2194823 num.type.NAPTR=18707 num.type.KX=0 num.type.CERT=6 num.type.TYPE38=238830 num.type.DNAME=9 num.type.OPT=0 num.type.APL=0 num.type.DS=177999 num.type.SSHFP=4846 num.type.IPSECKEY=0 num.type.RRSIG=20178 num.type.NSEC=281 num.type.DNSKEY=2261055 num.type.DHCID=0 num.type.NSEC3=0 num.type.NSEC3PARAM=2596 num.type.TLSA=22176 num.type.TYPE53=8 num.type.CDS=2267 num.type.CDNSKEY=2027 num.type.OPENPGPKEY=0 num.type.CSYNC=0 num.type.TYPE65=2 num.type.TYPE92=9 num.type.SPF=109981 num.type.NID=0 num.type.L32=0 num.type.L64=0 num.type.LP=0 num.type.EUI48=0 num.type.EUI64=0 num.type.TYPE127=5 num.type.TYPE143=1 num.type.TYPE165=1 num.type.TYPE191=335 num.type.TYPE222=3 num.type.TYPE223=27 num.type.TYPE239=29 num.type.TYPE240=2 num.type.TYPE243=2 num.type.TYPE246=1 num.type.TYPE247=41 num.type.TYPE251=26458 num.type.TYPE252=3312 num.type.TYPE253=42 num.type.TYPE254=29 num.type.TYPE255=21357118 num.opcode.QUERY=209248548 num.opcode.NOTIFY=80330 num.class.IN=209324746 num.class.CH=4132 num.rcode.NOERROR=138257521 num.rcode.FORMERR=417 num.rcode.SERVFAIL=132820 num.rcode.NXDOMAIN=25011450 num.rcode.NOTIMP=56046 num.rcode.REFUSED=36625841 num.rcode.YXDOMAIN=0 num.rcode.NOTAUTH=4 num.edns=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.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Measuring DNS TTL clamping in the wild
> 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 think this is subject to interpretation, some people view the done differently. The subject line felt hostile.. 2nd attempt to adjust subject-line to make it less hostile. - jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Measuring DNS TTL clamping in the wild
> 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 have "unreasonable" TTL's like less than 10 > seconds or multiple days and I see no reason why resolvers do not > apply minimal and/or max caching rules that are reasonable. Yes, I remember a load balancer from the last century that had serious issues with DNS requests with low TTLs. We ended up replacing it. TTL is certainly a MAX, but no reason you can’t return a shorter value. My stub resolver may see a lower number if an item is about to be evicted from cache, should we not see that? Clamping the max seems helpful and causes the least enduser harm, so is quite wise. The same would be true hitting a large anycast dns server like 75.75.75.75 or 8.8.8.8, 4.2.2.1, you may hit a different backend for whatever reason so see varying TTLs for the same query within a 10 second interval based on that. That’s not bad, it’s working as designed. I think measurements are interesting though, so identifying TTL clamping in the wild would be an interesting study. - jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale
On Thu, Sep 07, 2017 at 01:29:47PM -0700, Paul Vixie wrote: > if the draft being considered was clear on two points, i'd support adoption. > > first, this feature is controversial, and there is not consensus favouring > its > implementation, merely its documentation. > > second, the initiator must indicate its intent to use data beyond its TTL, > and > the responder must assent to this, and that otherwise, including in the > default case where such signaling is absent, data shall not be used beyond > its > TTL. Would you see the querying application informing you of intent via option code saying "If I'm unable to talk to you once TTL expires, I may serve your last known good answer"? What would a server then do if this intent were known? serve some alternate data, or even return REFUSED? I could 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++; | http://puck.nether.net/~jared/ My statements are only mine. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale
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-tale-dnsop-serve-stale > > The draft is available here: > https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > *If You have already stated your position for or against adoption, we are > counting those so you do not need to repeat yourself. * > > This call for adoption ends: 19 September 2017 > > Thanks, > tim wicinski > DNSOP co-chair > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] opportunistic refresh and Happy Eyeballs
> 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 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 implemented. > > as i've said every few years when this proposal comes up, it's unnec'y. > > we can specify that be sent as additional data for QTYPE=A, and > that A be sent as additional data when QTYPE=. > > given identical deployment curves along both the ANYA and > additional-data timelines, we will get identical results. As this is DNSOP, what implementations support this? - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] opportunistic refresh and Happy Eyeballs
> 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 implemented. - jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-serve-stale
> 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 reflect that. Vixie >> >> >> I will note there are other implementations out there as well, such as in >> unbound. serve-expired configuration directive is available there as well. > > Though, the algorithm described in this document is a much different > algorithm than the one in Unbound. At least the initial implementation is documented (via code) here: https://github.com/jedisct1/unbound/commit/e03d89343e4031be15b2ee78bd432f83cdc79889 > If I understand Unbound's serve-expired algorithm correctly, it always > serves from cache if available (regardless of expiration status), and if > what it served to the client happened to be expired, it triggers a > post-response fetch to update the cache asynchronously. That can end up > serving a lot more stale bread than is strictly necessary if your > Unbound server only serves a few clients. I see the perceived damage here as very low due to the "few clients" you already commented on. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-serve-stale
> 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/dnsop
Re: [DNSOP] draft-tale-dnsop-serve-stale
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 directive is available there as well. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] old arguments unrelated to SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)
On Tue, Mar 01, 2016 at 06:15:22PM -0500, John R Levine wrote: > >>The NDR record is deliberately free format because changing DNS > >>servers is HARD, no really it is ridiculously hard with a ten year > >>lag. Which is of course why we won't use a new record at all: > > > >Really? We have rpm's of new versions of named supplied within > >hours of ISC's public announcements of new named releases. I'm > >sure there are similar announcements for other nameserver vendors. > > I suppose I could say web based configuration crudware a few dozen more > times, but I doubt it would sink in any more than it has before. I've seen organizations that don't upgrade/patch software if they feel it can be mitigated with other technical means because alterting them would require hypothetical testing that they won't do. With the recent stream of security updates in the past 2-3 years to bash, OpenSSL, etc.. they have started to change their stance. I understand the goals of 'change one thing at a time' so it's easy to know what introduced the breakage, but at some point people who fail to upgrade will cease to work. I was helping with a router today where the lack of a proper clock meant it could not generate a SSH key because the crypto system would not work. We are creating a more fragile ecosystem at times for the sake of security, and things will 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 available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0
> 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 some answers from my zones (e.g. DNSKEY) are bigger than > 512 bytes and so can cause truncation and TCP, so maybe I do care after > all. Or just having the TCP implementation in BIND get improved as it’s clear there are some more people pushing in this direction. I’m looking at just putting something like DNSDIST on my hosts to process TCP and balance it across multiple daemons to do the query scale. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)
> 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 designed at all. i'm glad we > did the foolish thing and kept going, though. > This reiterates to me the need for me to complete the backend tooling for diagnosing DNS resolver issues. Having something that detects if a server is doing minimization will be helpful to understand client behaviors. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new Resource record?
> 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.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new Resource record?
> 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 to suggest the following format (this is the rough version and > it is not exact but only giving you an idea that what is the purpose) for a > new resource record to store the reference information of bounding of > authentication and authorization where authentication can be based on public > keys or certificates. > This means each reference no represents an actual policy template in other > security system or other services. This means if a certificates bound to > more than one references, then more than one of this section is added to > RDATA section of the DNS query. This also should be updatable by the DDNS > protocol. > BTW, I skipped the header and other parts of RR and this part is only the > RDATA section. > > --- > |flag| reference no | > --- > | some human readable | > | text | > --- > > The processes are also simple, when a node query the certificates, DNS > server also includes this RR if it exists on the DNS server so that when the > querier retrieves this information, it can query other services for the > given value to authorize the other host on the network. > > Is DNSOP a right place for that? I asked DANE and they said it Is not in > their charter. If not, please tell me where is the right place. If yes, > please tell me what do you think about that and whether or not you support > it to draft it. People have done things similar to this over the years. I remember software once distributed UNENCODED over sequenced DNS TXT records. It seems something like TXT would be the best way to do this, eg: dig txt 1.255.42.204.in-addr.arpa. Nothing really stops you from putting a “Seq-01-Base64-Blob” out there. You might be able to use HINFO for that as well since it’s designed for two fields already. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 2181 - reconsiderations
> 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
Nor is your comment helpful in moving the discussion forward. As the scribe from yesterday I tried to capture the essence of the room. I'm not aware of a requirement to post the contents to the list. I would kindly ask you to take a quick read to get the essence of what transpired yesterday 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 know if you need help finding them. > > that's not responsive to my question. > >>> (is the definition of an IETF WG's "membership" still its mailing list not >>> its meeting rooms?) > > -- > Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
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 informational document with current >> behaviors may be helpful? > > as the notes have not been published, those of us not in the room have not > had a chance to observe or comment. (is the definition of an IETF WG's > "membership" still its mailing list not its meeting rooms?) > > -- > Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
> 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 serious question.) This is somewhat of a religious thing for me, but: a) vendors respond to behaviors documented in RFCs when RFPs/RFIs are issued b) IP packets are generally assumed to be version 4 by most people, getting in the habit of documenting the behavior of both isn’t really that hard. We need to get into the habit of putting v6 examples in documents, it’s 2015. c) people copy examples forever, having good well-documented examples for both are important. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
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 operational environment in which RFC 1035 has been > interpreted since 1987. if we want the initiator to change its assumptions > then we have to say so. the saying of so may or may not constitute a protocol > change since we're clarifying the assumptions rather than asking for > different behaviour. but since we must also guide the initiator to not leave > a tcp session idle, which absolutely is a protocol change, i see no harm is > bundling this guidance into a single document which is collectively a > revision to the protocol. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
> 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 minor nit for consideration: the examples should also include IPv6 loopback ::1 as well. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
> 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 losing. > > if we're serious about redefining ANY as a meta-query, then answering with > RCODE=0/ANCOUNT=0 is correct. (as it would be for RD=0 queries against an > RA=1 server.) > > but whatever we do, any new reaction to QTYPE=ANY has to ensure that the > client gives up, and stops asking. I for one am concerned about doing away with QTYPE=ANY and would like to see something more along the lines of authorities returning results so dig +trace works for diagnosis. Perhaps building better tools for this which might remove my concern around ANY, that way it can iterate through various QTYPEs for me. - jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Another suggestion for "any"
On Wed, Mar 11, 2015 at 07:12:55AM -0700, Paul Hoffman wrote: > On Mar 11, 2015, at 2:00 AM, Paul Vixie wrote: > > djb doesn't want QTYPE=ANY deprecated in any form. > > > > olafur doesn't want to "do_ANY", under any conditions. > > > > so i'm baffled by why you're offering this alternative? > > Neither djb nor Olafur are automatically the consensus of this WG. None of us > are. > I've had trouble emailing djb about this and received bounces from his mailer, so feel trustrated trying to have a conversation that includes him at least. This does seem to fall into the whole "undefined" category just like many people feel that TCP is optional where my reading of 1035 4.2.2 defines how queries over TCP should be performed. At the most recent NANOG John Kristoff presented on the TCP part: https://www.nanog.org/sites/default/files/nanog63-dnstrack-kristoff-dnstcp.pdf There is a gap, neither positive or negative in the behavior of these things, which I'm sure will rage along for a bit re: ANY, TCP, etc... I'm working on a project right 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 finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
> 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 ultimate answer (clearly it >> can be improved); what I'm saying is that these are protocol issues, and >> that protocol changes need to be handled by an appropriately chartered >> IETF working group. > > (I removed the dns-operations list from this because this needs to be > discussed on DNSOP.) > > > Dan, > > You're right. But. > > Operators are not bound to comply with what the IETF documents. > > As much as operators shouldn't bully the IETF nor the public for which the > serve, the street goes two ways. The IETF is not able to and should not > bully them. The IETF is supposed to provide us with an interoperable way > to operate and is supposed to have documents that reflect "running code.” I would be interested in hearing the results you had from disabling ANY queries, or anyone else results. This isn’t standing in opposition to change, but trying to understand the true scope and nature of this problem. Perhaps I’m missing parts of the problem, but the qmail issue has existed for 10 years. Firefox recently turned on and back off ANY queries in 36.0 and 36.0.1 to try to keep performance what it should be for websites that have low TTLs vs being ‘sticky’ to an old A/ record. >> * Second: The merits of the protocol modification have to be properly >> discussed in that working group, to evaluate the costs and benefits >> of the protocol modification---and to consider whether there are >> better ways to achieve the same benefits. > > > If operators find that a protocol needs to be modified to be properly > operated, the IETF ought to adjust the protocol definition. Having a > migration path would be a plus too. (Said tongue in cheek.) > > But - "finding that a protocol needs to be modified" is not as easy as > that - hence my quoting of your words above. I’m concerned a change of this sort will cause a number of people to see something as ‘broken’ where it really is not. If we are dealing with code that will break things for existing users, giving them broad warning is important, even if they are using/abusing this capability of the DNSs system today. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
> 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. > > There are three bugs in the way qmail uses ANY queries. > > (1) qmail uses ANY queries for domain canonicalization on outgoing > messages, as specified by RFC 1123. But canonicalization is not required > by the current SMTP specification. It is a waste of time. Fixing this bug > would make bug (3) moot. > > (2) qmail's DNS response buffer is too small to accommodate a complete DNS > message, so it fails if it gets a large response. It uses the low-level > libc resolver API which can easily handle large responses, including > fallback to TCP, so it is a pity that qmail breaks this part of the > resolver's functionality. This bug means it is not guaranteed to work. > > (3) Using an ANY query suppresses alias processing, so qmail makes a > series of queries to follow CNAME chains. This is inefficient and > wasteful. If you make an A or MX query, the DNS server will chase the > CNAME chain for you, so you only need to make one query to get the > canonical name. Even ignoring if qmail is “broken”. (I would rather classify it as, could do better), depreciating the ANY qtype is going to have some significant side effects of users troubleshooting DNS problems. I’m very sensitive to the abuse of ANY queries, but this is something that I feel there are sufficient controls that exist to mitigate the issues, namely using TC=1 to direct well behaving clients to receive a valid response. dnsop-any-notimp violates the principle of least surprise in technology by returning NOTIMP where Paul Vixie suggested NOERROR/ANCOUNT=0 would be more appropriate with the existing definitions. Much of this is triggered by bad coding practices and bad networking examples that are littered around codebases, e.g.: gethostbyname() vs getnameinfo() and by broken behaviors by nscd and other OS/LIBC implementations that also violate the principle of least surprise. - Jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
