:: > The stub config is interesting, though. :: :: Will be interesting to see if it even works. :: :: If they are just stubs for the fakeTLD.newdotnet.net., then :: all client :: requests will have to be properly formatted on send, meaning :: that it will :: only work if the plugin is used. Stuff like ping won't work. Nasty. :: :: If they are supporting an alias function (assuming ISPs are able to :: control the DNS settings on their users systems), then the :: ISP partners' :: DNS servers will have to run fake roots in order catch the :: requests for :: fake.zone. If they do that, are they going to answer with fake.zone. :: RRsets? or are they going to DNAME/CNAME everything? :: :: Neither mechanisms are pretty, both are required, it'll never last. No. It appears that they have fully prepared TLD DNS service implemented for the .chat, .xxx, .book, etc., Just like I could prepare a .karyn. TLD and set it up on my name server. I checked it out, the stub config sets up a slave stub zone for the TLDs they are serving, the resulting db file generated is like: ; BIND version named 8.2.3-REL Wed Jan 31 09:45:01 PST 2001 ; BIND version root@dns-01-001.root-dns.com:/usr/local/src/bind-8.2.3/src/bin/named ; zone 'chat' first transfer ; from 204.69.234.253:53 (local 64.7.192.162) using AXFR at Tue Mar 6 09:29:16 2001 $ORIGIN .chat 7200 IN SOA ns0.newdotnet.net. hostmaster.new.net. ( 983865614 1200 300 3600000 600 ) 7200 IN NS udns1.newdotnet.net. 7200 IN NS udns2.newdotnet.net. Using the stub config, you don't have to alter your root.cache. If ICANN has the root servers start serving of .chat info, then you can just remove the zone config from the .conf file. It's not that complicated to manage. You can keep the whole stub config outside of your main configs and "include" it (I do this ALOT anyways). The result is that you have a simple NS record like you do for COM/NET/ORG/EDU, etc. Not to evil. However, it would be VERY evil if the plug-in thing got into broad use. What a load that would be. Technical support on it would be a nightmare for every single ISP on the Internet. Imagine troubleshooting Joe Users browser access when he isn't telling you he's using this thaang. Dark clouds of jumbled characters over every TS cube is what you'll get. Next thing you know, every inet app would have to have this layer to get anywhere (the POS layer). Also, it's pretty evil that the first course they are offering ISP is to replace their root.cache file with a file that just has their 3 dns servers. No thanx. I'd hate to see what I'd find out when I trace out their locations and connectivity. Hopefully, they are smarter than having it as Bob's ISP, but I (like most netops) have become very cyncial about the technical capabilities of startups and "new" technologies. I would be willing to use them for name service for these alternative TLDs until they are served on the root servers. BUT, I won't depend on them for access to the root servers themselves. Color me foolish. K