- NZNOG - lists.nznog.org

Re: [nznog] heads up to registries re Day in the Life of the Internet
by k claffy 27 Feb '08

27 Feb '08

hi folks, many of you have already heard about it, but we want to remind folks of the 'day in the life of the Internet' 2008 experiment: we're coordinating dns (and possibly other types of) measurements from a single (2)day period in mid-march 2008. we will repeat our simultaneous root server collections from 2007, and try to expand our coverage to include other TLDs, and hopefully data from other levels of the hierarchy, e.g., caching resolver data. we'd also like to compare statistics from secured vs unsecured zones. we're hoping this experiment provides data to help answer questions operators care about, e.g., IPv6 adoption, DNSSEC adoption, pollution to root servers, use of unallocated addresses in the wild, reverse DNS deployment, <send us your questions> (working list at: http://www.caida.org/projects/ditl/questions/ ) OARC is providing special support for this project, and Duane is executing some practice runs with participations this week, to test measurement/transport logistics. DNS-based participation should not require much work, ideally running 'dnscap' on/near DNS server(s) and sending the pcap files to OARC: (public.oarci.net) but there are other methods of participation too, depending on your policy constraints. (indexing data into datacat and controlling distribution of the data through your own AUP, or submitting more "cooked" data, e.g., logfile summaries, RRD graphs, reports based on data collected internally by networks during the DITL dates. if you are interested in donating the time and energy and (some form of) data to this project, please let duane, kenjiro, or me know and we'll get you started. URLs with details: http://www.caida.org/projects/ditl/ duane's nanog talk last week: http://www.caida.org/publications/presentations/2008/nanog_dw_ditl/ dns-specific guidance: http://www.caida.org/research/dns/roottraffic/dnsroot_measurement_recommend… thanks, k

1 0

YouTube "IP hijacking"
by Juha Saarinen 26 Feb '08

26 Feb '08

Fat thread on NANOG: http://www.merit.edu/mail.archives/nanog/msg06299.html Did anyone in NZ notice? -- Juha

5 7

NZRR Route Registry Update
by NZRR Database Notifications 26 Feb '08

26 Feb '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS24324 descr: advertised to AS9560 by Kordia - AS24324 members: 118.148.0.0/15^15-29, 124.157.64.0/19^19-29, 58.84.224.0/20^20-29, 116.89.224.0/20^20-29, 202.56.32.0/20^20-29, 202.68.80.0/20^20-29, 203.144.32.0/20^20-29, 117.104.176.0/21^21-29, 123.108.144.0/21^21-29, 202.20.0.0/21^21-29, 202.49.16.0/21^21-29, 202.49.128.0/21^21-29, 202.56.48.0/21^21-29, 202.137.240.0/21^21-29, 218.185.224.0/21^21-29, 202.27.88.0/23^23-29, 202.65.160.0/23^23-29, 202.174.190.0/23^23-29, 203.110.28.0/23^23-29, 116.90.132.0/24^24-29, 192.173.17.0/24^24-29, 202.21.130.0/24^24-29, 202.27.83.0/24^24-29, 202.27.90.0/24^24-29, 202.36.75.0/24^24-29, 202.36.137.0/24^24-29, 202.36.154.0/24^24-29, 202.36.173.0/24^24-29, 202.37.168.0/24^24-29, 202.37.197.0/24^24-29, 202.49.158.0/24^24-29, 202.49.183.0/24^24-29, 203.30.174.0/24^24-29, 203.171.4.0/24^24-29, 203.97.62.200/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: smc(a)kordia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080213 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS24324 descr: advertised to AS9560 by Kordia Limited - AS24324 members: 118.148.0.0/15^15-29, 124.157.64.0/19^19-29, 58.84.224.0/20^20-29, 116.89.224.0/20^20-29, 202.56.32.0/20^20-29, 202.68.80.0/20^20-29, 203.144.32.0/20^20-29, 117.104.176.0/21^21-29, 123.108.144.0/21^21-29, 202.20.0.0/21^21-29, 202.49.16.0/21^21-29, 202.49.128.0/21^21-29, 202.56.48.0/21^21-29, 202.137.240.0/21^21-29, 218.185.224.0/21^21-29, 202.27.88.0/23^23-29, 202.65.160.0/23^23-29, 202.174.190.0/23^23-29, 203.110.28.0/23^23-29, 116.90.132.0/24^24-29, 192.173.17.0/24^24-29, 202.21.130.0/24^24-29, 202.27.83.0/24^24-29, 202.27.90.0/24^24-29, 202.36.75.0/24^24-29, 202.36.137.0/24^24-29, 202.36.154.0/24^24-29, 202.36.173.0/24^24-29, 202.37.168.0/24^24-29, 202.37.197.0/24^24-29, 202.49.158.0/24^24-29, 202.49.183.0/24^24-29, 203.30.174.0/24^24-29, 203.92.25.0/24^24-29, 203.171.4.0/24^24-29, 203.97.62.200/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: smc(a)kordia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080227 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 26 Feb '08

26 Feb '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Ltd - AS17746 members: 60.234.0.0/16^16-29, 156.62.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 116.199.208.0/21^21-29, 210.54.56.0/21^21-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.175.142.0/23^23-29, 203.84.134.0/23^23-29, 192.203.216.0/24^24-29, 202.27.77.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.64/27^27-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: ricky.tipper(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071213 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Ltd - AS17746 members: 60.234.0.0/16^16-29, 121.98.0.0/16^16-29, 156.62.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 116.199.208.0/21^21-29, 210.54.56.0/21^21-29, 210.79.48.0/21^21-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.175.142.0/23^23-29, 203.84.134.0/23^23-29, 192.203.216.0/24^24-29, 202.27.77.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.64/27^27-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: ricky.tipper(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080227 source: NZRR ------------------------------------------------------------

1 0

OSPF on a Mac
by Matthew Poole 25 Feb '08

25 Feb '08

Greetings all Anyone know of any implementations of OSPF that run on OS X? Preferably something I don't have to build from source, but from what little I've found on Google thus far I don't think that's an option. -- Matthew Poole "Don't use force. Get a bigger hammer."

3 2

Orcon DSL (Beer Involved)
by Jasper Bryant-Greene 21 Feb '08

21 Feb '08

If there's anyone on the list from Orcon and/or Telecom who has the ability to provision Orcon DSL by midnight tonight to a Wellington address for a broadband monitoring company who shall not be named, I would appreciate a ping off-list. Significant quantities of beer are involved. -jasper

1 0

Update to the IPv4 Registry¹s Format and Content
by Leo Vegoda 21 Feb '08

21 Feb '08

This message has been sent to several lists. I apologise for duplicates. IANA has improved the format for the IPv4 Address Space registry. At the same time, the entries that were marked ³Various Registries² have been replaced with references to the Regional Internet Registry (RIR) that provides WHOIS and reverse DNS service for that /8 allocation. If you want to machine-process the IPv4 registry, the new fields are: * Prefix * Designation * Date * Whois * Status * Note where the Date will always be of the form ³YYYY-MM² and the status has the following possible values: RESERVED, LEGACY, ALLOCATED and UNALLOCATED /8 allocations that contain legacy assignments in them that are now managed by the RIRs have the text ³Administered by² in the Designation column. Legacy assignments refer to IP address allocations made before the RIR system was established. Reserved address space held by IANA does not have a date listed. The registry can be found at: http://www.iana.org/assignments/ipv4-address-space If you have questions about the structure of the new format, please send e-mail to iana(a)iana.org. Kind regards, Leo Vegoda Manager, Number Resources - IANA

1 0

Using nolisting to reduce spam
by Glen Eustace 19 Feb '08

19 Feb '08

Yesterday, I came across the concept of 'nolisting' as a technique for reducing the volume of inbound spam. It wasn't something I had previously come across so have done some reading on the topic. http://nolisting.org as a starting point. For such a simple technique, I was surprised by its impact. Simply speaking, the idea is to use a primary MX that doesn't listen on port 25 but simply rejects the connection. Well behaved MTAs will all try the secondary MX(es) and delivery will occur. Many spambots only try the primary so there is an immediately benefit, less inbound to check in other ways and a consequential increase in the available resources on the mail server(s). I set it up on one domain and behavior seems to be exactly as described. My reading suggests that there is no negative impact on legitimate mail and no noticeable additional latency in delivery as the switch from the primary to secondary on a reject is almost instantaneous. I was wondering whether anyone else has had any experience with this technique and if so whether the claim that it has no negative impact is true. Also, if people haven't heard of it, it may be something people might want to look at as another weapon in the anti-spam war. Glen.

18 24

query_status: 440 Request Denied Another one bites the dust
by Barry Murphy 18 Feb '08

18 Feb '08

query_status: 440 Request Denied from 4 sources, including dnc site. Barry

3 2

DNS sub-domain best practice
by Matthew Poole 18 Feb '08

18 Feb '08

My employer (part of a large educational institution) is delegated a bunch of 4LD zones within our org's 3LD space. These are utilised in a flat fashion, with staff machines, lab machines and servers all present as hosts inside various 4LDs. One 4LD has literally thousands of For obvious reasons, I'd like to move at least some stuff into 5LD space, starting with the labs. However, when I suggested this, my boss shot me down with "Too much typing. If it's a problem then we should differentiate at the 4th level." The only way to deal with that kind of attitude would appear to be a formal proposal (there are other issues in our DNS that need to be tidied up, so it's not just a proposal for this one thing), and I want to include some industry references about best practice in zone structuring. However, Google's not being kind to me at present. All it wants to tell me about is AD and MS DNS, and we're using bind so that doesn't translate so well. Anyone got some guides that I can refer to when I talk about why we shouldn't be using the 4LD as our functional level for all things? -- ËMatthew Poole "Don't use force. Get a bigger hammer."

2 1