August 2006 - NZNOG - lists.nznog.org

Re: [nznog] Domain Registration scam
by Scott Weeks 06 Aug '06

06 Aug '06

----- Original Message Follows ----- From: "Craig Whitmore" <lennon(a)orcon.net.nz> To: "Jeremy Strachan" <JeremyS(a)cclnz.co.nz>, "NZNOG" <nznog(a)list.waikato.ac.nz> > > I see this scam is back again, obviously using out of > http://www.nzdomainregistration.com/ hosted at nac.net > with no website . Did anyone send email to abuse(a)nac.net? scott

2 1

Domain Registration scam
by Jeremy Strachan 06 Aug '06

06 Aug '06

I see this scam is back again, obviously using out of date Domain registration information, and mass mail drops. I've probably received 20 letters today to register domains we don't have. Presumably it's the same culprit as the previous two occasions.

2 1

Notification of NZRR Database changes
by NZRR Database Notifications 06 Aug '06

06 Aug '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS10022 descr: advertised to AS9560 by Datacom - AS10022 members: 202.175.128.0/21^21-29, 202.14.20.0/22^22-29, 202.14.82.0/23^23-29, 202.36.198.0/23^23-29, 192.203.216.0/24^24-29, 202.14.84.0/24^24-29, 202.27.76.0/24^24-29, 202.27.140.0/24^24-29, 202.27.143.0/24^24-29, 202.27.250.0/24^24-29, 202.36.233.0/24^24-29, 210.55.5.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: idc(a)datacom.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060602 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS10022 descr: advertised to AS9560 by Datacom Systems Auckland - AS10022 members: 202.36.8.0/21^21-29, 202.175.128.0/21^21-29, 202.14.20.0/22^22-29, 202.14.82.0/23^23-29, 202.36.198.0/23^23-29, 192.203.216.0/24^24-29, 202.14.84.0/24^24-29, 202.27.76.0/24^24-29, 202.27.140.0/24^24-29, 202.27.143.0/24^24-29, 202.27.250.0/24^24-29, 202.36.233.0/24^24-29, 210.55.5.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: idc(a)datacom.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060807 source: NZRR

1 0

Yet another trademe scam...
by Mark Foster 05 Aug '06

05 Aug '06

http://www.blakjak.net/node/548 Rather cleverly created, doesn't look forged unless you're fairly onto it. ISPs may like to null-route the IP the HREF points at. Trademe - you probably also need to know. Regards Mark.

3 2

Weird DNS Problems
by Jithen Singh 04 Aug '06

04 Aug '06

Hey Guys, Was wondering if anyone could help out with this. Just two days ago we started to experience DNS problems resolving international addresses. The DNS servers are configured with no forwarders and go directly out. We can resolve NZ addresses but nothing else. Norhing's changed on the DNS severs and the problem just started happening. Link is going out on Citylink through to ICONZ. Any ideas? or help? Cheers J > intergen.co.nz Server: ns1.eaglegis.co.nz Address: 210.48.106.196 Name: intergen.co.nz Address: 202.49.144.165 > google.com Server: ns1.eaglegis.co.nz Address: 210.48.106.196 DNS request timed out. timeout was 2 seconds. *** Request to ns1.eaglegis.co.nz timed-out > nzpost.co.nz Server: ns1.eaglegis.co.nz Address: 210.48.106.196 Name: nzpost.co.nz Address: 202.12.249.9

3 3

Screening 2.4Ghz AP's?
by Simon Blake 02 Aug '06

02 Aug '06

While we're on the subject of subfunctional wireless links, does anybody know of a simple way of reducing the RF output from a functioning AP? Basically, I'd like to find a way to mute an AP while it's being setup, so that it doesn't affect other users of production AP's near by (in the same SSID). I'm thinking putting it in a box surrounded with a bunch of (non frozen) plastic freezer packs might be the go, but I'd be interested to know if anybody has any other cunning ideas. We could disable the RF or remove aerials, but that adds extra steps - I'm looking for something that could sit on a desk that the AP could be dropped in while somebody is working on the console. Cheers Si

8 8

Notification of NZRR Database changes
by NZRR Database Notifications 02 Aug '06

02 Aug '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: filter-set: fltr-unallocated descr: Unallocated (by IANA) IPv4 prefixes. filter: {1.0.0.0/8^+, 2.0.0.0/8^+, 5.0.0.0/8^+, 7.0.0.0/8^+, 23.0.0.0/8^+, 27.0.0.0/8^+, 31.0.0.0/8^+, 36.0.0.0/8^+, 37.0.0.0/8^+, 39.0.0.0/8^+, 42.0.0.0/8^+, 49.0.0.0/8^+, 50.0.0.0/8^+, 77.0.0.0/8^+, 78.0.0.0/8^+, 79.0.0.0/8^+, 92.0.0.0/8^+, 93.0.0.0/8^+, 94.0.0.0/8^+, 95.0.0.0/8^+, 96.0.0.0/8^+, 97.0.0.0/8^+, 98.0.0.0/8^+, 99.0.0.0/8^+, 100.0.0.0/8^+, 101.0.0.0/8^+, 102.0.0.0/8^+, 103.0.0.0/8^+, 104.0.0.0/8^+, 105.0.0.0/8^+, 106.0.0.0/8^+, 107.0.0.0/8^+, 108.0.0.0/8^+, 109.0.0.0/8^+, 110.0.0.0/8^+, 111.0.0.0/8^+, 112.0.0.0/8^+, 113.0.0.0/8^+, 114.0.0.0/8^+, 115.0.0.0/8^+, 116.0.0.0/8^+, 117.0.0.0/8^+, 118.0.0.0/8^+, 119.0.0.0/8^+, 120.0.0.0/8^+, 173.0.0.0/8^+, 174.0.0.0/8^+, 175.0.0.0/8^+, 176.0.0.0/8^+, 177.0.0.0/8^+, 178.0.0.0/8^+, 179.0.0.0/8^+, 180.0.0.0/8^+, 181.0.0.0/8^+, 182.0.0.0/8^+, 183.0.0.0/8^+, 184.0.0.0/8^+, 185.0.0.0/8^+, 186.0.0.0/8^+, 187.0.0.0/8^+, 197.0.0.0/8^+, 223.0.0.0/8^+} remarks: For the complete set of bogons, please see: fltr-martians - special use and reserved prefixes. fltr-bogons - fltr-unallocated + fltr-martian. http://www.cymru.com/Documents/bogon-list.html admin-c: RTH32-ARIN tech-c: RTH32-ARIN notify: radb(a)cymru.com notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-BOGON-FILTERS changed: rpsl-admin(a)nzix.net 20040819 changed: rpsl-admin(a)nzix.net 20060113 source: NZRR REPLACED BY: filter-set: fltr-unallocated descr: Unallocated (by IANA) IPv4 prefixes filter: { 1.0.0.0/8^+, 2.0.0.0/8^+, 5.0.0.0/8^+, 7.0.0.0/8^+, 23.0.0.0/8^+, 27.0.0.0/8^+, 31.0.0.0/8^+, 36.0.0.0/8^+, 37.0.0.0/8^+, 39.0.0.0/8^+, 42.0.0.0/8^+, 49.0.0.0/8^+, 50.0.0.0/8^+, 77.0.0.0/8^+, 78.0.0.0/8^+, 79.0.0.0/8^+, 92.0.0.0/8^+, 93.0.0.0/8^+, 94.0.0.0/8^+, 95.0.0.0/8^+, 96.0.0.0/8^+, 97.0.0.0/8^+, 98.0.0.0/8^+, 99.0.0.0/8^+, 100.0.0.0/8^+, 101.0.0.0/8^+, 102.0.0.0/8^+, 103.0.0.0/8^+, 104.0.0.0/8^+, 105.0.0.0/8^+, 106.0.0.0/8^+, 107.0.0.0/8^+, 108.0.0.0/8^+, 109.0.0.0/8^+, 110.0.0.0/8^+, 111.0.0.0/8^+, 112.0.0.0/8^+, 113.0.0.0/8^+, 114.0.0.0/8^+, 115.0.0.0/8^+, 116.0.0.0/8^+, 117.0.0.0/8^+, 118.0.0.0/8^+, 119.0.0.0/8^+, 120.0.0.0/8^+, 173.0.0.0/8^+, 174.0.0.0/8^+, 175.0.0.0/8^+, 176.0.0.0/8^+, 177.0.0.0/8^+, 178.0.0.0/8^+, 179.0.0.0/8^+, 180.0.0.0/8^+, 181.0.0.0/8^+, 182.0.0.0/8^+, 183.0.0.0/8^+, 184.0.0.0/8^+, 185.0.0.0/8^+, 186.0.0.0/8^+, 187.0.0.0/8^+, 197.0.0.0/8^+, 223.0.0.0/8^+ } remarks: For the complete set of bogons, please see: fltr-martians - special use and reserved prefixes fltr-bogons - fltr-unallocated + fltr-martian http://www.cymru.com/Documents/bogon-list.html admin-c: RTH32-ARIN tech-c: RTH32-ARIN notify: radb(a)cymru.com notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-BOGON-FILTERS changed: rpsl-admin(a)nzix.net 20040819 changed: rpsl-admin(a)nzix.net 20060113 changed: rpsl-admin(a)nzix.net 20060803 source: NZRR

1 0

Fwd: [Apnic-announce] APNIC debogon project
by Nurani Nimpuno 02 Aug '06

02 Aug '06

Fyi. APNIC is now allocating from the address ranges below. Cheers, Nurani --------------------------------------------------------------------- Nurani Nimpuno email: nurani(a)apnic.net Outreach coordinator, APNIC sip: nurani(a)voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 --------------------------------------------------------------------- Welcome to APNIC 22! Kaohsiung, Taiwan, 4-8 September 2006 http://www.apnic.net/meetings --------------------------------------------------------------------- Begin forwarded message: > From: John Tran <john(a)apnic.net> > Date: 3 August 2006 10:32:10 AM > To: apnic-announce(a)apnic.net > Cc: apops(a)apops.net, pacnog(a)pacnog.org, sanog(a)sanog.org > Subject: [Apnic-announce] APNIC debogon project > Reply-To: apnic-talk(a)apnic.net > > > Dear colleagues > > In January 2006, APNIC received the following IPv4 address ranges > from IANA: > > - 121/8 > - 122/8 > - 123/8 > > APNIC has started making allocations from these address ranges. > > To ensure these ranges are not being accidentally filtered, > selected prefixes from each /8 have been announced using AS12654. > > A reachability test can be done on each test prefix. A list of > "pingable" hosts and a daily visibility report for each prefix is > available here: > > http://www.ris.ripe.net/debogon/debogon.html > > If you need further assistance or have any concerns, please feel > free to contact us at <helpdesk(a)apnic.net>. > > Regards > ______________________________________________________________________ > __ > Son Tran email: > helpdesk(a)apnic.net > Resource Services Manager, APNIC sip: > helpdesk(a)voip.apnic.net > http://www.apnic.net/helpdesk phone: +61 7 3858 > 3188 > fax: +61 7 3858 > 3199 > ______________________________________________________________________ > __ > Welcome to APNIC 22! > Kaohsiung, Taiwan, 4-8 September 2006 http://www.apnic.net/meetings > _____________________________________________________________________ > > _______________________________________________ > Apnic-announce mailing list > Apnic-announce(a)lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/apnic-announce

1 0

Re: [nznog] Wireless link adversly affected by the sun?
by Michael Davies 02 Aug '06

02 Aug '06

Wow thanks for all the responses. In reply to Neil Fenemor: I can definitely see how thermal things like that and the way heat moves could effect things, the building we link to isn't too far away but the route as the crow flies is directly over the city and therefore a lot of asphalt and whatnot so I can see how that would cause problems. I imagine there's not a lot a lot that can be done to prevent/circumvent that other than changing to a different connection method. Irt Mark Foster & others regarding heat: This definitely sounds like something I'll have to look at further, I know the trango unit does have some kind of internal thermometer (probably for this very reason) so I'll look into a way of graphing the output from that. What kind of temperatures would be classed as too high? 40-50deg? Irt Dave, I'll reply off list. Cheers all, Michael Btw hopefully the weather keeps up, would be nice to see a warm end to winter :) ________________________________________ From: Ben Deller - Airnet NZ [mailto:ben(a)team.airnet.net.nz] Sent: Tuesday, 1 August 2006 4:22 p.m. To: Michael Davies Subject: RE: [nznog] Wireless link adversly affected by the sun? Hi Michael Perhaps try being more specific in isolating the problem. Is it latency and jitter in the wireless link or past the link out on another network (the internet)? Try the smokeping test to your ISP's network not the internet. Also have you checked you signal and noise levels on the wireless link? (Or asked your ISP to check this) It could be wireless interference from another network. Or it could just be too hot. Ben ________________________________________ From: Michael Davies [mailto:michael(a)hereisasite.co.nz] Sent: Tuesday, 1 August 2006 3:48 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] Wireless link adversly affected by the sun? Hi there, As the subject suggests, I've been noticing an interesting problem with our internet. We're lucky enough to be on the receiving end of a wireless net connection running through Trango broadband hardware, fairly conventional wireless tech. However I've noticed through monitoring the connection with smokeping to various places around the country that the connection quality seems to decrease dramatically through the middle of the day, but not every day. At first I thought that this was simply related to congestion somewhere, but from following the weather a bit I've started noticing that it gets worse on the nice sunny days. For example: Today, a balmy 17 degrees in Dunedin and beautifully sunny all day. Packet loss and jitter begins to increase at about 9am and peaks about 1pm with 60% loss, then at 2pm as if flicking a switch it returns to nearly 0% loss. From looking at the graphs over time, this does happen quite often but not every day and the loss today is definitely the worst I've seen it (but also the warmest/sunniest day we've had in Dunedin for quite a while). Has anyone seen or heard of this happening before? Would there be any way to prevent this - supposing that the sun is the culprit - short of installing a Mr. Burns type sun shield? Regards, Michael

3 3

Wireless link adversly affected by the sun?
by Michael Davies 01 Aug '06

01 Aug '06

Hi there, As the subject suggests, I've been noticing an interesting problem with our internet. We're lucky enough to be on the receiving end of a wireless net connection running through Trango broadband hardware, fairly conventional wireless tech. However I've noticed through monitoring the connection with smokeping to various places around the country that the connection quality seems to decrease dramatically through the middle of the day, but not every day. At first I thought that this was simply related to congestion somewhere, but from following the weather a bit I've started noticing that it gets worse on the nice sunny days. For example: Today, a balmy 17 degrees in Dunedin and beautifully sunny all day. Packet loss and jitter begins to increase at about 9am and peaks about 1pm with 60% loss, then at 2pm as if flicking a switch it returns to nearly 0% loss. From looking at the graphs over time, this does happen quite often but not every day and the loss today is definitely the worst I've seen it (but also the warmest/sunniest day we've had in Dunedin for quite a while). Has anyone seen or heard of this happening before? Would there be any way to prevent this - supposing that the sun is the culprit - short of installing a Mr. Burns type sun shield? Regards, Michael

16 15