Hi list, this is my first post, so be nice. :) Wondering about IPv6 deployments to end-users, imagine we deploy a full /48 address to each client. How is the reverse DNS for each possible IPv6 address going to be? Nowadays I'm used to do IPv4 reverse using old Class C, which has (up to) 256 entries. Are we really going to make reverse DNS entries for each of those 2^80 addresses? Or going to deploy rDNS only at the PtP links and relevant servers? Kind regards, Felipe
In message <v2s621b657f1004271721icf7c9237kcfb877b7785d1e73@mail.gmail.com>, Felipe Zanchet Grazziotin writes:
Hi list,
this is my first post, so be nice. :)
Wondering about IPv6 deployments to end-users, imagine we deploy a full /48 address to each client. How is the reverse DNS for each possible IPv6 address going to be?
Nowadays I'm used to do IPv4 reverse using old Class C, which has (up to) 256 entries. Are we really going to make reverse DNS entries for each of those 2^80 addresses? Or going to deploy rDNS only at the PtP links and relevant servers?
Kind regards, Felipe
Windows will just populate the reverse zone as needed, if you let it, using dynamic update. If you have properly deployed BCP 39 and have anti-spoofing ingres filtering then you can just let any address from the /48 add/remove PTR records. Other OS's will follow suite. Alternatively you can delegate the reverse for the /48 to servers run by the customers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote:
Windows will just populate the reverse zone as needed, if you let it, using dynamic update. If you have properly deployed BCP 39 and have anti-spoofing ingres filtering then you can just let any address from the /48 add/remove PTR records. Other OS's will follow suite.
Is DDNS really considered to be the end-all answer for this? It seems we're putting an awful lot of trust in the user when doing this.. I'd rather see some sort of macro expansion in bind/tinydns/etc that would allow a range of addresses to be added.
Alternatively you can delegate the reverse for the /48 to servers run by the customers.
This works for commercial customers, but I'm not sure I'd want to delegate this to a residential customer.
Mark
--------------------------- Jason 'XenoPhage' Frisvold xenophage@godshell.com --------------------------- "Any sufficiently advanced magic is indistinguishable from technology." - Niven's Inverse of Clarke's Third Law
Naïve question: If you used macro expansion, wouldn't you end up providing responses for a lot of addresses that aren't in use? Maybe that's not a problem? On Tue, Apr 27, 2010 at 8:47 PM, Jason 'XenoPhage' Frisvold <xenophage@godshell.com> wrote:
On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote:
Windows will just populate the reverse zone as needed, if you let it, using dynamic update. If you have properly deployed BCP 39 and have anti-spoofing ingres filtering then you can just let any address from the /48 add/remove PTR records. Other OS's will follow suite.
Is DDNS really considered to be the end-all answer for this? It seems we're putting an awful lot of trust in the user when doing this.. I'd rather see some sort of macro expansion in bind/tinydns/etc that would allow a range of addresses to be added.
Alternatively you can delegate the reverse for the /48 to servers run by the customers.
This works for commercial customers, but I'm not sure I'd want to delegate this to a residential customer.
Mark
--------------------------- Jason 'XenoPhage' Frisvold xenophage@godshell.com --------------------------- "Any sufficiently advanced magic is indistinguishable from technology." - Niven's Inverse of Clarke's Third Law
On Apr 27, 2010, at 8:50 PM, Richard Barnes wrote:
Naïve question: If you used macro expansion, wouldn't you end up providing responses for a lot of addresses that aren't in use? Maybe that's not a problem?
Presumably the op would only use macros where needed, ie dynamically assigned addresses. So, for a pool of addresses assigned for DSL/Cable/FIOS subscribers, that pool would have forward/reverse set up. Note: I am definitely not up on my IPv6 knowledge, so there may be a Really Good Reason(tm) that one should not do this.. However, I was under the impression that having both forward and reverse for dynamic IPs was a best practice.. --------------------------- Jason 'XenoPhage' Frisvold xenophage@godshell.com --------------------------- "Any sufficiently advanced magic is indistinguishable from technology." - Niven's Inverse of Clarke's Third Law
On Tue, Apr 27, 2010 at 7:58 PM, Jason 'XenoPhage' Frisvold <xenophage@godshell.com> wrote:
On Apr 27, 2010, at 8:50 PM, Richard Barnes wrote: ...However, I was under the impression that having both forward and reverse for >dynamic IPs was a best practice..
Perhaps we should back up a bit and delete 'how' from the subject line of this thread, and first ask 'Will it be done?' and where will RDNS be implemented? It is best practice within IPv4 networks. The IPv6 internet is a new network, and prevalent practices will not necessarily turn out to be what we consider best from V4. 'Best practice' is going to have to meet with administrative necessity in some form at some point. A reality may be that not all hosts necessarily have a meaningful hostname that they should be addressed by, or that the 'operator' (web browser user) wants to be known; Useful RDNS records may become more confined to hosts that actually provide a globally accessible service. Residential subscribers of ISP you-are-not-allowed-to-run-a-server level of DSL/Cable service will likely not have their own domain name, providing RDNS delegation would be mostly a waste of resources. Providing DDNS updates to RDNS is likely to be abused in various ways, even if it can be secured (malware would love this -- instant fully RDNS-cognizant mail server). The prevalent practice is almost certainly going to be for res. ISPs to provide a NXDOMAIN response to RDNS queries, or a generic response like is common with V4. Probably "custom RDNS" would be considered a business service, and like all business services, have its own pricing schedule, and involve subscriber providing IP addresses of DNS servers to delegate to. If Res. subscribers are lucky the big ISPs might provide a proprietary app to run on their PC to magically register it with RDNS, and enable for connectivity. With the downside that there can now be an enforced per-PC surcharge. Consumer DSL providers would probably love this.... $60/month, connectivity for one PC to the internet at X/speed included..... . $1/day extra for each additional PC registered with the DNS, $0.10/hour for each Xbox/gaming console/HTPC/Media streaming device registered for internet access. *zip bang voom* 4 years later... IPv6 NAT, the prevalent technology present in every $50 IPv6 router, an unofficial hack that might some day get an RFC made about it.... -- -J
On 4/27/2010 19:50, Richard Barnes wrote:
Naïve question: If you used macro expansion, wouldn't you end up providing responses for a lot of addresses that aren't in use? Maybe that's not a problem?
If you get a request, you will have to respond in any case. I have a theory about data-base lookups--finding something is always faster than not finding anything, unless you are using a human brain. (A human brain can respond "I don't know that" without an inventory of everything it does know.) (That may be to only truly unique thing about humans. And no, I have not kept up with neural networks work.) -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
<off-topic> <IANADBExpert> Interesting theory, but seems kind of wrong. Wouldn't the time to look up or fail be tied to the complexity of how the key space is populated? In any case, it seems like the time to succeed or fail will usually be about the same, since you'll try to access the value for a key and either find something there or fail. On Tue, Apr 27, 2010 at 9:19 PM, Larry Sheldon <LarrySheldon@cox.net> wrote:
On 4/27/2010 19:50, Richard Barnes wrote:
Naďve question: If you used macro expansion, wouldn't you end up providing responses for a lot of addresses that aren't in use? Maybe that's not a problem?
If you get a request, you will have to respond in any case.
I have a theory about data-base lookups--finding something is always faster than not finding anything, unless you are using a human brain.
(A human brain can respond "I don't know that" without an inventory of everything it does know.)
(That may be to only truly unique thing about humans. And no, I have not kept up with neural networks work.)
-- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner.
Freedom under a constitutional republic is a well armed lamb contesting the vote.
Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca
ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On 4/27/2010 20:25, Richard Barnes wrote:
<off-topic> <IANADBExpert>
Interesting theory, but seems kind of wrong. Wouldn't the time to look up or fail be tied to the complexity of how the key space is populated? In any case, it seems like the time to succeed or fail will usually be about the same, since you'll try to access the value for a key and either find something there or fail.
The theory is based on the notion that if you find something you stop looking for it. If what you are looking for is not there, you have to search all of the key-space, regardless of the index method. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On 4/27/2010 20:28, Larry Sheldon wrote:
On 4/27/2010 20:25, Richard Barnes wrote:
<off-topic> <IANADBExpert>
Interesting theory, but seems kind of wrong. Wouldn't the time to look up or fail be tied to the complexity of how the key space is populated? In any case, it seems like the time to succeed or fail will usually be about the same, since you'll try to access the value for a key and either find something there or fail.
The theory is based on the notion that if you find something you stop looking for it. If what you are looking for is not there, you have to search all of the key-space, regardless of the index method.
That is why, when I was actively designing (or supervising the design) of data-bases, we tried to make the most likely hits at the beginning of the key-space. In general, easier to say than to do. And not as intuitive as you might think. (In the old days, there was the closely related entertainment of predicting which benefited most from cached-disc systems, random files or sequential files.) -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Bloom filters work that way. Tony (on his iPod). -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ On 28 Apr 2010, at 02:19, Larry Sheldon <LarrySheldon@cox.net> wrote:
(A human brain can respond "I don't know that" without an inventory of everything it does know.)
(That may be to only truly unique thing about humans. And no, I have not kept up with neural networks work.)
On 4/28/2010 02:29, Tony Finch wrote:
Bloom filters work that way.
I charge the time to order, index, hash the key space so that can work. I don't know what a fair distribution of that cost would be.
Tony (on his iPod).
Larry on his.....oh, who cares? -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On Apr 27, 2010, at 5:47 PM, Jason 'XenoPhage' Frisvold wrote:
On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote:
Windows will just populate the reverse zone as needed, if you let it, using dynamic update. If you have properly deployed BCP 39 and have anti-spoofing ingres filtering then you can just let any address from the /48 add/remove PTR records. Other OS's will follow suite.
Is DDNS really considered to be the end-all answer for this?
Seems it is that or not bothering with reverse anymore.
It seems we're putting an awful lot of trust in the user when doing this.. I'd rather see some sort of macro expansion in bind/tinydns/etc that would allow a range of addresses to be added.
Hmm. A macro expansion for a /48 would mean 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test for name servers... :-). Slightly more seriously, there have been discussions in the past about doing dynamic synthesis of v6 reverses, but that gets icky (particularly if you invoke the dreaded "DNSSEC" curse) and I don't know any production server that actually does this now. Dynamic DNS is probably the least offensive solution if you really want reverses for your v6 nodes. Regards, -drc
On Apr 27, 2010, at 9:00 PM, David Conrad wrote:
Hmm. A macro expansion for a /48 would mean 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test for name servers... :-).
Um.. sure. :) Your computer can't handle that? How about a programmatic expansion? Only create the necessary record when asked for it.
Slightly more seriously, there have been discussions in the past about doing dynamic synthesis of v6 reverses, but that gets icky (particularly if you invoke the dreaded "DNSSEC" curse) and I don't know any production server that actually does this now. Dynamic DNS is probably the least offensive solution if you really want reverses for your v6 nodes.
DNSSEC does seem to throw the proverbial wrench in the works.. At least, from what I understand.. I'm still not sold on DNSSEC and that, partly, has to do with a lack of knowledge.. If you allow a client to set their own reverse, don't you run into issues where the client can spoof their identity? ie, set their reverse to whitehouse.gov or bankofamerica.com ? Or is it possible to configure DDNS in such a way as to only allow subdomain names where the domain is tacked on automagically?
Regards, -drc
--------------------------- Jason 'XenoPhage' Frisvold xenophage@godshell.com --------------------------- "Any sufficiently advanced magic is indistinguishable from technology." - Niven's Inverse of Clarke's Third Law
On Apr 27, 2010, at 6:10 PM, Jason 'XenoPhage' Frisvold wrote:
How about a programmatic expansion? Only create the necessary record when asked for it.
The downsides I know of (off the top of my head) with dynamic synthesis are (a) challenges if you want DNSSEC and (b) increased susceptibility to D(D)oS attack. There are probably others. At some point, one has to ask if the ability to map the address into a name is worth the effort...
If you allow a client to set their own reverse, don't you run into issues where the client can spoof their identity? ie, set their reverse to whitehouse.gov or bankofamerica.com ?
Yep, but those are boring examples. I've seen (typically University computer science) networks with some truly fascinating (in scatological, religious and/or reproductive senses) reverse names. Since anyone who relies on the reverse for anything other than a hint that the address might be part of a managed network deserves what they get, the names were good for a chuckle.
Or is it possible to configure DDNS in such a way as to only allow subdomain names where the domain is tacked on automagically?
Most DDNS servers support some form of filtering. However, the better way, at least in IPv4, is to have the DHCP server do the dynamic updates, not the client. However, since some view DHCPv6 as Evil Pure and Simple by way of the Eighth Dimension(tm), this may not be an option. Regards, -drc
Presumably, if you've already got a script that's provisioning reverse results, you could amend it to add name constraints. No idea if this is possible with current DynDNS software, though. --Richard On Tue, Apr 27, 2010 at 9:10 PM, Jason 'XenoPhage' Frisvold <xenophage@godshell.com> wrote:
On Apr 27, 2010, at 9:00 PM, David Conrad wrote:
Hmm. A macro expansion for a /48 would mean 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test for name servers... :-).
Um.. sure. :) Your computer can't handle that?
How about a programmatic expansion? Only create the necessary record when asked for it.
Slightly more seriously, there have been discussions in the past about doing dynamic synthesis of v6 reverses, but that gets icky (particularly if you invoke the dreaded "DNSSEC" curse) and I don't know any production server that actually does this now. Dynamic DNS is probably the least offensive solution if you really want reverses for your v6 nodes.
DNSSEC does seem to throw the proverbial wrench in the works.. At least, from what I understand.. I'm still not sold on DNSSEC and that, partly, has to do with a lack of knowledge..
If you allow a client to set their own reverse, don't you run into issues where the client can spoof their identity? ie, set their reverse to whitehouse.gov or bankofamerica.com ? Or is it possible to configure DDNS in such a way as to only allow subdomain names where the domain is tacked on automagically?
Regards, -drc
--------------------------- Jason 'XenoPhage' Frisvold xenophage@godshell.com --------------------------- "Any sufficiently advanced magic is indistinguishable from technology." - Niven's Inverse of Clarke's Third Law
On 2010.04.27 21:00, David Conrad wrote:
On Apr 27, 2010, at 5:47 PM, Jason 'XenoPhage' Frisvold wrote:
On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote:
Windows will just populate the reverse zone as needed, if you let it, using dynamic update. If you have properly deployed BCP 39 and have anti-spoofing ingres filtering then you can just let any address from the /48 add/remove PTR records. Other OS's will follow suite.
Is DDNS really considered to be the end-all answer for this?
Seems it is that or not bothering with reverse anymore.
There are other solutions, which has become a major focus of mine based on some of the results I've gathered from my little test. About 50% (currently 50.59%) of all successful visits to my site do not have rDNS configured for their IPv6... That is a problem that needs a solution. The OP has a great question here. Steve
Hmm. A macro expansion for a /48 would mean 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test for name servers... :-).
My inclination would be to use a wildcard that returns something like not-in-service.some-network.net, and let the clients add records for the addresses they use. For spoof resistance, how about doing a forward lookup on the purported name and only installing it if it gets a matching AAAA record? R's, John
On Apr 27, 2010, at 6:46 PM, John Levine wrote:
Hmm. A macro expansion for a /48 would mean 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test for name servers... :-). My inclination would be to use a wildcard that returns something like not-in-service.some-network.net, and let the clients add records for the addresses they use.
While better than 1 septillion zone entries, you still have the problem of how to let the clients add the records. DDNS is one approach. Manual intervention (e.g., as part of a customer provisioning system) is another as long as you don't use privacy extensions.
For spoof resistance, how about doing a forward lookup on the purported name and only installing it if it gets a matching AAAA record?
Sounds like a reasonable DDNS filtering approach. Regards, -drc
On Tue, Apr 27, 2010 at 11:13 PM, David Conrad <drc@virtualized.org> wrote:
On Apr 27, 2010, at 6:46 PM, John Levine wrote:
For spoof resistance, how about doing a forward lookup on the purported name and only installing it if it gets a matching AAAA record?
Sounds like a reasonable DDNS filtering approach.
On controlled environments it might work. Don't know how larger ISPs would set AAAA records before for bazillion possible combinations of computer.subnet.customer.isp.tld. If going dynamic, are you willing to lower your DNS TTL to handle that? Maybe doing wildchar evatulation for /64 subnets? "Everything under this subnet is my-subnet.customer.isp.tld".
Regards, -drc
Kindly, Felipe
David Conrad wrote:
While better than 1 septillion zone entries, you still have the problem of how to let the clients add the records. DDNS is one approach. Manual intervention (e.g., as part of a customer provisioning system) is another as long as you don't use privacy extensions.
Realtime updates to zonedata as the IP is seen. Dual detections of IP (ddns, which we won't allow, but easy detection of IP assigned) and edge detection in security/tracking layer (perhaps as fallback, 5-10minute delay) in case their setup isn't trying ddns to our nameservers. Jack
-----Original Message----- From: David Conrad [mailto:drc@virtualized.org] Sent: Wednesday, April 28, 2010 3:01 AM To: Jason 'XenoPhage' Frisvold Cc: nanog@nanog.org Subject: Re: [Nanog] Re: IPv6 rDNS - how will it be done?
On Apr 27, 2010, at 5:47 PM, Jason 'XenoPhage' Frisvold wrote:
On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote:
Windows will just populate the reverse zone as needed, if you let it, using dynamic update. If you have properly deployed BCP 39 and have anti-spoofing ingres filtering then you can just let any address from the /48 add/remove PTR records. Other OS's will follow suite.
Is DDNS really considered to be the end-all answer for this?
Seems it is that or not bothering with reverse anymore.
It seems we're putting an awful lot of trust in the user when doing this.. I'd rather see some sort of macro expansion in bind/tinydns/etc that would allow a range of addresses to be added.
Hmm. A macro expansion for a /48 would mean 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test for name servers... :-).
With LUA scripting and PowerDNS you could create a reverse DNS/forward DNS based on the input and match it (IP or hostname). This could be really dynamic and with using some cache it should also be fast. Checking what IPv6 address is in use and providing them a rDNS is also an option of course (but I think that will consume more power/bandwith/etc. on the long term).
Slightly more seriously, there have been discussions in the past about doing dynamic synthesis of v6 reverses, but that gets icky (particularly if you invoke the dreaded "DNSSEC" curse) and I don't know any production server that actually does this now. Dynamic DNS is probably the least offensive solution if you really want reverses for your v6 nodes.
As long as you don't use DNSSEC the option above is possible, but with DNSSEC many options will fail I think. Completely dynamic based on the request of a client isn't an option if you ask me (or do we want .local addresses in the rDNS?).
Regards, -drc
On 28.04.2010, at 09:31, Mark Scholten wrote:
Hmm. A macro expansion for a /48 would mean 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test for name servers... :-).
With LUA scripting and PowerDNS you could create a reverse DNS/ forward DNS based on the input and match it (IP or hostname). This could be really dynamic and with using some cache it should also be fast. Checking what IPv6 address is in use and providing them a rDNS is also an option of course (but I think that will consume more power/bandwith/etc. on the long term).
Lua scripting is available for PowerDNS recursor only i fear, you would want a authoritative DNS solution here and there already is one: This script [1] by Wijnand Modderman is a pipe backend for PowerDNS Server which will provide you with IPv6 forward and reverse entries much like DJB's walldns does for IPv4. Due to the way backends are exhausted for answers subsequently in PowerDNS Server i can have my mysql backend provide IN AAAA and PTR records for hosts that i want named specifically and then let the pipe backend handle all the rest of my /48.
Slightly more seriously, there have been discussions in the past about doing dynamic synthesis of v6 reverses, but that gets icky (particularly if you invoke the dreaded "DNSSEC" curse) and I don't know any production server that actually does this now. Dynamic DNS is probably the least offensive solution if you really want reverses for your v6 nodes.
As long as you don't use DNSSEC the option above is possible, but with DNSSEC many options will fail I think. Completely dynamic based on the request of a client isn't an option if you ask me (or do we want .local addresses in the rDNS?).
DNSSEC support for PowerDNS Server is on it's way [2] and i think it should integrate with most available backend types not for long, however whats still missing is indeed the dynamic DNS support aka TSIG - i don't need it but i happen to know there have been a few requests for DDNS support in PowerDNS recently, so maybe that will happen too. Stefan [1] http://zaphods.net/~zaphodb/pdns-ipv6-reverse-backend.py [2] http://mailman.powerdns.com/pipermail/pdns-users/2010-April/006671.html
In message <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com>, "Jason 'XenoPhage' Frisvold" wri tes:
On Apr 27, 2010, at 8:42 PM, Mark Andrews wrote:
Windows will just populate the reverse zone as needed, if you let it, using dynamic update. If you have properly deployed BCP 39 and have anti-spoofing ingres filtering then you can just let any address from the /48 add/remove PTR records. Other OS's will follow suite.
Is DDNS really considered to be the end-all answer for this?
It works if you let it.
It seems = we're putting an awful lot of trust in the user when doing this.
What trust? The OS just does it. The user doesn't need to think about this.
I'd = rather see some sort of macro expansion in bind/tinydns/etc that would = allow a range of addresses to be added.
Macro expansion won't work. 1208925819614629174706176 PTR records is a hell of a lot of records and that's just 1 /48. :-)
Alternatively you can delegate the reverse for the /48 to servers run by the customers.
This works for commercial customers, but I'm not sure I'd want to = delegate this to a residential customer.
Some will be capable others won't. I would leave it as a option but not the default. Some thing that the account's control panel can turn on and off. I would however use a different set of servers for the /48's to that of serving the /32 (or whatever) as you can just change the delegation without having to also add and remove zones which you would if they are on the same servers. I would also provide customers with forward zones that they can populate again using the /48 to control access. e.g. <hex>.customer.isp.com. <hex> is the hexadecimal representation of the /48. <machine>.<hex>.customer.isp.com. AAAA <hex>:<client> They don't need to use it but it should be there to provide complete the loop. If HE was following this schema then bsdi would default to: bsdi.200104701f00.customer.he.net AAAA 2001:470:1f00:ffff::5a1 bsdi.200104701f00.customer.he.net AAAA 2001:470:1f00:820:2e0:29ff:fe19:c02d But as I care about the name of the machine it is: bsdi.dv.isc.org. AAAA 2001:470:1f00:ffff::5a1 bsdi.dv.isc.org. AAAA 2001:470:1f00:820:2e0:29ff:fe19:c02d Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
participants (13)
-
David Conrad -
Felipe Zanchet Grazziotin -
Jack Bates -
James Hess -
Jason 'XenoPhage' Frisvold -
John Levine -
Larry Sheldon -
Mark Andrews -
Mark Scholten -
Richard Barnes -
Stefan Schmidt -
Steve Bertrand -
Tony Finch