BitFolk Users February 2012

users@mailman.bitfolk.com

33 participants
14 discussions

by Robert Gauld

I'm currently toying with the idea of asking Andy to delegate the reverse lookup for my IP addresses to my name server rather than bothering him when I want to change them. I've been Googling to see what the zone file I'd need to create for this would look like and could only find resources on creating a zone for for an entire class C network, what would the zone file look like? (please either answer or point me to a resource I couldn't find) -- Robert Gauld http://www.robertgauld.co.uk

11 years, 3 months

IP address at Nominet's nameservers is wrong

by Ian

I am having problems with this - despite updating them (again) today, it is still showing the old IP address for one of the nameservers: Here's the BIND record, with the domain name changed: $ttl 10800 example.co.uk. IN SOA sub.example.co.uk. example.gmail.com. ( 2012021001 7200 3600 604800 10800 ) example.co.uk. IN NS sub.example.co.uk. example.co.uk. IN NS top.example.co.uk. example.co.uk. IN A 85.119.83.xx sub.example.co.uk. IN A 85.119.83.xx top.example.co.uk. IN A 85.119.83.yy mail.example.co.uk. IN A 85.119.83.xx ns1.example.co.uk. IN A 85.119.83.xx ns2.example.co.uk. IN A 85.119.83.yy *.example.co.uk. IN CNAME sub example.co.uk. IN MX 10 mail.example.co.uk. But here is what Nominet's whois says: Relevant dates: Registered on: 21-Apr-2009 Renewal date: 21-Apr-2013 Last updated: 10-Feb-2012 Registration status: Registered until renewal date. Name servers: sub.example.co.uk 212.13.195.xx top.example.co.uk 85.119.83.yy WHOIS lookup made at 12:42:49 10-Feb-2012 Note old IP address for sub.example.co.uk, even though the A record is clear it's the new address. Any suggestions as to what's going on gratefully received... Ian

11 years, 3 months

idle curiosity? bank phishing scam, was Fw: Notice ID:01ZMCX

by Max B

Hi bitfolkers, I was emailed today by a phish bot (copy withheld by yahoo spamguard) which seeks bank information. The scam appears to redirect victims to a location in Stanford (see www.81solutions.com/server-location.html) whose host is located in Austria: 171.66.18.10 resolved by scotiaonline.scotiabank.compan.for-some.biz I suspect this is a VPS, in an organisation similar to bitfolk, with a virus. Which leads me to ask some questions of this list: 1) Do I have a duty in law to maintain a phishbot-virus-free VPS? 2) Can a mandamus order shut down an innocent VPS owner whose server hosts a phishbot virus? 3) Has a bitfolk VPS owner ever been targetted by phishbots? If so, what were the symptoms and what were the ramifications? Cheers! Max

11 years, 3 months

Reboot scheduled for host "bellini", 2012-02-20 2200Z; host "president", 2012-02-21 2200Z

by Andy Smith

Hi folks, Short version: Two of our servers appear to be subject to a now fixed kernel bug affecting IPv6, and require a reboot for kernel upgrade. Host bellini.bitfolk.com will be rebooted on Monday 20th February at 2200Z. Provided that does fix the problem, host president.bitfolk.com will be similarly rebooted the following day, Tuesday 21st February also at 2200Z. Longer version: While investigating some recent reports of poor IPv6 performance, it seems that both bellini.bitfolk.com and president.bitfolk.com are affected by a bug in the igb Intel gigabit Ethernet driver as described here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630730 The symptoms are very poor IPv6 performance in the region of a maximum of 100kilobit/sec. On doing a tcpdump you will see packets of length greater than 1500 bytes, followed by an ICMP6 "packet too big" message coming from our server, and then a retransmit. These hosts have been up for 138 days (bellini) and 223 days (president), and unfortunately neither we nor any customers noticed any problems until recently. On casual inspection IPv6 works. It's only noticeable when trying to do a larger data transfer. Since the current impact is so low, I am not going to rush to reboot these hosts. I would rather give plenty of notice to those who need it. When it's time for the reboot we will shut down all VPSes on these servers cleanly, reboot the machine and then begin booting them up again. Downtime is expected to be in the region of 15 minutes. If you are in any doubt as to whether your VPS starts cleanly with all required services running, you should test this ahead of time. I am fairly confident that the problems observed are caused by that bug and therefore that a kernel upgrade will fix it, but unfortunately we do not have any other hardware that uses the igb driver. If doing the upgrade on bellini does not resolve the issue then we will have to consider our options. In the mean time, if your VPS is hosted on bellini or president then you may wish to set your VPS to prefer IPv4 DNS results ahead of IPv6 results: https://tools.bitfolk.com/wiki/IPv6#Preferring_IPv4_over_IPv6 Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

11 years, 3 months

Tor Obsfucation

by Daniel Case

Hey Guys, As you may have heard, over the last few weeks the Iranian government have come hard against all SSL/TLS encrypted traffic and stopped most of it getting through. I'm going to set this up on my server: https://lists.torproject.org/pipermail/tor-talk/2012-February/023070.html I was just wondering if there is any reason it would be violating any Bitfolk policies and any best practise tips you can give me to minimize any impact. Thank you, Daniel

11 years, 3 months

DNS hiccups

by Keith Williams

I got a warning email saying that c.authns.bitfolk.com was suffering s critical error, then very soon afterwards an email saying it was recovered. I did a quick check with intodns.com and all was well except this Same GlueLooks like the A records (the GLUE) got from the parent zone check are different than the ones got from your nameservers. You have to make sure your parent server has the same NS records for your zone as you do.I detected some problems as follows: For *c.authns.bitfolk.com* the parent reported: *['209.237.247.198']* and your nameservers reported: *['173.255.227.192']* Everytime I refresh it reports slightly differently with server c always reported as wrong sometimes all three Same Glue Looks like the A records (the GLUE) got from the parent zone check are different than the ones got from your nameservers. You have to make sure your parent server has the same NS records for your zone as you do.I detected some problems as follows: For *c.authns.bitfolk.com* the parent reported: *['85.119.80.222']* and your nameservers reported: *['173.255.227.192']* For *a.authns.bitfolk.com* the parent reported: *['85.119.80.222']* and your nameservers reported: *['85.119.80.222']* For *b.authns.bitfolk.com* the parent reported: *['85.119.80.222']* and your nameservers reported: *['209.237.247.198']* I assume there is some work going on with the servers as my domain is resolving Keith -- Keith Williams Of those who say nothing, few are silent. - Thomas Neill I'm sick of following my dreams. I'm just going to ask them where they're going and hook up with them later. - Mitch Hedberg ทำดีได้ดี ทำชั่วไดชั่ว I can picture in my mind a world without war, a world without hate. And I can picture us attacking that world, because they'd never expect it. - Jack Handey

11 years, 3 months

c.authns.bitfolk.com has been renumbered

by Andy Smith

Hello, If you don't make use of BitFolk's secondary DNS service then you can ignore this email as it has no impact on you. c.authns.bitfolk.com has been renumbered: 209.20.91.73 → 173.255.227.192 2001:4978:f:392::2 → 2600:3c03::31:2053 This actually has nothing to do with BitFolk's renumbering. c.authns used to be hosted at Slicehost which recently got bought by Rackspace, and they are also renumbering. Most people don't need to do anything. The glue record for c.authns.bitfolk.com has been updated so over the next couple of days the new IP will start being used. If you have made your own DNS records that pointed at 209.20.91.73 or 2001:4978:f:392::2 (for example if you made nameserver host names inside your own domain(s)) then you will need to update them. It is recommended not to use such names because of the need to change them in so many places. You may also have ACLs that allow zone transfer from 209.20.91.73. These normally don't get used since the BitFolk nameservers try to do zone transfer from each other first. If you do have such an ACL then you will need to update it. 209.20.91.73 and 2001:4978:f:392::2 will go away on 19th March. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

11 years, 3 months

Renumbering: resolver not working? still points to 212.x, instead of 85.y on >=1 machine

by Max B

Hi all, thanks for everyone's response to my wiki proposal. I hadn't intended a flame war, and may respond selectively at a future date, when for instance, I am not faced with a puzzle, as follows. dig returns the correct value 85.y on my VPS. dig returns the old address 212.x elsewhere (at work). Should I be concerned? I must access the ethernet address to my VPS--not the name--from 'elsewhere'. I changed bind at least 24h ago. Is the 'expire' time* of 7 days (current setting) responsible for this, or is my problem more insidious? *the third entry after the 'serial number' in a bind config Thanks for any/all replies. Cheers, Max

11 years, 3 months

IMPORTANT: You need to renumber the IP address(es) of your BitFolk VPS

by Andy Smith

Dear customer, [ Apologies if you've received duplicate copies of this email; we felt it was of sufficient importance to send direct to the contacts for each account. ] If you've been following our mailing lists you'll know that the time has come where we need you to change the IP address(es) associated with your VPS. Basically: - For each IP address on your VPS you need to enable a new address, which has already been routed to you. - You then need to reconfigure your services to use only the new IP addresses. - Finally you need to disable the old IP addresses. Full information on what you need to do can be found here: https://tools.bitfolk.com/wiki/Renumbering_for_customers The next time you need to reboot your VPS you should take care to instead shut it down and boot it again from your Xen Shell, otherwise you will lose the routes to the new IP addresses that have been added. The old IP addresses will be disabled approximately *three months* from now, so if you don't make these changes before then YOU WILL EXPERIENCE A LOSS OF SERVICE. Therefore if you have any questions please do not hesitate to ask, preferably on our users list: https://lists.bitfolk.com/mailman/listinfo/users Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

11 years, 3 months

VPS renumbering failure

by Paul Stimpson

Hi, Due to a punishing workload, I left my renumbering to the last minute and it's not worked right. Here is my new /etc/network/interfaces: > auto lo > iface lo inet loopback > > auto eth0 > iface eth0 inet static > address 85.119.82.73 > netmask 255.255.248.0 > gateway 85.119.80.1 > > auto eth0:1 > iface eth0:1 inet static > address 85.119.82.67 > netmask 255.255.255.255 > > auto eth0:2 > iface eth0:2 inet static > address 212.13.194.73 > netmask 255.255.255.255 > > auto eth0:3 > iface eth0:3 inet static > address 212.13.194.67 > netmask 255.255.255.255 ip -4 addr show dev eth0 > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > state UNKNOWN qlen 1000 > inet 85.119.82.73/21 brd 85.119.87.255 scope global eth0 > inet 85.119.82.67/32 brd 85.255.255.255 scope global eth0:1 > inet 212.13.194.73/32 brd 212.13.194.255 scope global eth0:2 > inet 212.13.194.67/32 brd 212.13.194.255 scope global eth0:3 ip -4 route show > 10.26.0.2 dev tun0 proto kernel scope link src 10.26.0.1 > 10.26.0.0/24 via 10.26.0.2 dev tun0 > 85.119.80.0/21 dev eth0 proto kernel scope link src 85.119.82.73 > default via 85.119.80.1 dev eth0 /etc/resolv.conf > nameserver 85.119.80.232 > nameserver 85.119.80.233 I can still ping and ssh the old 212 addresses. When I'm logged in, I can't ping 85.119.80.1 and dig says that there are no DNS servers available. I can ping both 212 addresses from outside but neither of the 85 addresses. I'd be really grateful if someone would point out my stupid and obvious mistake. Thanks, Paul.

11 years, 3 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

BitFolk Users February 2012