Re: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
On Sat, 6 Aug 2005, Joshua Brady wrote: the FBI can call the NSA anytime they want without a tap order and get them to trigger ECHELON when your voice is apparant on any line. Not me, I wrapped my cellphone in tin foil. [EMAIL PROTECTED]< The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Re: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
>>I'm sorry, but this is simply an unsupportable statement. What is >>required of routers is that the provider be able to configure the device >>to make copies of certain packets to a monitoring port. Assuming that >>the monitoring port is duly managed, how does this qualify as "insecure"? > > > It qualifies as "insecure" because if that rather dubious assumption fails to > be true, you have a big problem. If any port on a router is not duly managed, you have a big problem. Tony
Re: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
On Sat, 06 Aug 2005 17:26:23 PDT, Tony Li said: > I'm sorry, but this is simply an unsupportable statement. What is > required of routers is that the provider be able to configure the device > to make copies of certain packets to a monitoring port. Assuming that > the monitoring port is duly managed, how does this qualify as "insecure"? It qualifies as "insecure" because if that rather dubious assumption fails to be true, you have a big problem. pgptUY5oa87ow.pgp Description: PGP signature
Re: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
On 8/6/05, Tony Li <[EMAIL PROTECTED]> wrote: > > > > i opine that some features are innovation and others not. i.e., > > x.25 support on modern kit seems a not innovative and a waste of > > resources i would rather see applied elsewhere. Who said the user end needs to support a "tap" being done? They can just force ISP's to log everything at the headend. Your phone doesn't need a specialized device to tap it right now does it; cell phones either; the FBI can call the NSA anytime they want without a tap order and get them to trigger ECHELON when your voice is apparant on any line. -- Joshua Brady
Re: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design fo r In ternet Services
I realize that CALEA is primarily geared towards traditional wiretapping (esp. pen register), but given the machinations of other organaizations (which have also mobilzed law enforcement) such as the MPAA and the RIAA, one might also surmise that this also seems to be desired for not just VoIP services - ferg -- sjk <[EMAIL PROTECTED]> wrote: We all pay the bill with higher equipment costs, the maintenance of configurations, and possible storage costs. CALEA was bound to include VoIP services - given the definition telecom carrier in the act; however, as I recall -- and I may be wrong -- when CALEA was first passed the carriers were given tax breaks and subsidies to implement changes. Is such financial help being offered today? --sjk -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
> i opine that some features are innovation and others not. i.e., > x.25 support on modern kit seems a not innovative and a waste of > resources i would rather see applied elsewhere. Probably a fairer characterization. > but every feature has its cost in complexity and resources to build > and maintain. resources are finite and complexity has super-linear > cost. so i would much prefer that the vendors concentrate on the > features *i* want . and i am quite skeptical of features which > non-paying non-customers want. Well, I'm even skeptical of features that paying customers want. But that doesn't pay the bills. ;-) While complexity has super-linear cost, not all features introduce significant complexity. It's very much a function of the architecture. In a highly partitioned, loosely coupled system, adding a feature that interacts with only a single other component in a trivial way may be quite simple. In a monolithic system, adding a feature that permeates the system may be so complex as to be unimplementable. The features to avoid are those where the complexity cost outweighs the revenue. If only we could evaluate this properly! ;-) Tony
Re: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
On Sat, 6 Aug 2005, Randy Bush wrote: It also hobbles technical innovation by forcing companies involved in broadband to redesign their products to meet government requirements. As opposed to hobbling innovation by meeting customer requirements? who's paying the bill? and sorry to hear from a vendor that meeting the customers' requirements is such a negative thing. randy We all pay the bill with higher equipment costs, the maintenance of configurations, and possible storage costs. CALEA was bound to include VoIP services - given the definition telecom carrier in the act; however, as I recall -- and I may be wrong -- when CALEA was first passed the carriers were given tax breaks and subsidies to implement changes. Is such financial help being offered today? --sjk
Re: /8 end user assignment?
Actually the cable modems and Dsl modems usually have a 10.x address they are used by the ISP's to access their internal firware. Also on traces that I have done on both cable and dsl the first hop is invariably a RFC1918 address. Steven M. Bellovin wrote: In message <[EMAIL PROTECTED] t>, "Stephen J. Wilcox" writes: 2. We know cable companies, dsl providers and mobile companies can use this ma ny IPs, but they generally seem to make use of NAT and IPv6. If everyone in this category who could justify a /8 applied and received them we might be in real trouble with our IPv4 space. I had said elsewhere this was unprecedented but was then pointed at 73.0.0.0/9, 73.128.0.0/10 which is Comcast assigned in April. I'm surprised none of these assignemtns have shown up on mailing lists.. When it comes to Comcast, I'm just an ordinary residential subscriber, but they don't use NAT for subscriber addresses as best I can tell. Certainly, I've never been given one, asked about one, etc. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb . -- My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. -- carpe ductum -- "Grab the tape" CDTT (Certified Duct Tape Technician) Linux user #322099 Machines: 206822 256638 276825 http://counter.li.org/
Re: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
It also hobbles technical innovation by forcing companies involved in broadband to redesign their products to meet government requirements. >>> As opposed to hobbling innovation by meeting customer requirements? >> who's paying the bill? and sorry to hear from a vendor that meeting >> the customers' requirements is such a negative thing. > You mistake my meaning, Randy. Implementing features ARE innovation. > Not hobbling it. sorry if i misinterpreted. i opine that some features are innovation and others not. i.e., x.25 support on modern kit seems a not innovative and a waste of resources i would rather see applied elsewhere. but every feature has its cost in complexity and resources to build and maintain. resources are finite and complexity has super-linear cost. so i would much prefer that the vendors concentrate on the features *i* want . and i am quite skeptical of features which non-paying non-customers want. randy
Re: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
>>>It also hobbles technical innovation by forcing companies involved in >>>broadband to redesign their products to meet government requirements. >> >>As opposed to hobbling innovation by meeting customer requirements? > > > who's paying the bill? and sorry to hear from a vendor that meeting > the customers' requirements is such a negative thing. You mistake my meaning, Randy. Implementing features ARE innovation. Not hobbling it. Tony
Re: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
>> It also hobbles technical innovation by forcing companies involved in >> broadband to redesign their products to meet government requirements. > > As opposed to hobbling innovation by meeting customer requirements? who's paying the bill? and sorry to hear from a vendor that meeting the customers' requirements is such a negative thing. randy
Re: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
> Practically, what this means is that the government will be asking broadband > providers > - as well as companies that manufacture devices used for broadband > communications – to build insecure backdoors into their networks, > imperiling the privacy and security of citizens on the Internet. I'm sorry, but this is simply an unsupportable statement. What is required of routers is that the provider be able to configure the device to make copies of certain packets to a monitoring port. Assuming that the monitoring port is duly managed, how does this qualify as "insecure"? > It also hobbles technical innovation by forcing companies involved in > broadband to redesign their products to meet government requirements. As opposed to hobbling innovation by meeting customer requirements? There are many issues with CALEA that one can object to, primarily having to do with the checks necessary to ensure that appropriate warrants are obtained and that the traffic is appropriately filtered before monitoring. I'm disappointed that EFF is so off the mark here. Tony
FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
Via the EFF website. [snip] Today the Federal Communications Commission (FCC) issued a release announcing its new rule expanding the reach of the Communications Assistance to Law Enforcement Act (CALEA). The ruling is a reinterpretation of the scope of CALEA and will force Internet broadband providers and certain voice-over-IP (VoIP) providers to build backdoors into their networks that make it easier for law enforcement to wiretap them. The Electronic Frontier Foundation (EFF) has argued against this expansion of CALEA in several rounds of comments to the FCC on its proposed rule. CALEA, a law passed in the early 1990s, mandated that all telephone providers build tappability into their networks, but expressly ruled out information services like broadband. Under the new ruling from the FCC, this tappability now extends to Internet broadband providers as well. Practically, what this means is that the government will be asking broadband providers - as well as companies that manufacture devices used for broadband communications to build insecure backdoors into their networks, imperiling the privacy and security of citizens on the Internet. It also hobbles technical innovation by forcing companies involved in broadband to redesign their products to meet government requirements. "Expanding CALEA to the Internet is contrary to the statute and is a fundamentally flawed public policy," said Kurt Opsahl, EFF staff attorney. "This misguided tech mandate endangers the privacy of innocent people, stifles innovation and risks the functionality of the Internet as a forum for free and open expression." [snip] http://www.eff.org/news/archives/2005_08.php#003876 - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: /8 end user assignment?
On 6-aug-2005, at 23:58, Christopher L. Morrow wrote: how would you know if people who had dualstack systems were trying to get and failing? Run statistics off some selected recursive resolvers? Filter out spammers and other abuse first to make them more accurate. Ok, perhaps off your auth boxes would be better as you likely aren't getting copies of the log from my (or anyone else's) recursive servers. anyone atleast doing this? I ran a web bug for a reasonably popular generic Dutch site for a while, and I discovered that around 0.16% of all requests (that's about 1 in 666) happened over IPv6. Counting requests isn't very reliable, as some software performs these requests even if the system has no IPv6 connectivity. I believe Firefox does this unless IPv6 support is turned off. (It's turned on by default on nix and Win, off on Mac.)
Re: Why some of us are IPv6 holdouts (Was: /8 end user assignment?)
--On August 6, 2005 6:56:27 PM + "Christopher L. Morrow" <[EMAIL PROTECTED]> wrote: a good email over all explaining more parts of the pie :) sweet! Thanks... I try to add something to the threads when I weigh in... <..> ok, good... now in 5 years when there are 'many more' v6 users are you still in this boat? should some of this work get started also? Would that be facilitated by getting some actual logs? The point really, was that there are many packages of software. Open Source, Commercial, in-house, front-end and back room that will need to be looked at and outfitted. It's happening, but it will take a lot of work, and probably time. In 5 years, I don't know. I hope not. I hope by long before then that a majority of my concerns are addressed. It will take my employer/org about six months, to one year to fully light IPv6 for production. Maybe a bit longer. We've internal software to worry about, and that estimate excludes any set-backs from external sources, like Juniper deciding to twist everyone's arms for IPv6 licensing. I can leave that to a separate thread/argument though. I do have about a paragraph or two of venom on that topic if anyone is interested. :) Maybe I'm more concerned about what (potentially bad) things happen on my networks. Maybe not. Either way, that issue alone means a LOT of other software than the web server, load balancer, and routers need to understand (or speak) IPv6. There's a huge ecosystem of software here. A lot of it hasn't been written in such a way that it takes into account any other addressing/networking scheme than IPv4. agreed, but that problem doesn't seem to be getting addressed any better than the lb/router/web-server problem doe sit? No not particularly. The web server software, routers, and load balancers in my networks are all IPv6 capable, aware, and ready. What isn't at this point is management tools, and an unknown number of customer applications. I work primarily in web hosting. This means that there are lots of unrelated applications that may make turning on IPv6 difficult. I'm not saying it's impossible. I'm not saying it won't happen. Heck I want it to happen. I want to go IPv6, get out of the way of the address shortage that will be. I wanted to point out the bigger picture amongst these threads of half answers and single issues. This isn't a one issue thing. Everyone here on NANOG can make it that if they want to, but I doubt that most of us do. The difficulty is in pointing this out to the 'sky is falling migrate today!' drum beaters, most of us are working on it, but we're not the ones that need to be haranged. SW developers need to be educated too, as much as, maybe more so than the ops community. They're the ones that will ultimately make or break this thing. We can build a network however we damn well please. But in the end the network is just a road. We need applications. Cars. And people to drive those carsuse those applications. That's what it comes down to. Multicast has limited traction not necessarily because of limited technical merit or ability, but because there are few applications that make use of it. As apps improve and start to support or require IPv6, more and more will roll it out or be forced to roll it out. Some of us are being held up by applications, hardware, or upsterams lack of v6, but that won't last forever, and it can't last much longer or we could very realistically miss the deadline, whatever it ends up being, for the 'last of the v4 space'. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler
Re: /8 end user assignment?
On Sat, 6 Aug 2005, Petri Helenius wrote: > > Christopher L. Morrow wrote: > > > > >This arguement we (mci/uunet) used/use as well: "not enough demand to do > >any v6, put at bottom of list"... (until recently atleast it still flew as > >an answer) How would you know if you had demand? how would you know if > >people who had dualstack systems were trying to get and failing? > > > Run statistics off some selected recursive resolvers? Filter out > spammers and other abuse first to make them more accurate. Ok, perhaps off your auth boxes would be better as you likely aren't getting copies of the log from my (or anyone else's) recursive servers. anyone atleast doing this? -Chris
Re: /8 end user assignment?
On 6-aug-2005, at 21:56, Randy Bush wrote: i.e. how much will doing v6 add to the lb company's income? Business is so much easier when it comes with guarantees about the future. I.e. sometimes you need to invest in new technology without immediate clear benefits to remain relevant in the long term. We all know that it's rarely the first adopter that makes the most money off of something new, but it's never the last.
Re: /8 end user assignment?
> without immediate needs and immediate testing/work I doubt vendors will > push in this new feature :( I may be cynical though... s;immediate testing/work;increased sales; i.e. how much will doing v6 add to the lb company's income? randy
Re: /8 end user assignment?
Christopher L. Morrow wrote: This arguement we (mci/uunet) used/use as well: "not enough demand to do any v6, put at bottom of list"... (until recently atleast it still flew as an answer) How would you know if you had demand? how would you know if people who had dualstack systems were trying to get and failing? Seriously, I'm just curious here... this is akin to the 'if a tree fell inn the forest would it make noise' problem. Run statistics off some selected recursive resolvers? Filter out spammers and other abuse first to make them more accurate. Pete
Re: /8 end user assignment?
On Fri, 5 Aug 2005, Daniel Golding wrote: > > > > On 8/4/05 6:49 PM, "Steve Feldman" <[EMAIL PROTECTED]> wrote: > > > > >> I meant to ask this at a nanog or this IETF... why don't some of the > > > > - There are (perceived to be) more important things to spend > > our limited resources on. > > > > Why should content providers be at all interested in driving v6 usage? They > are interested in meeting demand, innovating, collecting ad revenue, etc. > The ROI to the given content provider is what? There ARE more important > things to spend one's limited resources on. > Content providers will have to do something about v6 'soon' (ho wsoon is another matter I suppose) I was attempting to spur on some discussion (which this did) about v6 deployment. I was also suggesting that perhaps a sideline v6 access to some larger providers would make other folks move forward, and would get vendors in to the right mood about v6 on their gear. 'checkbox' support is just not going to fly when the fan finally starts spinning and the darkmatter starts flying :(
Re: Why some of us are IPv6 holdouts (Was: /8 end user assignment?)
a good email over all explaining more parts of the pie :) sweet! On Fri, 5 Aug 2005, Michael Loftis wrote: > > --On August 5, 2005 11:13:13 AM +0200 Iljitsch van Beijnum > <[EMAIL PROTECTED]> wrote: > > There's a huge knock-on-effect on all manner of things that you might not > expect to need to think about IPv6 offhand. Like log processors. I don't > know about you but I don't have humans or chimps reading my logs for > suspicious activity and producing summary reports of traffic, I've got > automated processes. I'm not willing to wager that every one of those > programs is ready yet. ok, good... now in 5 years when there are 'many more' v6 users are you still in this boat? should some of this work get started also? Would that be facilitated by getting some actual logs? > > Maybe I'm more concerned about what (potentially bad) things happen on my > networks. Maybe not. Either way, that issue alone means a LOT of other > software than the web server, load balancer, and routers need to understand > (or speak) IPv6. There's a huge ecosystem of software here. A lot of it > hasn't been written in such a way that it takes into account any other > addressing/networking scheme than IPv4. agreed, but that problem doesn't seem to be getting addressed any better than the lb/router/web-server problem doe sit?
Re: /8 end user assignment?
On Fri, 5 Aug 2005 [EMAIL PROTECTED] wrote: > > Sabri Berisha <[EMAIL PROTECTED]> wrote: > [...] > > With the use of anycast DNS servers on the internet, TCP is no > > longer an option for DNS. > > Erm, bollocks. > > Just because a few nameservers are anycasted doesn't mean that the > vast majority of non-anycasted servers may not use TCP. > > Optimising the common case of simple lookups so they fit in a UDP > request makes good sense, but an overzealous determination to stamp > out TCP DNS is not helpful, since it is rather useful under certain > circumstances. *cough* worldnic dns servers *cough* it's part of the rfc, make sure it works please.
Re: /8 end user assignment?
Oh how I relish the firebomb email while on vacation trick :)
On Fri, 5 Aug 2005, Iljitsch van Beijnum wrote:
> On 5-aug-2005, at 10:59, Randy Bush wrote:
>
> >> Until such devices support IPv6, to reiterate Steve's point, it's
> >> not an
> >> option to consider approaching connectivity suppliers with IPv6
> >> enquiries.
>
> > could you comment on christopher's observation that, given the likely
> > volume of v6 traffic, you would not have a v6 load worth balancing?
> > of course, then you would be committed to serving v6. and if loads
> > increased before you got vendor support for balancing, you would not
> > be in a pretty place.
>
--snip dns multi- tricks---
>
> Obviously when people running these services refuse to consider IPv6
> because they can't load balance doesn't provide much incentive to
> load balance vendors to upgrade their stuff.
>
I think most of the problem gets to:
"Vendor XYZ, we need ipv6 support in your hardware loadbalancer product."
"Customer ABC, hrm, COOL! when are you deploying v6?"
"Vendor XYZ, well, we aren't ready YET, but perhaps when we get down to
item 234 on our priorities list we will be ready, say 5 years from now?
provided other projects don't slip and marketting doesn't throw another
monkey wrench in my project list :("
"Customer ABC, sure...w e'll get right on that then wanna see a
shiney new lb product fact sheet?..."
without immediate needs and immediate testing/work I doubt vendors will
push in this new feature :( I may be cynical though...
Re: /8 end user assignment?
On Fri, 5 Aug 2005, Andy Davidson wrote: > > Randy Bush wrote: > >>Until such devices support IPv6, to reiterate Steve's point, it's not an > >>option to consider approaching connectivity suppliers with IPv6 enquiries. > > could you comment on christopher's observation that, given the likely > > volume of v6 traffic, you would not have a v6 load worth balancing? > > My point was that the 'loadbalancers' do so much more than share load, > and I don't want to lose this functionality. Sure, and the things you pointed out you yourself pointed out could be done with mod_proxy on apache, provided the load wasn't TOO high... > > But to answer your question, the market isn't providing us with enough - > or rather *any* interest, and this is what matters. If we reach the > point where people can't buy widgets from us until we support IPv6, or > that people would rather buy widgets from someone else because they > support it, then we have to move. This arguement we (mci/uunet) used/use as well: "not enough demand to do any v6, put at bottom of list"... (until recently atleast it still flew as an answer) How would you know if you had demand? how would you know if people who had dualstack systems were trying to get and failing? Seriously, I'm just curious here... this is akin to the 'if a tree fell inn the forest would it make noise' problem. > > I don't know if there can be other financial incentives for us - if we > can buy IPv6 connectivity very cheaply - which helps us squeeze those > margins even more of course, then similarly we have to move. Quickly. v6 is free in most places today, sprint/verio/uu (someone else I'm forgetting, sorry!) in the US atleast have v6 connectivity for 'free' (provided you have a v4 link), is 'free' cheap enough? :)
Re: /8 end user assignment?
On Fri, 5 Aug 2005, Andy Davidson wrote: > > Christopher L. Morrow wrote: > > will the v6 access really be enough to require LB's? or are they there for > > other reasons (global lb for content close to customers, regionalized > > content) perhaps reasons which would matter 'less' in an initial v6 world > > where you were getting the lb's fixed by their vendor? (or finding a > > vendor that supports v6 lb?) > ---snip lb chatter--- > Until such devices support IPv6, to reiterate Steve's point, it's not an > option to consider approaching connectivity suppliers with IPv6 enquiries. > One hopes for your sake you are poking the vendor for v6 support, poking hard and often. If the talk of a complete v6 transition for Yahoo-BB in japan goes over, and they have 'crappy' or 'no' v4 to the users there's some large number of millions of users disappearing from the v4 network, hurry up :) > > [0] Redline Networks E|X, now owned by Juniper of Borg. > > -a >
Re: /8 end user assignment?
On Sat, 06 Aug 2005 17:45:13 -, Paul Vixie said: > disagreed. (because DNSSEC is coming.) The operational question is, of course, whether we need to worry about allocating resources for deploying DNSSEC before or after IPv6. ;) pgpbo8XS6qCho.pgp Description: PGP signature
Re: /8 end user assignment?
[EMAIL PROTECTED] (Iljitsch van Beijnum) writes: > On 5-aug-2005, at 15:55, Joe Abley wrote: > > > It is of course possible to construct networks through which TCP > > behaves very poorly with anycasted services. This does not mean that > > TCP is fundamentally incompatible with anycast. > > It does mean that if people want to anycast services that run over TCP > (even just a small part of the time, such as DNS) they should make sure > this works well. it's working fine for 30+ instances of F-root. > A good start is using different AS numbers for the anycast instances so > (Cisco) routers won't load balance over the different paths. we have not encountered a problem like this, even though all F-root anycast instances use a consistent origin-AS. my belief, previously explained here, is that anyone who turns on multipath-EGP (rather than multipath-IGP) is going to have a boatload of other problems before they ever get around to noticing whether TCP is working toward anycasted servers. (OSPF ECMP is, i believe, on-by-default; multipath-BGP is, i am sure, off-by-default.) > But all of this is irrelevant to the discussion at hand, unless I missed > something big and DNS over TCP has now been deprecated. If that's the > case, the appropriate action is to disable TCP queries in the software, > not to avoid TCP queries by keeping response sizes small. agreed. (that TCP isn't a problem.) > But my original point was that you won't go over the non-EDNS0 limit > for normal queries with less than a dozen records anyway. disagreed. (because DNSSEC is coming.) -- Paul Vixie
Re: Fiber cut in SJ
On 8/5/05 8:12 PM, "George William Herbert" <[EMAIL PROTECTED]> wrote: > First, an electrical contractor backhoed a large fiber > link in downtown San Jose (address deleted due to security > concerns) this morning, causing moderate damage. That's just plain silly. As if we (or even your imagined 'terrorist') don't know where the fiber runs around here. Mindlessly classifying everything as 'secret' is a tactic I'd expect of DHS, not NANOG. 'Need to know' does not appear anywhere in the constitution. -- Joe McGuckin ViaNet Communications (address deleted due to security concerns)
Re: /8 end user assignment?
On 5-aug-2005, at 15:55, Joe Abley wrote: It is of course possible to construct networks through which TCP behaves very poorly with anycasted services. This does not mean that TCP is fundamentally incompatible with anycast. It does mean that if people want to anycast services that run over TCP (even just a small part of the time, such as DNS) they should make sure this works well. A good start is using different AS numbers for the anycast instances so (Cisco) routers won't load balance over the different paths. But all of this is irrelevant to the discussion at hand, unless I missed something big and DNS over TCP has now been deprecated. If that's the case, the appropriate action is to disable TCP queries in the software, not to avoid TCP queries by keeping response sizes small. But my original point was that you won't go over the non-EDNS0 limit for normal queries with less than a dozen records anyway.
