Re: Please, talk me down.
On 17 Oct 2012, at 5:35 AM, Joseph Anthony Pasquale Holsten wrote: > I want to like IPv6. I do. But I'm seriously considering turning off IPv6 > support from our servers. > > First off, I'm using djbdns internally and it doesn't support records. > So we really aren't using it internally. > > But today I noticed that we have a lot of traffic to our DNS cache, and > started to investigate. Turns out that every DNS request would start with one > for the record. Ah, no luck. Maybe you forgot the search domain? Let's > retry that DNS request with that tacked on. Failed again? Meanwhile, lets > simultaneously try for the AA record then. Repeat. ++ on what everyone else has said about this being a problem with the way you run your DNS infrastructure, instead of an actual IPv6 problem. Without reasons listed for why you use djbdns, I can't really adequately comment, but: on our net we're using unbound as caching DNS servers with pretty good success, and pdns with dynamic backends (the backends are custom in-house stuff) as our authoritative DNS. Short of issues now and then with the backends, it works pretty well. -J
Re: Please, talk me down.
On Wed, 17 Oct 2012, Joseph Anthony Pasquale Holsten wrote: First off, I'm using djbdns internally and it doesn't support records. So we really aren't using it internally. Sounds like a self-inflicted wound. You have alternatives. I'm _this_ close to turning IPv6 off entirely. Anyone want to talk me off this ledge? -- http://josephholsten.com You can stay on the ledge if you like. A lot of folks have already decided to move on... Antonio Querubin e-mail: t...@lavanauts.org xmpp: antonioqueru...@gmail.com
Re: Please, talk me down.
On Tue, 16 Oct 2012 20:35:11 -0700, Joseph Anthony Pasquale Holsten wrote: I want to like IPv6. I do. But I'm seriously considering turning off IPv6 support from our servers. First off, I'm using djbdns internally and it doesn't support records. So we really aren't using it internally. But today I noticed that we have a lot of traffic to our DNS cache, and started to investigate. Turns out that every DNS request would start with one for the record. Ah, no luck. Maybe you forgot the search domain? Let's retry that DNS request with that tacked on. Failed again? Meanwhile, lets simultaneously try for the AA record then. Repeat. I'm _this_ close to turning IPv6 off entirely. Anyone want to talk me off this ledge? You will eventually have to turn it on again, so you may run away from the problem that will catch you up anyway or, better, start tackling the problems, like fixing djbdns or replacing it with something that works. That's my way of seeing it. Good luck with it. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp
Re: Please, talk me down.
In message <2801f5f8-b8e2-4a9f-9a89-02d7783cc...@josephholsten.com>, Joseph Ant hony Pasquale Holsten writes: > I want to like IPv6. I do. But I'm seriously considering turning off > IPv6 support from our servers. > > First off, I'm using djbdns internally and it doesn't support > records. So we really aren't using it internally. djbdns doesn't support lots of things. > But today I noticed that we have a lot of traffic to our DNS cache, and > started to investigate. Turns out that every DNS request would start > with one for the record. Ah, no luck. Maybe you forgot the search > domain? Let's retry that DNS request with that tacked on. Failed again? > Meanwhile, lets simultaneously try for the AA record then. Repeat. It looks like your getaddrinfo implementation is a searching for records and then searching for A records. With a A record for name2 you get a query path like this. e.g.name1 -> NXDOMAIN name2 -> NODATA name3 -> NXDOMAIN name1 A -> NXDOMAIN name2 A -> DATA You could ask you vendor to implement a alternating search strategy. e.g.name1 -> NXDOMAIN name1 A -> NXDOMAIN name2 -> NODATA name2 A -> DATA Additionally you could get your vendor skip the A lookup on NXDOMAIN from . e.g.name1 -> NXDOMAIN name2 -> NODATA name2 A -> DATA > I'm _this_ close to turning IPv6 off entirely. Anyone want to talk me > off this ledge? > -- > http://josephholsten.com > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Please, talk me down.
On Tue, 2012-10-16 at 21:59 -0600, Jima wrote: > FWIW, DJB's public take on IPv6 can be found here: > http://cr.yp.to/djbdns/ipv6mess.html . After a quick read, it seems that that statement completely fails to consider dual stack as a transition mechanism. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Re: Detection of Rogue Access Points
On 10/14/12, Karl Auer wrote: > No-one has said this yet, so I will - why are people working around your > normal network policies? This is often a sign of something lacking that > people need in their daily work. You can often reduce this sort of While that's no reason to stop looking for rogues... It's a good point that policy and planning there is a crucial element; more important than managing all network devices; or even having antivirus or firewalls. Because humans are a weak point -- every enterprise has them: there are ways the humans can be exploited unwittingly, humans might sometimes follow an improper procedure,the eventual occurrence of an incident related to human weakness may be inevitable. "Lacking something they need" is not likely. If it's really true that a forbidden thing is needed for their work -- they should be able to persuade their org's leadership to create a variance from the policy, or implement a solution. It's more likely the network user introduces rogue devices because (1) The rule wasn't written down.. E.g. It was actually an unwritten policy never carefully formulated into writing, that nobody may just plug in whatever network device wireless AP, 5 port switch, or Linksys router, even with a "good reason" to; the network users had no document to follow to explain mandatory steps required to introduce a new device. (2) The people don't know what the policy, standard, or directive actually is: They haven't been administered adequate training and been quizzed appropriately on the relevant policies, standards, and guidelines; their role with regard to the policy is not understood properly. (3) The organization hadn't made commitment to the pertinent IT policy clear. For example: The network user do not have high certainty that audit controls and procedures will be in place will detect their infraction and remove unauth'd equipment. If they are made certain a violation will be detected, and receive investigation, the rate of non-compliance could be expected to decrease. > Sometimes it's cheaper to give people what they want than to prevent > them taking it. Maybe at least consider that as an option. That depends on what 'they want'; and what regulations apply to the organization. The feds may force various organizations into saying no, even if network users want it, and the org. would prefer to allow it. If what the network users want is an unmanaged personal device on a corporate intranet, there are security considerations, which have a non-zero level of risk, that might be judged too high. Bandwidth and potentially firewall user licenses for i-devices to have continuous Facebook and Youtube access are not free. The possibility of required incident management for potential abuse cases. Possible SOX requirements to archive Twitter/Facebook "status update" message traffic etc. etc. > Regards, K. > Karl Auer (ka...@biplane.com.au) -- -JH
Re: Please, talk me down.
> First off, I'm using djbdns internally and it doesn't support > records. So we really aren't using it internally. if the clutch in my car is broken, should i stop using vehicles? dump djbdns or get some diehard to tell you how to fix it. randy
Re: Please, talk me down.
On 2012-10-16 21:35, Joseph Anthony Pasquale Holsten wrote: I want to like IPv6. I do. But I'm seriously considering turning off IPv6 support from our servers. First off, I'm using djbdns internally and it doesn't support records. So we really aren't using it internally. It sounds like this is a djbdns problem, not an IPv6 problem. FWIW, DJB's public take on IPv6 can be found here: http://cr.yp.to/djbdns/ipv6mess.html . Judging by the lack of updates in the past 10 years (OK, 10 years next month), I'm not certain whether his position has changed. (Granted, some of the ten-year-old facts have, so who knows.) Personally, I didn't agree with his perspective at the time, and I feel it's only gotten less valid over time. But today I noticed that we have a lot of traffic to our DNS cache, and started to investigate. Turns out that every DNS request would start with one for the record. Ah, no luck. Maybe you forgot the search domain? Let's retry that DNS request with that tacked on. Failed again? Meanwhile, lets simultaneously try for the AA record then. Repeat. Are 2x the queries -- in exchange for future-proofing the network -- coming that close to overloading your DNS cache? You may want to re-evaluate the scalability of your cache. Or replace your DNS cache with something maintained in the last decade (I thought I was exaggerating, but the last changelog in 1.05 is 20010211), and deploy all your internal assets on IPv6 -- thus reducing the query load AND getting your systems ready for the future. I'm _this_ close to turning IPv6 off entirely. Anyone want to talk me off this ledge? Go right ahead. But first, what company is this, so the rest of us can know to avoid doing business? ;-) Jima
Re: Please, talk me down.
Upgrade djbdns to support IPV6? Think there is a patch for it... -mike Sent from my iPhone On Oct 16, 2012, at 20:36, Joseph Anthony Pasquale Holsten wrote: > I want to like IPv6. I do. But I'm seriously considering turning off IPv6 > support from our servers. > > First off, I'm using djbdns internally and it doesn't support records. > So we really aren't using it internally. > > But today I noticed that we have a lot of traffic to our DNS cache, and > started to investigate. Turns out that every DNS request would start with one > for the record. Ah, no luck. Maybe you forgot the search domain? Let's > retry that DNS request with that tacked on. Failed again? Meanwhile, lets > simultaneously try for the AA record then. Repeat. > > I'm _this_ close to turning IPv6 off entirely. Anyone want to talk me off > this ledge? > -- > http://josephholsten.com
Re: Please, talk me down.
On Wed, 17 Oct 2012, Joseph Anthony Pasquale Holsten wrote: But today I noticed that we have a lot of traffic to our DNS cache, and started to investigate. Turns out that every DNS request would start with one for the record. Ah, no luck. Maybe you forgot the search domain? Let's retry that DNS request with that tacked on. Failed again? Meanwhile, lets simultaneously try for the AA record then. Repeat. You're describing normal behaviour. Why do you feel the behaviour you're seeing is a problem? Because you're not running IPv6, you're seeing twice the DNS traffic in some cases. Doing multiple lookups for everything in search domain is done for IPv4 as well. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Please, talk me down.
I want to like IPv6. I do. But I'm seriously considering turning off IPv6 support from our servers. First off, I'm using djbdns internally and it doesn't support records. So we really aren't using it internally. But today I noticed that we have a lot of traffic to our DNS cache, and started to investigate. Turns out that every DNS request would start with one for the record. Ah, no luck. Maybe you forgot the search domain? Let's retry that DNS request with that tacked on. Failed again? Meanwhile, lets simultaneously try for the AA record then. Repeat. I'm _this_ close to turning IPv6 off entirely. Anyone want to talk me off this ledge? -- http://josephholsten.com
Re: best way to create entropy?
On 10/16/12, JC Dill wrote: It's interesting... though Lava lamps require heat to work, so not necessarily energy efficient. In theory, you shouldn't really need the lava lamp part. Just the digital camera part.. operate at a high ISO, say ISO 3000, dark background, and manual shutter and aperature controls, configured to achieve exposure with minimal light (E.g. a lowest possible usable exposure at the highest speed you can get), analyze, and discard the value of any pixels that statistically show as "hot" or "correlated" and capture the inherent CCD sensor noise due to unpredictability of electrons, which you maximized, without having to have any movement in the scene. > You might want to take a look at: > http://www.lavarnd.org/news/lavadiff.html > jc -- -JH
Re: 14 years ago today....
- Original Message - > From: "Rodney Joffe" > ... we lost Jon. > > http://www.ietf.org/rfc/rfc2468.txt Be liberal in what you accept, and conservative in what you send. I don't remember the timing; did Jon borrow that from Fidonet's "Be ye not overly annoying, nor too easily annoyed"? Or the other way 'round? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: processing passwords?
- Original Message - > From: "Jean-Pierre A. Radley" > | $ JRA=test echo $JRA > | > | does not work in the superficially obvious manner, but it makes > | sense > | after I think about it -- it's like trying to use sudo with > | redirection. > | > | That behavior is documented back to the v7 shell, I'm pretty sure, > | though > | my v7 UPM is at home. > | > > Your shell isn't behaving like mine, in that case. I start out in tcsh > and: > > jpradley:appl 6 sh > $ unset JPR > $ JPR=test echo $JPR > > $ echo $JPR > test tcsh, not especially to my surprise, does not meet the SVID or POSIX, then. _Unix Shell Programming_, Kochan and Wood, 1985, Hayden, p 251: "Another Way To Pass Variables To A Subshell If you want to send the value of a variable to a subshell, there's another way to do it besides setting the variable and then exporting it. On the command line, you can precede the name of the command with the assignment of as many variables as you want. For example: DBHOME=/unx2/data DBID=452 dbrun places the variables DBHOME and DBID, and their indicated values, into the environment of dbrun, and then dbrun gets executed. *These variables will not be known to the current shell; they're created only for the execution of dbrun.*" (Emphasis mine). Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Internet-wide port scans
On 10/16/12, Darius Jahandarie wrote: > On Tue, Oct 16, 2012 at 12:57 AM, Scott Weeks > wrote: > I always thought it wasn't allowed because of 18 USC § 2701, but > IINAL, would be happy to hear otherwise :). 18 USC 2701 is not necessarily the only consideration. I would rather say that there might be a risk of criminal and civil liability, for all entities intentionally participating in, assisting as accomplices in, or facilitating as service provider, software provider, providers of information or operating instructions, etc, for, anyone conducting or intentionally assisting an unauthorized port scan of a different ISP's address space, that varies with jurisdiction, and you should consult your counsel, to determine if any precautions are appropriate to manage the risk, such as obtaining proper Letters of authorization from IP address assignees in advance, or if the responsible entity determines that you must abstain from the activity entirely, because the risk level is too high. By definition a reputable service, will not have a policy that you may execute internet-wide port scans of arbitrary ports that include IP networks/addresses that are not either assigned to you, your ISP customer, or that you have specific written permission to scan, as they will want to manage the risks to themselves properly as well. Port scans are strongly associated with malicious activity. And there are other risks of adverse actions, besides legal ones, such as the service provider's address space becoming widely blacklisted or becoming depeered. Before a network service provider offers any kind of service that permits the SPs' services to be used for arbitrary port scans of other remote networks, they are likely to have taken steps to protect themselves, by setting some terms of use and policy restrictions on what conditions and parameters must be met, before a scan is allowed. > Darius Jahandarie -- -JH
Re: Detection of Rogue Access Points
On Mon, Oct 15, 2012 at 04:31:34PM -0700, Joe Hamelin wrote: > I think it would be cheaper to have a script written that would grab the > ARP table of each site and then compare to what is known. Kind of an ARP > tripwire. Netdisco does this, and more (reports on ports which have more than 1 MAC address, devices from known wireless manufacturers, search MAC address by manufacturer, etc). http://www.netdisco.org/
Re: best way to create entropy?
On Sat, Oct 13, 2012 at 11:11:20PM +0100, Jasper Wallace wrote: > and with ekeyd-egd-linux you can distribute the entropy from an entropykey > over the net - great for giving vm some randomness. You would then be interested in http://hundun.ae7.st. Server I setup just a week or so ago doing this very thing. However, if using a server's random data, it's important you mix it into your /dev/random device, rather than using the data directly. After all, how can you trust the admin, that he's not keeping track of which client is receiving which data? -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o pgp1DdYvJwhzK.pgp Description: PGP signature
Re: Internet-wide port scans
On Tue, 16 Oct 2012 11:38:52 -0400, Darius Jahandarie said: > In particular, my understanding was that since you're sending a SYN, > it could very well initiate access to stored communications (although What 18 USC 2701 actually says, courtesy of www.law.cornell.edu: "Offense. - Except as provided in subsection (c) of this section whoever: (1) intentionally accesses without authorization a facility through which an electronic communication service is provided; or (2) intentionally exceeds an authorization to access that facility; and thereby obtains, alters, or prevents authorized access to a wire or electronic communication while it is in electronic storage in such system shall be punished as provided in subsection (b) of this section." First off, I believe (but don't have citation handy) there's actual case law that says that a SYN scan doesn't count as "access" (either without or exceeding authorization). And that's *stored* communications (in other words, your mail spool, not mail in-flight). You're better off chasing 18 USC 2511 (wiretapping, where the bits are in motion), and of course the 800 pound gorilla would be 18 USC 1030 (Fraud and related activity in connection with computers). And I'm pretty sure that an NMAP scan doesn't rise to the definition of 'accessed' for any of those. Of course, if the answer actually matters, ask a competent lawyer you've paid for advice. ;) pgp0nPrEmWEP5.pgp Description: PGP signature
Re: Internet-wide port scans
On Tue, Oct 16, 2012 at 9:46 AM, wrote: > On Tue, 16 Oct 2012 08:48:47 -0400, Darius Jahandarie said: >> On Tue, Oct 16, 2012 at 12:57 AM, Scott Weeks wrote: >> > Want to re-write that section or should I respond now? ;-) >> >> I always thought it wasn't allowed because of 18 USC 2701, but >> IINAL, would be happy to hear otherwise :) > > If a portscan allows access to stored communications, you have bigger > problems. In particular, my understanding was that since you're sending a SYN, it could very well initiate access to stored communications (although that may have not been the intent of the SYN). But maybe I'm wrong -- and even if I'm right, this seems like something that probably wouldn't hold in court very well anyways. -- Darius Jahandarie
Re: Internet-wide port scans
- Original Message -
> From: "Scott Weeks"
> From: Darius Jahandarie
>
> Either way, in the US at least, it's not legal to port scan random
> machines on the internet, so this was a rather useless exercise. (And
> --
>
> Want to re-write that section or should I respond now? ;-)
I was gonna say {{citation-needed}}, myself, but yeah: "Huh?"
Cheers,
-- jra
--
Jay R. Ashworth Baylink j...@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA #natog +1 727 647 1274
Re: Internet-wide port scans
On Tue, 16 Oct 2012 08:48:47 -0400, Darius Jahandarie said: > On Tue, Oct 16, 2012 at 12:57 AM, Scott Weeks wrote: > > Want to re-write that section or should I respond now? ;-) > > I always thought it wasn't allowed because of 18 USC 2701, but > IINAL, would be happy to hear otherwise :) If a portscan allows access to stored communications, you have bigger problems. pgpS7298U95u0.pgp Description: PGP signature
Re: Internet-wide port scans
On Tue, Oct 16, 2012 at 12:57 AM, Scott Weeks wrote: > Want to re-write that section or should I respond now? ;-) I always thought it wasn't allowed because of 18 USC § 2701, but IINAL, would be happy to hear otherwise :). -- Darius Jahandarie
Re: 100.100.0.0/24
On 16/10/2012 11:37, Lowe, Richard B wrote: > Kind of like the 192.0.2.1/32 for IPv4, huh? no - 192.0.2.0/24 is formally "TEST-NET-1, documentation and examples", like 2001:db8::/32. 100::/64 is specifically for discard and analysis style RTBHs. I.e. for ipv6, you can now keep your documentation prefixes on your documentation. Nick > RFC: 5635 > > -Original Message- > From: Nick Hilliard [mailto:n...@foobar.org] > Sent: Sunday, October 07, 2012 6:40 AM > To: nanog@nanog.org > Subject: Re: 100.100.0.0/24 > > On 07/10/2012 00:34, Randy Bush wrote: >> ipv6 route 2001:DB8:0:DEAD:BEEF::1/128 Null0 > > plug: rfc . > > 100::/64 is reserved for this purpose. > > Nick > > > >
Re: Detection of Rogue Access Points
On Mon, Oct 15, 2012 at 09:00:56AM -0700, Joe Hamelin wrote: > On Mon, Oct 15, 2012 at 8:54 AM, Roy wrote: > > Why not give them wireless Internet access only? That will keep all the > > smartphone users happy. > Maybe because he has 130 sites and 130 truck rolls is not cheap. Also > company policy says no. So stick a pre-configured device in the post, with instructions on how and where to plug it in. -- David Cantrell | top google result for "topless karaoke murders" "Cynical" is a word used by the naive to describe the experienced. George Hills, in uknot
Re: best way to create entropy?
On 11/10/12 5:01 PM, shawn wilson wrote: in the past, i've done many different things to create entropy - encode videos, watch youtube, tcpdump -vvv > /dev/null, compiled a kernel. but, what is best? just whatever gets your cpu to peak or are some tasks better than others? You might want to take a look at: http://www.lavarnd.org/news/lavadiff.html jc
Search DSL Supplier in Italy
Hi I am search good DSL (Adsl/Sdsl/EFM) supplier in Italy. delivred in ATM, L2TP or EThernet Vlan (no internet) Contact me best regards Olivier
Re: Internet-wide port scans
Have a look at the talks done by Fyodor the creator of Nmap "Scanning the Internet". http://nmap.org/presentations/BHDC08/bhdc08-slides-fyodor.pdf http://www.securitytube.net/video/170 http://blog.thc.org/index.php?/archives/2-Port-Scanning-the-Internet.html Also if you are look for a host CloudSigma are open to Security Researches using their VPS system for this kind of work. http://www.cloudsigma.com/ On 16 Oct 2012 05:59, "Scott Weeks" wrote: > > > --- djahanda...@gmail.com wrote: > From: Darius Jahandarie > > Either way, in the US at least, it's not legal to port scan random > machines on the internet, so this was a rather useless exercise. (And > -- > > > Want to re-write that section or should I respond now? ;-) > > scott > >
