From ilupe74 at econonews.com Tue May 12 20:01:16 1998 From: ilupe74 at econonews.com (ilupe74 at econonews.com) Date: Tue, 12 May 1998 20:01:16 +0200 (CEST) Subject: PDCD1 Message-ID: <199805121801.UAA00996@www.econonews.com> * NOTICE: ANSWERS ARE READ AUTOMATICALLY. - ONLY SEND US BACK THIS MESSAGE IF YOU ARE INTERESTED IN OUR JOURNAL. IF YOU WISH TO RECEIVE "BREAKFAST AND DIAMONDS" IN SPANISH, INDICATE IN THE E-MAIL SUBJECT: ES (e.g.: DCD1ES) - IF YOU SEND US BACK THIS MESSAGE MORE THAN ONCE, "BREAKFAST WITH DIAMONDS" WILL BE FORWARDED AS MANY TIMES AS YOU HAVE SENT IT. *ATENCION: LAS RESPUESTAS DE ESTE E-MAIL SE LEEN AUTOMATICAMENTE. - SOLO DEBERA REBOTAR ESTE MENSAJE EN CASO DE ESTAR INTERESADO EN NUESTRO PERIODICO. SI QUIERE RECIBIR "DESAYUNE CON DIAMANTES" EN ESPA?OL A?ADA EN EL ASUNTO LA ABREVIATURA: ES (EJ.DCD1ES). - SI REBOTA MAS DE UNA VEZ ESTE E-MAIL LE ENVIAREMOS "DESAYUNE CON DIAMANTES" TANTAS VECES COMO LO HAYA REBOTADO. Dear Sir/Madam, Would you like to have breakfast with diamonds? You probably think that this only happens in movies. However, our wish is to make your dreams come true and that you have breakfast while reading the hottest economic news in "Breakfast with Diamonds". "Breakfast with Diamonds" is an ALIVE JOURNAL, since news are hourly updated, INTERACTIVE, since our subscribers have the opportunity to ask for further information of any piece of news (free service), and GLOBAL since it includes the most significant news worldwide. INFORMATION IS KNOWLEDGE AND KNOWLEDGE IS POWER If you wish to learn more about "Breakfast with Diamonds" we cordially invite you to visit our website: http://www.econonews.com If you wish to receive "Breakfast with Diamonds" for a free 30-day trial, you just have to send us back this message. Sorry for any inconvenience we may have caused you and thank you for your time. Yours faithfully, Breakfast with Diamonds Marketing Director From hasse at swip.net Thu May 14 16:14:15 1998 From: hasse at swip.net (Hans Niklasson) Date: Thu, 14 May 1998 16:14:15 +0200 (MET DST) Subject: Recommendations for DNS Message-ID: Greetings This is one of the actionspoints from RIPE-28, to present easy and short recommendations for setting up a DNS. I presented this for the DNS WG on RIPE-29. Any suggestions or remarks will still be very welcomed. Especially the times for the SOA records. Otherwise I recommend that we move forward to make this a RIPE-document. DNS recommendations. By: Hans Niklasson Amar Andersson Scope: This documents act as a recommendation for configuring your DNS. This is NOT a requirement, only a recommendation of things to think about when setting up your DNS. Purpose: To decrease lame delegations and limit unecessary traffic due to resolving problems, among other things. Records: ----------------------------------------------------------------------------- SOA The address in this field must be a valid e-mail address to the administrator for the DNS. *** It's also good practise to have role address instead of personal, ie root.. admin.. hostmaster.. (when domain-administrator is leaving your company, you only change the alias for role address). Ex: domain.xx. 3600 SOA dns.domain.xx admin.domain.xx. SERIAL Serial number should follow this format: YYYYMMDDXX ( year.year.year.year.month.month.day.day.nr.nr ), where XX is the number of the latest update of the zone in the same day. (Year 2000 is near.) Ex: 1998010101 ; serial TTL A good balance of this will reduce unecessary traffic between nameservers. Ex: 28800 ; refresh (8 hours) 7200 ; retry (2 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) MX When pointing a domain to a mailserver/hostname, don?t forget to add a glue record ( A ) for this. Ex: domain.xx. 86400 MX 10 mail.domain.xx. mail.domain.xx 86400 A 192.168.0.1 CNAME Use this with percausion. It is *not* recommended to use a CNAME for a mailservers hostname, as this can cause resolving problems and mailloops. A A gluerecord can only point to an IP address. PTR This is used for reverse lookup of the IP address to a hostname within the zone. Make sure that your PTR records and A records match. For each A record there has to be a PTR record, and vice versa. More tips: Unecessary glue data: Don?t add unecessary glue data about hosts that is not within the zone. This can cause resolving problems if the host changes IP address. Ex: domain.xx. 86400 MX 10 mail.server.xx. mail.server.xx 86400 A 192.168.0.1 Trailing dots: Don?t forget to add a "." at the end of the domain/ hostname. If this is forgotten, this will make the DNS to add the domain name to the domain/hostname again. This will cause resolving problems. Ex: domain.xx. 86400 MX 10 mail.domain.xx.domain.xx. Illegal characters: Only a-z , 0-9 and - is valid to use. All other characters is illegal and can cause the resolving to fail. General Points: Use the latest version of the DNS software for your platform. Check for updates regulary, as new versions has the latest solutions and information. Additional reading and references: RFC1537 ( RFC1912 ) ( Common DNS Operational and Configuration Errors ) "DNS & BIND 2nd Edition" by Paul Albitz & Cricket Liu from O?Reilly & Associates Inc. ftp://ftp.ripe.net/internet-drafts/draft-ietf-dnsind-classless- inaddr-04.txt ( For reverse delegation methods for blocks smaller than /24, 256 addresses ) http://www.dns.net/dnsrd/ ( DNS Resources Directory ) /Hans Niklasson ----------------------------------------------------------------- SWipNet - The Swedish IP Network From frwi at global-ip.net Thu May 14 16:26:48 1998 From: frwi at global-ip.net (Fredrik Widell) Date: Thu, 14 May 1998 16:26:48 +0200 (MET DST) Subject: Recommendations for DNS In-Reply-To: Message-ID: On Thu, 14 May 1998, Hans Niklasson wrote: > Greetings > > This is one of the actionspoints from RIPE-28, to present easy and short > recommendations for setting up a DNS. > I presented this for the DNS WG on RIPE-29. > Any suggestions or remarks will still be very welcomed. > Especially the times for the SOA records. > Otherwise I recommend that we move forward to make this a RIPE-document. Hello. As someone pointed out at RIPE-29, it would be a good idea to increase the expiration period appr four times, say 2419200, there is really no point in limiting this to one week, often the customers do not realize that their nameserver is out of order, and in one week their domain is vanished from Internet. Best regards > > > > > DNS recommendations. > > > By: > > Hans Niklasson > Amar Andersson > > > > Scope: > > This documents act as a recommendation for configuring your DNS. This is > NOT a requirement, only a recommendation of things to think about when > setting up your DNS. > > Purpose: > > To decrease lame delegations and limit unecessary traffic due to resolving > problems, among other things. > > > Records: > ----------------------------------------------------------------------------- > > SOA The address in this field must be a valid e-mail address to the > administrator for the DNS. > *** It's also good practise to have role address instead of > personal, ie root.. admin.. hostmaster.. > (when domain-administrator is leaving your company, you > only change the alias for role address). > > Ex: > > domain.xx. 3600 SOA dns.domain.xx admin.domain.xx. > > > SERIAL Serial number should follow this format: YYYYMMDDXX > ( year.year.year.year.month.month.day.day.nr.nr ), > where XX is the number of the latest update of the zone in the > same day. (Year 2000 is near.) > > Ex: > > 1998010101 ; serial > > > TTL A good balance of this will reduce unecessary traffic between > nameservers. > > Ex: > > 28800 ; refresh (8 hours) > 7200 ; retry (2 hour) > 604800 ; expire (7 days) > 86400 ) ; minimum (1 day) > > MX When pointing a domain to a mailserver/hostname, don4t forget to > add a glue record ( A ) for this. > > Ex: > > domain.xx. 86400 MX 10 mail.domain.xx. > > mail.domain.xx 86400 A 192.168.0.1 > > > CNAME Use this with percausion. It is *not* recommended to use a CNAME > for a mailservers hostname, as this can cause resolving problems > and mailloops. > > A A gluerecord can only point to an IP address. > > > > PTR This is used for reverse lookup of the IP address to a hostname > within the zone. Make sure that your PTR records and A records > match. For each A record there has to be a PTR record, and vice > versa. > > > More tips: > > Unecessary glue data: > > Don4t add unecessary glue data about hosts that is not within the > zone. This can cause resolving problems if the host changes IP > address. > > Ex: > > domain.xx. 86400 MX 10 mail.server.xx. > > mail.server.xx 86400 A 192.168.0.1 > > Trailing dots: > Don4t forget to add a "." at the end of the domain/ > hostname. If this is forgotten, this will make the DNS to add the > domain name to the domain/hostname again. This will cause > resolving problems. > > Ex: > > domain.xx. 86400 MX 10 mail.domain.xx.domain.xx. > > Illegal characters: > > Only a-z , 0-9 and - is valid to use. All other characters is > illegal and can cause the resolving to fail. > > > General Points: > > Use the latest version of the DNS software for your platform. > Check for updates regulary, as new versions has the latest > solutions and information. > > > Additional reading and references: > > RFC1537 ( RFC1912 ) > ( Common DNS Operational and Configuration Errors ) > > "DNS & BIND 2nd Edition" by Paul Albitz & Cricket Liu > from O4Reilly & Associates Inc. > > ftp://ftp.ripe.net/internet-drafts/draft-ietf-dnsind-classless- > inaddr-04.txt > ( For reverse delegation methods for blocks smaller than /24, > 256 addresses ) > > http://www.dns.net/dnsrd/ > ( DNS Resources Directory ) > > > /Hans Niklasson > > ----------------------------------------------------------------- > SWipNet - The Swedish IP Network > > > > > > > > /Fredrik --------------------------------- Fredrik Widell - Global IP Sweden Phone : +46 8 519 131 00 Mail : frwi at global-ip.net From jhma at EU.net Thu May 14 16:40:00 1998 From: jhma at EU.net (James Aldridge) Date: Thu, 14 May 1998 16:40:00 +0200 Subject: Recommendations for DNS In-Reply-To: Your message of "Thu, 14 May 1998 16:14:15 +0200." Message-ID: <199805141440.QAA08952@aegir.EU.net> Just a couple of comments... Hans Niklasson wrote: > SOA The address in this field must be a valid e-mail address to the > administrator for the DNS. It must _correspond_ to a valid email address (by replacing the first '.' with an '@') but isn't an email address itself -- I've seen some broken zone files where there was an '@' in the SOA record. > *** It's also good practise to have role address instead of > personal, ie root.. admin.. hostmaster.. > (when domain-administrator is leaving your company, you > only change the alias for role address). > > Ex: > > domain.xx. 3600 SOA dns.domain.xx admin.domain.xx. ^ You're missing a '.' here (the dns.domain.xx.domain.xx. problem you mention below). > > > SERIAL Serial number should follow this format: YYYYMMDDXX > ( year.year.year.year.month.month.day.day.nr.nr ), > where XX is the number of the latest update of the zone in the > same day. (Year 2000 is near.) > > Ex: > > 1998010101 ; serial If anyone is interested (and doesn't want to reinvent the wheel), I've got a short perl script which generates suitable numbers and replaces a magic token (%SERIAL%) in zone files when installing updates which I can tidy up a bit and make available. > > TTL A good balance of this will reduce unecessary traffic between > nameservers. > > Ex: > > 28800 ; refresh (8 hours) > 7200 ; retry (2 hour) > 604800 ; expire (7 days) > 86400 ) ; minimum (1 day) > > MX When pointing a domain to a mailserver/hostname, don4t forget to > add a glue record ( A ) for this. > > Ex: > > domain.xx. 86400 MX 10 mail.domain.xx. > > mail.domain.xx 86400 A 192.168.0.1 ^ Missing '.' again. > Trailing dots: > Don4t forget to add a "." at the end of the domain/ > hostname. If this is forgotten, this will make the DNS to add the > domain name to the domain/hostname again. This will cause > resolving problems. > > Ex: > > domain.xx. 86400 MX 10 mail.domain.xx.domain.xx. Regards, James ----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 622 4657 - ----- 24hr emergency number: +31 20 421 0865 From zsako at banknet.net Thu May 14 16:26:53 1998 From: zsako at banknet.net (Janos Zsako) Date: Thu, 14 May 98 16:26:53 +0200 Subject: Recommendations for DNS Message-ID: <9805141426.AA26432@banknet.banknet.net> > From owner-dns-wg at ripe.net Thu May 14 15:54:09 1998 > From: Hans Niklasson Hans, > Illegal characters: > > Only a-z , 0-9 and - is valid to use. All other characters is > illegal and can cause the resolving to fail. I think it is worthwile at least mentioning that this restriction applies to _hostnames_ (e.g. right hand side of NS or MX records). This does not necessarily apply elsewhere. The third document you give as additional reading (draft-ietf-dnsind-classless-inaddr-04.txt) does use a character that is not in the set above (slash). This topic is very well clarified in RFC 2181 chapter 11. (Name syntax). Best regards, Janos From vaden at texoma.net Thu May 14 17:11:18 1998 From: vaden at texoma.net (Larry Vaden) Date: Thu, 14 May 1998 10:11:18 -0500 Subject: Recommendations for DNS Message-ID: <012001bd7f4a$8bb67560$4a6097d1@okie.texoma.net> -----Original Message----- From: James Aldridge To: Hans Niklasson Cc: dns-wg at ripe.net Date: Thursday, May 14, 1998 9:41 AM Subject: Re: Recommendations for DNS | |If anyone is interested (and doesn't want to reinvent the wheel), I've got a |short perl script which generates suitable numbers and replaces a magic |token (%SERIAL%) in zone files when installing updates which I can tidy up a |bit and make available. I would appreciate a copy of this perl script. Thanks, Larry Vaden Internet Texoma, Inc. From pk at TechFak.Uni-Bielefeld.DE Thu May 14 17:20:12 1998 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Thu, 14 May 1998 17:20:12 +0200 Subject: Recommendations for DNS In-Reply-To: Your message of "Thu, 14 May 1998 16:14:15 +0200." Message-ID: <199805141520.RAA18822@gunilla.TechFak.Uni-Bielefeld.DE> Hello, thanks for coming up with this again. > SOA The address in this field must be a valid e-mail address to the > administrator for the DNS. > *** It's also good practise to have role address instead of > =09=09personal, ie root.. admin.. hostmaster..=20 > =09=09(when domain-administrator is leaving your company, you=20 > =09=09only change the alias for role address). the three most common errors are: 1) Use of '@' in the DNS representation of the email address. It is essential that the '@' be encoded as '.'. One reason even knowledgable people use '@' is that you cannot publish addresses containing a dot in the local part this way. So, the popular scheme 'first.last at canonical.example' does not qualify for 1:1 translation. Usually you would (and you do, indeed) recommend using a canonical address like 'hostmaster at canonical.example' to avoid this. Another class of addresses are those from e.g. CompuServe. Just don't use them. 2) Useless defaults an unfortunately increasingly popular DNS server software suggests "administrator" either as a single label or with the zone name or probably the primary's name concatenated to it. While the first is even syntactically incorrect, mails to one of the latter nearly always bounces because the addresses have never been made valid. 3) copy 'n paste While it is tempting to use 'ns.bad.example' as the primary server for 'bad.example' and then to use 'root.ns.bad.example' as the "hostmaster" address, customers often forget one of the following: a) In most cases, although there exists an A-RR for ns.bad.example, that is not the "real" name of the host specified. To receive mail for root at ns.bad.example, the host must be informed to treat ns.bad.example as local. One of the strangest errors is receiving a mail from postmaster at schizo.example telling you that the address postmaster at schizo.example does not exist and then asking you to send further questions to, guess, postmaster at schizo.example. b) In other environments ns.bad.example is set up to handle DNS but for various reasons will not accept SMTP connections and does not have MX RRs defined for its name. During the last five years I've been sending hundreds of emails every month after evaluating the DE hostcount and most of the undeliverable mail fail due to one of the errors above (usually 15-20% of the tickets bounce.) > domain.xx. 3600 SOA dns.domain.xx admin.domain.xx.=20 IMHO there's no need to have a TTL of 3600 for the SOA, except that the software mentioned above seems to default to this value. > 28800 ; refresh (8 hours) > 7200 ; retry (2 hour) > 604800 ; expire (7 days) > 86400 ) ; minimum (1 day) As I probably mentioned in Amsterdam, an expire of just one week is almost always way too short. An Easter weekend with some days off for the administrator too easily destroy the zone completely. The value should be at least 4 weeks, because there is really no benefit from shorter expire. For the other fields fixed values are probably not appropriate in a recommendation. The usual case of one host inside a zone can have far larger TTLs and the values of refresh and retry depend on whether NOTIFY is available or not. Additionally, they are only relevant for the providers of secondary service. If an ISP will allow the customer a refresh of 30 minutes, it's their problem. If, however, the default TTL is only 3600, that affects third parties. > MX When pointing a domain to a mailserver/hostname, don=B4t forget to > add a glue record ( A ) for this. It's the other way round. If customer X adds MX RRs to his zone pointing to the providers mail relay, the customer MUST NOT add any A-RRs for that host. Modern versions of BIND fortunately do not allow out of zone data. > domain.xx. 86400 MX 10 mail.domain.xx. > =20 > mail.domain.xx 86400 A 192.168.0.1 maybe we should recommend As a target of an MX or NS resource record only domain names are allowed which directly resolve into an address. That means: 1) The name you enter must exist. Note that your software may let you enter names which do not exist without complaining. It is the DNS administrators responsibility to check this. A very helpful tool for this purpose is host ["reference here"]. 2) The name must really be a name. The DNS will not understand IP addresses here. Note however, that again your software may let you make the mistake but that it will definitely not bring you the results you wanted. Use only domain names here. 3) The domain name used must directly resolve into an address, which means you must not use an alias name here and an A resource record must exist for that name. Note that unless the name is part of your namespace you must not enter that A record yourself. > A A gluerecord can only point to an IP address. Avoid the term "glue record" here. -Peter From bmanning at ISI.EDU Thu May 14 18:13:35 1998 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Thu, 14 May 1998 09:13:35 -0700 (PDT) Subject: Recommendations for DNS In-Reply-To: <9805141426.AA26432@banknet.banknet.net> from "Janos Zsako" at May 14, 98 04:26:53 pm Message-ID: <199805141613.AA22646@zed.isi.edu> > > > From owner-dns-wg at ripe.net Thu May 14 15:54:09 1998 > > From: Hans Niklasson > > Hans, > > > Illegal characters: > > > > Only a-z , 0-9 and - is valid to use. All other characters is > > illegal and can cause the resolving to fail. > > I think it is worthwile at least mentioning that this restriction applies > to _hostnames_ (e.g. right hand side of NS or MX records). This does not > necessarily apply elsewhere. The third document you give as additional > reading (draft-ietf-dnsind-classless-inaddr-04.txt) does use a character > that is not in the set above (slash). > > This topic is very well clarified in RFC 2181 chapter 11. (Name syntax). > > Best regards, > Janos 27% more /nfs/ftp/internet-drafts/draft-ietf-dnsind-classless-inaddr-04.txt A new Request for Comments is now available in online RFC libraries. BCP 20: RFC 2317: Title: Classless IN-ADDR.ARPA delegation Author(s): H. Eidnes, G. de Groot, P. Vixie Status: Best Current Practice Date: March 1998 Mailbox: Havard.Eidnes at runit.sintef.no, GeertJan.deGroot at bsdi.com, paul at vix.com Pages: 10 Characters: 17744 Updates/Obsoletes: None URL: ftp://ftp.isi.edu/in-notes/rfc2317.txt -- --bill From pk at TechFak.Uni-Bielefeld.DE Thu May 14 17:20:12 1998 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Thu, 14 May 1998 17:20:12 +0200 Subject: Recommendations for DNS In-Reply-To: Your message of "Thu, 14 May 1998 16:14:15 +0200." Message-ID: <199805141520.RAA18822@gunilla.TechFak.Uni-Bielefeld.DE> Hello, thanks for coming up with this again. > SOA The address in this field must be a valid e-mail address to the > administrator for the DNS. > *** It's also good practise to have role address instead of > =09=09personal, ie root.. admin.. hostmaster..=20 > =09=09(when domain-administrator is leaving your company, you=20 > =09=09only change the alias for role address). the three most common errors are: 1) Use of '@' in the DNS representation of the email address. It is essential that the '@' be encoded as '.'. One reason even knowledgable people use '@' is that you cannot publish addresses containing a dot in the local part this way. So, the popular scheme 'first.last at canonical.example' does not qualify for 1:1 translation. Usually you would (and you do, indeed) recommend using a canonical address like 'hostmaster at canonical.example' to avoid this. Another class of addresses are those from e.g. CompuServe. Just don't use them. 2) Useless defaults an unfortunately increasingly popular DNS server software suggests "administrator" either as a single label or with the zone name or probably the primary's name concatenated to it. While the first is even syntactically incorrect, mails to one of the latter nearly always bounces because the addresses have never been made valid. 3) copy 'n paste While it is tempting to use 'ns.bad.example' as the primary server for 'bad.example' and then to use 'root.ns.bad.example' as the "hostmaster" address, customers often forget one of the following: a) In most cases, although there exists an A-RR for ns.bad.example, that is not the "real" name of the host specified. To receive mail for root at ns.bad.example, the host must be informed to treat ns.bad.example as local. One of the strangest errors is receiving a mail from postmaster at schizo.example telling you that the address postmaster at schizo.example does not exist and then asking you to send further questions to, guess, postmaster at schizo.example. b) In other environments ns.bad.example is set up to handle DNS but for various reasons will not accept SMTP connections and does not have MX RRs defined for its name. During the last five years I've been sending hundreds of emails every month after evaluating the DE hostcount and most of the undeliverable mail fail due to one of the errors above (usually 15-20% of the tickets bounce.) > domain.xx. 3600 SOA dns.domain.xx admin.domain.xx.=20 IMHO there's no need to have a TTL of 3600 for the SOA, except that the software mentioned above seems to default to this value. > 28800 ; refresh (8 hours) > 7200 ; retry (2 hour) > 604800 ; expire (7 days) > 86400 ) ; minimum (1 day) As I probably mentioned in Amsterdam, an expire of just one week is almost always way too short. An Easter weekend with some days off for the administrator too easily destroy the zone completely. The value should be at least 4 weeks, because there is really no benefit from shorter expire. For the other fields fixed values are probably not appropriate in a recommendation. The usual case of one host inside a zone can have far larger TTLs and the values of refresh and retry depend on whether NOTIFY is available or not. Additionally, they are only relevant for the providers of secondary service. If an ISP will allow the customer a refresh of 30 minutes, it's their problem. If, however, the default TTL is only 3600, that affects third parties. > MX When pointing a domain to a mailserver/hostname, don=B4t forget to > add a glue record ( A ) for this. It's the other way round. If customer X adds MX RRs to his zone pointing to the providers mail relay, the customer MUST NOT add any A-RRs for that host. Modern versions of BIND fortunately do not allow out of zone data. > domain.xx. 86400 MX 10 mail.domain.xx. > =20 > mail.domain.xx 86400 A 192.168.0.1 maybe we should recommend As a target of an MX or NS resource record only domain names are allowed which directly resolve into an address. That means: 1) The name you enter must exist. Note that your software may let you enter names which do not exist without complaining. It is the DNS administrators responsibility to check this. A very helpful tool for this purpose is host ["reference here"]. 2) The name must really be a name. The DNS will not understand IP addresses here. Note however, that again your software may let you make the mistake but that it will definitely not bring you the results you wanted. Use only domain names here. 3) The domain name used must directly resolve into an address, which means you must not use an alias name here and an A resource record must exist for that name. Note that unless the name is part of your namespace you must not enter that A record yourself. > A A gluerecord can only point to an IP address. Avoid the term "glue record" here. -Peter From Y.Adamopoulos at noc.ntua.gr Fri May 15 20:17:47 1998 From: Y.Adamopoulos at noc.ntua.gr (Yiorgos Adamopoulos) Date: Fri, 15 May 1998 21:17:47 +0300 Subject: Recommendations for DNS In-Reply-To: <199805141520.RAA18822@gunilla.TechFak.Uni-Bielefeld.DE>; from Peter Koch on Thu, May 14, 1998 at 05:20:12PM +0200 References: <199805141520.RAA18822@gunilla.TechFak.Uni-Bielefeld.DE> Message-ID: <19980515211747.16978@noc.ntua.gr> On Thu, May 14, 1998 at 05:20:12PM +0200, Peter Koch wrote: > 2) Useless defaults > an unfortunately increasingly popular DNS server software suggests > "administrator" either as a single label or with the zone name or > probably the primary's name concatenated to it. While the first is > even syntactically incorrect, mails to one of the latter nearly always > bounces because the addresses have never been made valid. Knowledgable people, should be able to hand-edit these software's produced files ;-) One thing I've discovered is that a SOA delegation cannot be followed by a A RR if you use the tools provided ;-) From JimFleming at unety.net Fri May 15 20:23:01 1998 From: JimFleming at unety.net (Jim Fleming) Date: Fri, 15 May 1998 13:23:01 -0500 Subject: Recommendations for DNS Message-ID: <01BD8004.96A0FF80@webster.unir.net> On Friday, May 15, 1998 1:17 PM, Yiorgos Adamopoulos[SMTP:Y.Adamopoulos at noc.ntua.gr] wrote: @On Thu, May 14, 1998 at 05:20:12PM +0200, Peter Koch wrote: @> 2) Useless defaults @> an unfortunately increasingly popular DNS server software suggests @> "administrator" either as a single label or with the zone name or @> probably the primary's name concatenated to it. While the first is @> even syntactically incorrect, mails to one of the latter nearly always @> bounces because the addresses have never been made valid. @ @Knowledgable people, should be able to hand-edit these software's produced @files ;-) One thing I've discovered is that a SOA delegation cannot be @followed by a A RR if you use the tools provided ;-) @ @ In the IPv8 Plan, an A resource record (RR) for the Top Level Domain contains a 32 bit quantity that is similar to a Program Status Word (PSW) on a CPU. This is used to encode the addressing mode for addresses that come from that TLD authority. It is surprising how many people think that A RRs can only contain IP addresses. They are really just object containers for the class 32 bit Integer. TXT records hold Strings and AAAA records hold 128 bit Integers. The DNS could be used for much more, once people are allowed to be creative... - Jim Fleming Unir Corporation - http://www.unir.net IPv8 - Designed for the Rest of the Human Race AM Radio Stations ---> http://www.DOT.AM From JimFleming at unety.net Fri May 15 20:23:01 1998 From: JimFleming at unety.net (Jim Fleming) Date: Fri, 15 May 1998 13:23:01 -0500 Subject: Recommendations for DNS Message-ID: <01BD8004.96A0FF80@webster.unir.net> On Friday, May 15, 1998 1:17 PM, Yiorgos Adamopoulos[SMTP:Y.Adamopoulos at noc.ntua.gr] wrote: @On Thu, May 14, 1998 at 05:20:12PM +0200, Peter Koch wrote: @> 2) Useless defaults @> an unfortunately increasingly popular DNS server software suggests @> "administrator" either as a single label or with the zone name or @> probably the primary's name concatenated to it. While the first is @> even syntactically incorrect, mails to one of the latter nearly always @> bounces because the addresses have never been made valid. @ @Knowledgable people, should be able to hand-edit these software's produced @files ;-) One thing I've discovered is that a SOA delegation cannot be @followed by a A RR if you use the tools provided ;-) @ @ In the IPv8 Plan, an A resource record (RR) for the Top Level Domain contains a 32 bit quantity that is similar to a Program Status Word (PSW) on a CPU. This is used to encode the addressing mode for addresses that come from that TLD authority. It is surprising how many people think that A RRs can only contain IP addresses. They are really just object containers for the class 32 bit Integer. TXT records hold Strings and AAAA records hold 128 bit Integers. The DNS could be used for much more, once people are allowed to be creative... - Jim Fleming Unir Corporation - http://www.unir.net IPv8 - Designed for the Rest of the Human Race AM Radio Stations ---> http://www.DOT.AM From UnitedWorldFriends at linxzit.net Wed May 20 13:06:45 1998 From: UnitedWorldFriends at linxzit.net (UnitedWorldFriends at linxzit.net) Date: Wed, 20 May 1998 13:06:45 Subject: World Friends Message-ID: <9805202043.AA04075@ncc.ripe.net> United World Friends Invitation # 201029 Dear World Friend: I am sure that by now you have tried all the "Get-Rich-Quick" schemes out there, and are ready and willing to turn your attention to something that really works. Most people are. Read on to unlock this Secret Door to your future. Would you like to quietly make extra money every month, year after year, and all of it be tax free? I knew you would. Now you can with the help of our World-Wide private network of friends helping friends. I would like to invite you to join a very special group of people and make the kind of money you are seeking. We have a private program based in the USA that extends around the entire world. Most of us are middle-aged or older, conservative and family oriented. We all made the commitment to do whatever we have to do -- as long as it is ethical, honest and legal -- to make tremendous income together in the years ahead. We have all `been there and done that' very much like you. We can all make money quietly and privately in comfort. You will not get rich overnight. If you want to get rich quick, this is not for you. By keeping it among private members, we can all profit handsomely in the coming months and years without drawing unnecessary attention to ourselves or our confidential strategies. I will show you how we use our unique, controlled, and honest program to put you in whatever income bracket you choose. All I want you to do is send $3.00 (to cover printing and postage) and I will send you all of our detailed information on how the club works and how everyone helps everyone. There is a one-time $10.00 set-up fee to become a member. Do not send the $10.00 now. If you like what you see after you review the information, then you can send in your $10.00 membership fee. We know you will like what you see. Our program will not interfere with any other programs in which you are participating. I will show you just how easy and powerful this program really is. Your tax-free cash gifts will come to you in increments of $10.00, not one or two dollars like some of the other programs out there. The money you can make is extraordinary, and we do most of the work. Our powerful Pentium servers and software keep track of everything for you.. You owe it to yourself to take a look and then decide if you would like to receive the kind of money that most people can only dream about. You will spend more than $3.00 on snacks today. Your future is worth more than a snack. No one will call you. No one will come see you. There is no pressure. You do not have to talk to anyone. You decide if you want to be part of our private network on your own after you review the information package. This is a private club with the privacy of each and every member protected. Quiet, confidential and comfortable. Mail this ENTIRE LETTER along with $3.00 inside US - $4.00 outside US (CASH only USD) for printing and postage to: UWF-Info * POBox 802-cp * CLEMMONS NC * 27012-0802 * USA Name: ______________________________________________________________ Address: __________________________________________________________ City: _______________________ State: _________ Zip: ____________ Country: ____________________ Email: ____________ at ________________ #201029 From jhma at EU.net Thu May 21 15:44:35 1998 From: jhma at EU.net (James Aldridge) Date: Thu, 21 May 1998 15:44:35 +0200 Subject: Recommendations for DNS In-Reply-To: Your message of "Thu, 14 May 1998 16:40:00 +0200." <199805141440.QAA08952@aegir.EU.net> Message-ID: <199805211344.PAA18847@aegir.EU.net> Last week I wrote: > If anyone is interested (and doesn't want to reinvent the wheel), I've got a > short perl script which generates suitable numbers and replaces a magic > token (%SERIAL%) in zone files when installing updates which I can tidy up a > bit and make available. Several people have asked me for this script. Since returning from Stockholm I've now had the chance to tidy it up a bit and add some basic documentation (a Unix manual page). The "inst-zone" script can now be found at http://www.staff.EU.net/jhma/dns/ Please note that I don't claim that this is the most efficient script in the world and also note that any comments on my Perl coding style will be quietly ignored ;-) Regards, James ----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 622 4657 - ----- 24hr emergency number: +31 20 421 0865 From mattu at cgi.interbusiness.it Fri May 22 13:00:55 1998 From: mattu at cgi.interbusiness.it (Gian Luca Mattu) Date: Fri, 22 May 1998 13:00:55 +0200 (MET DST) Subject: No subject Message-ID: <199805221053.MAA12943@cgi.interbusiness.it.interbusiness.it> help