ISC/F-Root are now live on the APE with IPv6: AS 23710 2001:7fa:4:c0cb::9a62 2001:7fa:4:c0cb::9a63 http://www.isc.org/peering We'll be advertising 2001:500::/48, the F-root prefix [*]. The corresponding AAAA record for F (2001:500::1035) is not in the root zone, yet, so this can be considered pre-production at this time. An application to add the AAAA record is pending with the IANA, however. If anybody would like to set up a native v6 session over the APE, we would be very pleased to peer. We are already peering with the Citylink v6ix route server at the APE, and so people peering with that (or with its counterpart at the WIX) should be able to see us with no additional work [*]. Many thanks to Juniper for their continued support of F in New Zealand: http://www.juniper.net/company/presscenter/pr/2005/pr-050208.html I wonder how many spam filters are going to object to "v6 APE action". [*] the network bits are done; 2001:500::/48 won't actually propagate until the servers have finished their v6alisation, which should happen in the next day or so.
I'm wondering what sort of traffic goes to ISC servers, could this be made
public, possibly mrtg graphs :)
Barry
----- Original Message -----
From: "Joe Abley"
ISC/F-Root are now live on the APE with IPv6:
AS 23710
2001:7fa:4:c0cb::9a62 2001:7fa:4:c0cb::9a63
We'll be advertising 2001:500::/48, the F-root prefix [*]. The corresponding AAAA record for F (2001:500::1035) is not in the root zone, yet, so this can be considered pre-production at this time. An application to add the AAAA record is pending with the IANA, however.
If anybody would like to set up a native v6 session over the APE, we would be very pleased to peer. We are already peering with the Citylink v6ix route server at the APE, and so people peering with that (or with its counterpart at the WIX) should be able to see us with no additional work [*].
Many thanks to Juniper for their continued support of F in New Zealand:
http://www.juniper.net/company/presscenter/pr/2005/pr-050208.html
I wonder how many spam filters are going to object to "v6 APE action".
[*] the network bits are done; 2001:500::/48 won't actually propagate until the servers have finished their v6alisation, which should happen in the next day or so.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
On 22 Feb 2005, at 22:56, Barry Murphy wrote:
I'm wondering what sort of traffic goes to ISC servers, could this be made public, possibly mrtg graphs :)
In normal operation F in Auckland answers a couple hundred queries per second at peak, corresponding to a client catchment of most of New Zealand's Internet (excluding 4648, who we have no way to reach at present). F as a whole (all nodes) normally answers a little under 10,000 queries per second. The Auckland node is engineered to deal with flash crowds (e.g. wildfire lookups of "WORKGROUP" by new and exciting windows worms) and denial-of-service traffic which fills the wire, which in this case means the two 100M connections to the APE. Short-term incidents which exceed the usual query rate by a factor of 10 or more are not uncommon (F as a whole saw around 80,000 queries per second for a short period about three weeks ago, for example). Graphs for the last 24 hours or so are attached. Real-time graphs are published through ISC's OARC (https://oarc.isc.org/) where work is also taking place to do fine-grained instrumentation of F-root traffic globally under a US NSF grant that ISC and CAIDA were recently awarded. Times below are UTC. Joe
Joe Abley wrote:
The Auckland node is engineered to deal with flash crowds (e.g. wildfire lookups of "WORKGROUP" by new and exciting windows worms)
That sounds more like the default Windows networking installation looking for its WORKGROUP workgroup rather than a worm. 'man pf' -- Juha
On 23 Feb 2005, at 15:10, Juha Saarinen wrote:
Joe Abley wrote:
The Auckland node is engineered to deal with flash crowds (e.g. wildfire lookups of "WORKGROUP" by new and exciting windows worms)
That sounds more like the default Windows networking installation looking for its WORKGROUP workgroup rather than a worm.
There are plenty of examples of worms triggering DNS lookups as they go about their wormly business. I'm not talking about the general background level of junk queries from Windows and other boxes which are either misconfigured or contain poor DNS client implementations. Evi did a talk on this in Mount Wellington.
'man pf'
If you're suggesting that blocking 53/udp and 53/tcp would be an effective way to reduce query load on the roots, then yes, I'm sure that would be highly effective. (Simply turning them all off would probably be less effort, however.) Joe
Joe Abley wrote:
There are plenty of examples of worms triggering DNS lookups as they go about their wormly business. I'm not talking about the general background level of junk queries from Windows and other boxes which are either misconfigured or contain poor DNS client implementations.
Evi did a talk on this in Mount Wellington.
So they look for WORKGROUP in DNS? Not weird SRV records or something for Active Directories?
If you're suggesting that blocking 53/udp and 53/tcp would be an effective way to reduce query load on the roots, then yes, I'm sure that would be highly effective. (Simply turning them all off would probably be less effort, however.)
Less drastic: 'man pf.os' -- Juha
On 23 Feb 2005, at 15:22, Juha Saarinen wrote:
So they look for WORKGROUP in DNS? Not weird SRV records or something for Active Directories?
You need to stop being so literal, I think.
If you're suggesting that blocking 53/udp and 53/tcp would be an effective way to reduce query load on the roots, then yes, I'm sure that would be highly effective. (Simply turning them all off would probably be less effort, however.)
Less drastic: 'man pf.os'
It's not obvious how that would manage to distinguish (a) source platforms on single-packet UDP requests or (b) requests that are received at the roots from intermediate-mode resolvers (to give Bill's new phrase some currency) which would mask the platform of the request's originator. It's also not obvious that blocking requests based on source operating system is anything that a root server operator ought to be considering, although what people decide to do on their own authority servers is their own business. Joe
Joe Abley wrote:
It's also not obvious that blocking requests based on source operating system is anything that a root server operator ought to be considering, although what people decide to do on their own authority servers is their own business.
As that cabbie in London once said: "there's only one way they'll learn". On a more serious note, if wormy traffic of various kinds could be fingerprinted with a reasonable degree of accuracy, it could be useful. -- Juha
On Thu, 24 Feb 2005, Juha Saarinen wrote:
On a more serious note, if wormy traffic of various kinds could be fingerprinted with a reasonable degree of accuracy, it could be useful.
There are papers out there on this, it's not that hard ( grep "MX" in the query logs for your DNS servers for a start) especially if you have spent the big bucks to log all the customer's traffic already. The hard bit is doing something with the list of customers once you have identified them. I gave a talk on this at nznog05, I assume you were in another one of the streams.. -- Simon J. Lyall. | Very Busy | Mail: simon(a)darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | eMT.
Simon Lyall
On Thu, 24 Feb 2005, Juha Saarinen wrote:
On a more serious note, if wormy traffic of various kinds could be fingerprinted with a reasonable degree of accuracy, it could be useful.
There are papers out there on this, it's not that hard ( grep "MX" in the query logs for your DNS servers for a start) especially if you have spent the big bucks to log all the customer's traffic already.
Most worms - both email-borne and the Sasser/Korgo/Welchia types - make snort light up like a Christmas tree. As you say, it's not hard to find infected machines.
The hard bit is doing something with the list of customers once you have identified them.
Disconnection works for me, but we're not exactly an ISP. The other option I suppose is to drop the user into some sort of quarantine area where they can obtain antivirus and OS updates and can't touch anything else. -- James Riden / j.riden(a)massey.ac.nz / Systems Security Engineer Information Technology Services, Massey University, NZ. GPG public key available at: http://www.massey.ac.nz/~jriden/
Evi did a talk on this in Mount Wellington.
So they look for WORKGROUP in DNS? Not weird SRV records or something for Active Directories?
http://www.caida.org/outreach/presentations/ietf0112/dns.damage.html Error Taxonomy, Bogus TLDs * 20% of the queries asked for a non-existant TLD o Includes the A queries above o Includes lots of internal Microsoft names (active directory) o Lots ending in .local, .localhost, .workgroup, .msft, .domain, etc.
participants (6)
-
Barry Murphy -
James Riden -
Joe Abley -
Juha Saarinen -
Matthew Luckie -
Simon Lyall