- NZNOG - lists.nznog.org

reload frequency .nz name servers
by Peter Mott 18 May '00

18 May '00

Does anybody know the timetable for reload of .nz 2TLD name servers on the domainz new system? I just rang them and was advised name servers are only reloaded once a day following a zone build at 4pm. The person did not state whether this occured on the weekend as well as during the week. Useful stuff like this does not appear on the domainz web site :-( Regards Peter Mott Chief Enthusiast 2day.com -/- --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

3 2

Email notifications of name server changes
by Andrew McGhie 17 May '00

17 May '00

We are in the process of implementing the following: After any change to name server details for a domain name a notification message will be sent to the email address in the soa record for the master name server. Where the master name server has changed as a result of the operation, the same message will be sent to the email address in the soa record of the master name server to which the domain name is being changed. Email messages will also be sent to the contact email addresses in the DRS database records for any Registrar(s) involved in a transaction. Registrars should therefore check their email contact addresses in the DRS. If these are incorrect, please notify registrars(a)domainz.net.nz and we will correct them. We expect to have these facilities available by the close of business hours tomorrow (19.5.00). Regards Andrew Mason (from Andrew McGhie's email) --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

6 8

E-Mail Addy When registering a new domain
by nntp＠takin.proz.ac.nz 17 May '00

17 May '00

(A copy of this message has also been posted to the following newsgroups: nz.org.isocnz) Hiyas I have just created a new domain name in the .school.nz space. We have created many of these before for schools as they gain an internet presence. When entering the Name Holder Details, we used to enter the e-mail address as "principal(a)schoolname.school.nz". This was fine and all e-mail to the name holder made it to the desired recipient. I have already set up our mail server to accept mail for that domain. Now when I try and do the same thing with the new DRS system, I am told that the e-mail field is not acceptable. It states that you must use a real address. Presumably this is because their checks show that there is no such domain (as we are only registering it now!!). So, to get around it (the e-mail field is compulsory!) I have to enter a bullshite address with a real domain name (fakie(a)advcomm.co.nz for instance). This is hopeless! Now all e-mail intended for the Name Holder will be lost, whereas it used to get there fine! Why has this chnaged, and can Advantage change it so that it will accept an e-mail field with a domain-name that is still being registered? Thanks in advance! Pete --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

6 5

Re: [DRS] Email notification of change of Registrar
by Pete 17 May '00

17 May '00

Put my name down for a yes. If it used to happen automatically, and now it does not, who made the decision that it should not be implemented without registrars requesting it? On Thu, 18 May 2000, Andrew McGhie wrote: > As we have announced, when a name is transferred from one Registrar to > another, email notifications are sent to both Registrars on successful > completion of the transfer. > > The system does not at present send a notification to the soa for the names > servers if this is different from the Registrar. As you are probably aware, > we have received a request to do this; we would be grateful to hear from > Registrars as to whether this is a facility that they would like to see. > Technically this can be accomplished very quickly > > Regards > Andrew Mason (from Andrew McGhie's email) > > > > _______________________________________________ > DRS mailing list > DRS(a)domainz.net.nz > http://listserver.actrix.co.nz/mailman/listinfo/drs > --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 1

notification of delegation of domain names
by Peter Mott 17 May '00

17 May '00

Sorry for the intrusion... The new domainz system does not send a notification email to the soa email address for the zone a name server is delegated to when delegating or removing a delegation. The UoW system did this ok, and our DNS automatically removed zones as a result of such notification. It appears that DOMAINZ is struggling to hear enough people telling them this is an important feature. As a result, they may not fix the problem. If there are people here who are sysadms for name servers and you value being informed when domain names are moved, can I ask you to send messages to domainz via whatever means you know how, telling them that notification of delegations is rather important and they really should fix it. Thanks Regards Peter Mott Chief Enthusiast 2day.com -/- --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

3 2

Zone file builds
by Andrew McEwen Mason 17 May '00

17 May '00

Greetings all This is to inform you of a change in the schedule of zone builds effective Friday 19.5.00. As you know, these have continued uninterrupted at 16.00 daily since the introduction of the new Domainz Registration System, and have been moved to a 7 days/week operation. In the last few days we have consulted with major Registrars about both increasing the frequency of builds and also the preferred timings. A consensus emerged that twice daily would be appreciated, in the morning and after the end of the working day. As a result, starting this Friday (19 May 2000) zone builds will be carried out twice daily at 11.00 and 19.00 - 7 days a week. Thanks to all who gave their input. We hope that this new arrangement will be acceptable to all, and will welcome any feedback on timing, frequency or any other aspect of the zone build process. Regards to all Andrew ________________________________________________ Andrew McEwen Mason BSA Consulting Group 7 Mariri Road, Kelburn Wellington, NZ Phone +64 4 934-3178 Mobile +64 21 466-181 --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

FW: [DRS] Zone builds
by Peter Mott 16 May '00

16 May '00

Below for information of sysadmins. It was news to us as we are not a registrar and have no knowledge of the means by which domainz consults. I am not sure if the "zone builds" referred to mean the master name server for .nz 2TLD zones is reloaded using the new data, but one assumes this is the case Regards Peter Mott Chief Enthusiast 2day.com -/- > -----Original Message----- > From: drs-admin(a)domainz.net.nz [mailto:drs-admin(a)domainz.net.nz]On > Behalf Of Andrew McEwen Mason > Sent: Wednesday, 17 May 2000 9:49 p.m. > To: drs(a)domainz.net.nz > Subject: [DRS] Zone builds > > > Greetings all > > This is to inform you of a change in the schedule of zone builds effective > Friday 19.5.00. > > AS you know, these have continued uninterrupted at 16.00 daily since the > introduction of the new Domainz Registration System, and have > been moved to > a 7 days/week operation. > > In the last few days we have consulted with major Registrars about both > increasing the frequency of builds and also the preferred timings. A > consensus emerged that twice daily would be appreciated, in the > morning and > after the end of the working day. As a result, starting this > Friday (19 May > 2000) zone builds will be carried out twice daily at 11.00 and 19.00 - 7 > days a week. > > Thanks to all who gave their input. We hope that this new > arrangement will > be acceptable to all, and will welcome any feedback on timing, > frequency or > any other aspect of the zone build process. > > Regards to all > Andrew > > ________________________________________________ > Andrew McEwen Mason > BSA Consulting Group > 7 Mariri Road, Kelburn > Wellington, NZ > > Phone +64 4 934-3178 Mobile +64 21 466-181 > > > _______________________________________________ > DRS mailing list > DRS(a)domainz.net.nz > http://listserver.actrix.co.nz/mailman/listinfo/drs --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Name server authoritativeness checking
by Andrew McGhie 16 May '00

16 May '00

This is to confirm that the DRS has been amended such that, at registration or change of delegation it carries out authoritativeness checks on the master and first slave name servers only, and no others. The checks that it carries out have also been relaxed, which will overcome some other problems experienced in some quarters. The actual checks that are carried out are currently being documented and will be promulgated by the end of the day tomorrow. In the meantime, please let us know if there are any specific details you would like to see in this documentation. Regards Andrew Mason --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Old UPSes for New
by Joe Abley 16 May '00

16 May '00

Hi, Due to bad planning, I have two nearly-new Compaq UPSes that are about 10cm too long for the racks I need to put them in. The units were supplied new by Compaq for the LV Cup media centre in Auckland, and were purchased by my client as the media centre was closed down at the end of the Americas Cup. They have not since been used. The UPSes seem to be a Compaq-rebadged version of an APC rack-mount UPS, spec'd to 3000 kVA. Maximum input current 16A. 18 x 10A outputs on three separate buses. About 70kg each, which brings them nicely into the "christ, my back" category of equipment haulage. [Unit descriptions are from memory; I don't have them with me right now] I'd be very happy if I could exchange them for other, similar-spec rack- mount UPSes that will fit in our cabinets. If I have to, I will sell them. Private mail gratefully received :) Joe --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

6 8

Well known problem
by Arron Scott 15 May '00

15 May '00

Hi all, As this is a discussion forum for Network Operations people in NZ, I thought I would raise a little problem that I regularly see around the network. I am not pointing this at anyone in NZ in specific, it's just FYI. Hopefully most of you will already know about this. The problem: Clients can ping Web Servers running MTU Path Discovery but cannot HTTP. Why: At HTTP connect time, MTU is negotiated as the lowest set on the interfaces between server and client, for both using Internet this would be 1500 bytes. After that the server attempts to do MTU Path Discovery, by sending the largest agreed packet marked "DO NOT FRAGMENT". If there is a circuit somewhere along the path that is smaller than that packet size, the router is expected to drop the packet, and return ICMP Unreachables, with the "COULD NOT FRAGMENT" message attached. The server should then try a smaller packet. Unfortunately it is common for sites to filter the ICMP Unreachables, which the server never sees, and it spends it's life resending MTU Discovery Packets forever. How to Fix it: TURN OFF MTU PATH DISCOVERY on the server ... or less popular, change filtering to allow the required responses in. It is of course possible to fix the MTU for a specific case, but this never will work for everyone on the Internet. Common Scenarios: This will regularly occur with networks using; - Tunnels (L2TP, GRE, IPIP etc) as the tunnels must have lower MTU than the physical path, to allow it to carry the IP header. - ISDN Routers, where the client has an Ethernet, but the ISDN dialled connection is set to 952 or whatever. - Sites behind small links, where the MTU is tuned for the bandwidth available. This does not occur on dial-up connections, as the client may only have an MTU of 512 bytes, but this is internal to the client, and the original MTU negotiation will prevent a path discovery of packets beyond the MTU of the rest of the path. ps. I hope you are all aware of the problem with clients setting IP packets with a TTL of 32 hops, causing certain locations deep inside Europe to be unreachable. Detail on this problem is on www.netgate.net.nz under the "Too Many Hops Issue" Hope this is useful, Arron Scott Telecom NZ Ltd (But only for three more weeks)

2 1