From: "Joe Abley" Unless Xtra's planned configuration is particularly unusual, I would imagine they would return answers from the cache where they exist, return authoritative answers in the case of queries that they have authoritative data for, and otherwise return a referral to the root.

"no answers" is the usual "not here" reply (like ns1.ihug.co.nz) And therein lies the problem. For a non Xtra user, that has Xtra DNS servers hard coded, 90% of DNS requests will probably work because Xtra's servers have much of the nz internet namespace in their cache, (or the servers are authorititive) The IP address 202.27.184.3 is a virus, it seems have spread into the configurations of many NZ computers, I think it is one of those "it just works" scenarios and computer technicians have used it as a default fix for many "wierd" DNS issues. Once Xtra disable recursion for non Xtra customers, those same techncians will be challenged with trying to diagnose a very intermittent "page can not be displayed" fault. Ted, if we assume this change is being made because there are a significant number of requests (relative to the size of your user base) coming from non Xtra IP addresses, then we would have to assume that a significant number of users (that have dumb client resolvers) are going to be affected. Are there any statistics available from your name servers on the scale of this issue (Like is it 10% non Xtra requests?) Cheers BG

From: "Mark Foster" One does have to ask tho - "Is this Xtra's Problem?"

On the basis that they are trying to fix it..... :)

Would the better solution not simply be to do what Ted has done here - get the information out ahead of time - so that when confronted with the problem, those very same technicians know to look at the local DNS config first?

Yes, and we need to know the nature of the fault we are going to be presented with (which is where I am coming from). If Xtra dish out answers from cache to non Xtra users then the fault will be "I can't get to this website on Mondays". I think Xtra should kill all non authorititive answers to non Xtra users, that way non Xtra users will get consistant answers from Xtra name servers (i.e. a hard fault for non local domains). And yes, this is a lot better than the panic we had in 2002 with pop3.xtra.co.nz; two days out from Christmas. Cheers BG

Alot of it would be people who had an XTRA CD and ran though the internet connection wizard ( usually with the aid of the helpdesk ) . Changed ISP's and just changed the username / password and dial up number .

On 1-Nov-2005, at 19:45, Brian Gibbons wrote:

...

The IP address 202.27.184.3 is a virus, it seems have spread into the configurations of many NZ computers, I think it is one of those "it just works" scenarios and computer technicians have used it as a default fix for many "wierd" DNS issues.

Perhaps it's about time those alleged technicians found work more suited to their abilities.

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

brett wrote:

Alot of it would be people who had an XTRA CD and ran though the internet connection wizard ( usually with the aid of the helpdesk ) . Changed ISP's and just changed the username / password and dial up number .

(Not having used an xtra install CD) I'd like to assume that they let PPP hand out the dns servers, and for a long time now that has been dnsc1 and dnsc2.xtra.co.nz -Richard

for example - negative response - [root(a)host1 ~]# dig @ns1.safenz.net cnn.com ; <<>> DiG 9.2.4 <<>> @ns1.safenz.net cnn.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30146 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 11 ;; QUESTION SECTION: ;cnn.com. IN A ;; AUTHORITY SECTION: com. 172228 IN NS H.GTLD-SERVERS.NET. com. 172228 IN NS I.GTLD-SERVERS.NET. com. 172228 IN NS J.GTLD-SERVERS.NET. com. 172228 IN NS K.GTLD-SERVERS.NET. com. 172228 IN NS L.GTLD-SERVERS.NET. com. 172228 IN NS M.GTLD-SERVERS.NET. com. 172228 IN NS A.GTLD-SERVERS.NET. com. 172228 IN NS B.GTLD-SERVERS.NET. com. 172228 IN NS C.GTLD-SERVERS.NET. com. 172228 IN NS D.GTLD-SERVERS.NET. com. 172228 IN NS E.GTLD-SERVERS.NET. com. 172228 IN NS F.GTLD-SERVERS.NET. com. 172228 IN NS G.GTLD-SERVERS.NET. ;; ADDITIONAL SECTION: C.GTLD-SERVERS.NET. 86899 IN A 192.26.92.30 D.GTLD-SERVERS.NET. 86899 IN A 192.31.80.30 E.GTLD-SERVERS.NET. 86899 IN A 192.12.94.30 F.GTLD-SERVERS.NET. 86899 IN A 192.35.51.30 G.GTLD-SERVERS.NET. 86899 IN A 192.42.93.30 H.GTLD-SERVERS.NET. 87026 IN A 192.54.112.30 I.GTLD-SERVERS.NET. 87026 IN A 192.43.172.30 J.GTLD-SERVERS.NET. 86899 IN A 192.48.79.30 K.GTLD-SERVERS.NET. 86899 IN A 192.52.178.30 L.GTLD-SERVERS.NET. 87026 IN A 192.41.162.30 M.GTLD-SERVERS.NET. 86899 IN A 192.55.83.30 ;; Query time: 18 msec ;; SERVER: 203.98.6.51#53(ns1.safenz.net) ;; WHEN: Wed Nov 2 13:44:57 2005 ;; MSG SIZE rcvd: 425 ############################################################# in cache - [root(a)host1 ~]# dig @ns1.safenz.net xtra.co.nz ; <<>> DiG 9.2.4 <<>> @ns1.safenz.net xtra.co.nz ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56637 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;xtra.co.nz. IN A ;; ANSWER SECTION: xtra.co.nz. 68573 IN A 202.27.184.102 ;; AUTHORITY SECTION: xtra.co.nz. 71170 IN NS alien.xtra.co.nz. xtra.co.nz. 71170 IN NS terminator.xtra.co.nz. ;; ADDITIONAL SECTION: alien.xtra.co.nz. 71170 IN A 202.27.184.3 terminator.xtra.co.nz. 8469 IN A 202.27.184.5 ;; Query time: 18 msec ;; SERVER: 203.98.6.51#53(ns1.safenz.net) ;; WHEN: Wed Nov 2 13:45:04 2005 ;; MSG SIZE rcvd: 121 ################################################## authoritive - [root(a)host1 ~]# dig @ns1.safenz.net safenz.net ; <<>> DiG 9.2.4 <<>> @ns1.safenz.net safenz.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14413 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;safenz.net. IN A ;; ANSWER SECTION: safenz.net. 3600 IN A 203.98.6.53 ;; AUTHORITY SECTION: safenz.net. 3600 IN NS ns2.safenz.net.nz. safenz.net. 3600 IN NS ns3.safenz.net.nz. safenz.net. 3600 IN NS ns1.safenz.net.nz. ;; ADDITIONAL SECTION: ns1.safenz.net.nz. 3600 IN A 203.98.6.51 ns2.safenz.net.nz. 3600 IN A 203.98.6.34 ns3.safenz.net.nz. 3600 IN A 58.28.96.19 ;; Query time: 17 msec ;; SERVER: 203.98.6.51#53(ns1.safenz.net) ;; WHEN: Wed Nov 2 13:48:01 2005 ;; MSG SIZE rcvd: 159 Joe Abley wrote:

On 1-Nov-2005, at 15:19, Brian Gibbons wrote:

...

What action will those servers take when they receive a request from a non Xtra IP?

Unless Xtra's planned configuration is particularly unusual, I would imagine they would return answers from the cache where they exist, return authoritative answers in the case of queries that they have authoritative data for, and otherwise return a referral to the root.

That's what most mixed intermediate-mode resolver/authority servers do when replying to a query from a client for whom recursion is disabled.

Joe

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog