From hasse at swip.net Tue Sep 22 09:27:00 1998 From: hasse at swip.net (Hans Niklasson) Date: Tue, 22 Sep 1998 09:27:00 +0200 (MET DST) Subject: Recommendations for DNS Message-ID: Greetings This is the action point from RIPE-28 thats in the final stage. I will be presenting this at RIPE-31 this Thursday. So any comments and suggestions will be looked at if they arrive before Thursday. Otherwise I?ll see you there. :) 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. To have a document for LIR:s to use for their customers instead of a number of RFC:s. 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: foo.bar.com. IN SOA dns.foo.bar.com admin.foo.bar.com 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) 1209600 ; expire (14 days) 86400 ) ; minimum (1 day) MX When pointing a domain to a mailserver/hostname, do not forget to add a record ( A ) for this. Ex: foo.bar.com. IN MX 10 mail.foo.bar.com. mail.foo.bar.com. IN A 192.168.0.1 CNAME Use this with caution. It is *not* recommended to use a CNAME for a mailservers hostname, as this can cause resolving problems and mailloops. Also it is not a good thing to use CNAMES on nameservers as this will cause unnecessary traffic on the net. A A record 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: Do not add unecessary glue data about hosts that is not within the zone. This can cause resolving problems if the host changes IP address. Ex: foo.bar.com. IN MX 10 mail.foo.bar.com. mail.foo.bar.com. IN A 192.168.0.1 Trailing dots: Do not 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: 11 PTR foo.test will produce foo.test.7.42.666.in-addr.arpa. Illegal characters: Only a-z , 0-9 and - is valid to use. The domain system allows a label to contain any 8-bit character. Although the domain system has no restrictions, other protocols such as SMTP do have name restrictions. Because of other protocol restrictions, only the above characters are recommended for use in a host name (besides the dot separator). 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. Example on a recommended DNS: foo.bar.com IN SOA ns.foo.bar.com. root.foo.bar.com. ( 1998081900 ; serial 28800 ; refresh (8 hours) 7200 ; retry (2 hours) 1209600 ; expire (14 days) 86400 ) ; minimum (1 day) foo.bar.com. IN NS ns.foo.bar.com. foo.bar.com. IN NS ns2.foo.bar.com. foo.bar.com. IN MX 10 mail.foo.bar.com. www.foo.bar.com. IN CNAME www.webhotel.xx. www2.foo.bar.com. IN A 192.168.0.3 ns.foo.bar.com. IN A 192.168.0.1 ns2.foo.bar.com. IN A 192.168.0.4 mail.foo.bar.com. IN A 192.168.0.2 localhost IN A 127.0.0.1 Additional reading and references: RFC1537 ( RFC1912 ) ( Common DNS Operational and Configuration Errors ) RFC1033-5 RFC2181 "DNS & BIND 3nd Edition" by Paul Albitz & Cricket Liu from OReilly & 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 stephenb at uk.uu.net Tue Sep 22 10:33:44 1998 From: stephenb at uk.uu.net (Stephen Burley) Date: Tue, 22 Sep 1998 09:33:44 +0100 (BST) Subject: Recommendations for DNS In-Reply-To: Message-ID: I was hoping the SOA values recomended would be reduced particuaraly the ttl to increase convergance with the implementation of notify's. I agree the refresh and the retry realy do not nee to change that much but having such a high TTL means the dns will not converge for up to 24 hours. This means that the dns reocmendaed convergance time overall has not changed. What is the point of using notify's if the resolvers are not going to keep up. Just my thoughts. Stephen Burley  Senior HOSTMASTER for UUNET(UK) Internet House 332 Science Park, Milton Rd. Cambridge CB4 4BZ http://www.uk.uu.net Todays weirdness is tomorrows reasons why. On 22-Sep-98 Hans Niklasson wrote: > Greetings > > This is the action point from RIPE-28 thats in the final stage. > I will be presenting this at RIPE-31 this Thursday. > So any comments and suggestions will be looked at if they arrive before > Thursday. > Otherwise I4ll see you there. :) > > > 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. > To have a document for LIR:s to use for their customers instead of a > number of RFC:s. > > > 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: > > foo.bar.com. IN SOA dns.foo.bar.com admin.foo.bar.com > > > 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) > 1209600 ; expire (14 days) > 86400 ) ; minimum (1 day) > > MX When pointing a domain to a mailserver/hostname, do not forget > to add a record ( A ) for this. > > Ex: > > foo.bar.com. IN MX 10 mail.foo.bar.com. > > mail.foo.bar.com. IN A 192.168.0.1 > > > CNAME Use this with caution. It is *not* recommended to use a CNAME > for a mailservers hostname, as this can cause resolving problems > and mailloops. Also it is not a good thing to use CNAMES on > nameservers as this will cause unnecessary traffic on the net. > > A A record 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: > > Do not add unecessary glue data about hosts that is not within > the zone. This can cause resolving problems if the host changes IP > address. > > Ex: > > foo.bar.com. IN MX 10 mail.foo.bar.com. > > mail.foo.bar.com. IN A 192.168.0.1 > > > Trailing dots: > Do not 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: > > 11 PTR foo.test > > will produce foo.test.7.42.666.in-addr.arpa. > > > Illegal characters: > > Only a-z , 0-9 and - is valid to use. > The domain system allows a label to contain any 8-bit character. > Although the domain system has no restrictions, other protocols > such > as SMTP do have name restrictions. Because of other protocol > restrictions, only the above characters are recommended for use > in a host name (besides the dot separator). > > > 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. > > > Example on a recommended DNS: > > foo.bar.com IN SOA ns.foo.bar.com. root.foo.bar.com. ( > 1998081900 ; serial > 28800 ; refresh (8 hours) > 7200 ; retry (2 hours) > 1209600 ; expire (14 days) > 86400 ) ; minimum (1 day) > foo.bar.com. IN NS ns.foo.bar.com. > > foo.bar.com. IN NS ns2.foo.bar.com. > > foo.bar.com. IN MX 10 mail.foo.bar.com. > > www.foo.bar.com. IN CNAME www.webhotel.xx. > > www2.foo.bar.com. IN A 192.168.0.3 > > ns.foo.bar.com. IN A 192.168.0.1 > > ns2.foo.bar.com. IN A 192.168.0.4 > > mail.foo.bar.com. IN A 192.168.0.2 > > localhost IN A 127.0.0.1 > > > Additional reading and references: > > RFC1537 ( RFC1912 ) > ( Common DNS Operational and Configuration Errors ) > > RFC1033-5 > > RFC2181 > > "DNS & BIND 3nd Edition" by Paul Albitz & Cricket Liu > from OReilly & 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 > Stephen Burley  Senior HOSTMASTER for UUNET(UK) Internet House 332 Science Park, Milton Rd. Cambridge CB4 4BZ http://www.uk.uu.net Todays weirdness is tomorrows reasons why. From BERI at etf.bg.ac.yu Tue Sep 22 12:23:00 1998 From: BERI at etf.bg.ac.yu (Berislav Todorovic) Date: Tue, 22 Sep 1998 11:23 +0100 Subject: Recommendations for DNS Message-ID: >> This is the action point from RIPE-28 thats in the final stage. >> I will be presenting this at RIPE-31 this Thursday. >> So any comments and suggestions will be looked at if they arrive before >> Thursday. In general, the text is ok, though I think a more detailed text covering DNS is really needed. However, that can be left for some next iteration. Minor changes I would suggest here follow: >> To have a document for LIR:s to use for their customers instead of a >> number of RFC:s. I would add: "This document should be taken as a brief DNS reminder. For thorough understanding, reading RFC's and books, listed at the end of this document, is highly recommended". >> 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). I would add: "The 'at' ('@') sign of the email address should be replaced by a dot, e.g. instead of , the address should be specified as hostmaster.foo.bar.com, as given in the following example." >> MX When pointing a domain to a mailserver/hostname, do not forget >> to add a record ( A ) for this. I would add: "only if the hostname is within the zone (see below)". >> Additional reading and references: >> >> ftp://ftp.ripe.net/internet-drafts/draft-ietf-dnsind-classless- >> inaddr-04.txt >> ( For reverse delegation methods for blocks smaller than /24, >> 256 addresses ) This is outdated and has to be changed with the pointer to RFC 2317. Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI at etf.bg.ac.yu | /|\ Hostmaster of the YU TLD | |-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419 | \|/ Bulevar Revolucije 73 | 3370-106 | --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681 `-------' -------------------------------------------------------------------- From pk at TechFak.Uni-Bielefeld.DE Tue Sep 22 10:43:04 1998 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Tue, 22 Sep 1998 10:43:04 +0200 Subject: Recommendations for DNS In-Reply-To: Your message of "Tue, 22 Sep 1998 09:27:00 +0200." Message-ID: <199809220843.KAA20646@gunilla.TechFak.Uni-Bielefeld.DE> > Ex: > > foo.bar.com. IN SOA dns.foo.bar.com admin.foo.bar.com Add trailing dots if this is supposed to be in master file format. > MX When pointing a domain to a mailserver/hostname, do not forget > to add a record ( A ) for this. ... if and only if that target resides in the very same zone. > CNAME Use this with caution. It is *not* recommended to use a CNAME > for a mailservers hostname, as this can cause resolving problems > and mailloops. Also it is not a good thing to use CNAMES on > nameservers as this will cause unnecessary traffic on the net. Both are not only bad practice but forbidden by the protocol. >Unecessary glue data: > Do not add unecessary glue data about hosts that is not within > the zone. This can cause resolving problems if the host changes IP > address. > Ex: > > foo.bar.com. IN MX 10 mail.foo.bar.com. > > mail.foo.bar.com. IN A 192.168.0.1 Is this an example of what *not* to do? So how does it differ from the suggestion a few lines above? Otherwise, the term "glue" data is wrong. The only valid purpose of glue A RRs is to provide for the address of a nameserver residing in the domain tree in or below the zone it is delegated. > Example on a recommended DNS: s/DNS/zone file/ > foo.bar.com IN SOA ns.foo.bar.com. root.foo.bar.com. ( > 1998081900 ; serial > 28800 ; refresh (8 hours) > 7200 ; retry (2 hours) > 1209600 ; expire (14 days) > 86400 ) ; minimum (1 day) > foo.bar.com. IN NS ns.foo.bar.com. > > foo.bar.com. IN NS ns2.foo.bar.com. > > foo.bar.com. IN MX 10 mail.foo.bar.com. > > www.foo.bar.com. IN CNAME www.webhotel.xx. This cannot really be recommended. Extra zone CNAME-RRs have been the subject of long discussions and in most cases they are unnecessary. What users try to resemble by this is user-level aliasing, which is probably not a good idea here. > www2.foo.bar.com. IN A 192.168.0.3 > ns.foo.bar.com. IN A 192.168.0.1 > ns2.foo.bar.com. IN A 192.168.0.4 Having the zone served by only two nameservers inside that zone cannot be recommended. Especially, they're very likely connected to the same fuse, should "IP distance" reflect physical distance, which often holds :-) -Peter From woeber at cc.univie.ac.at Tue Sep 22 12:09:58 1998 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 22 Sep 1998 12:09:58 MET-DST Subject: Recommendations for DNS Message-ID: <009CC9AA.61D34DB2.12@cc.univie.ac.at> =>> 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). = =I would add: "The 'at' ('@') sign of the email address should be =replaced by a dot, e.g. instead of , the =address should be specified as hostmaster.foo.bar.com, as given =in the following example." With regard to the '@' sign hack, I'd rather use 'must' than 'should' :-) On top of that, I suggest to clearly describe the requirement to quote any "leading" dot(s) that are *not* supposed to be converted to an '@' character. Like in wilfried\.woeber.univie.ac.at ! Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 -------------------------------------------------------------------------- From bmanning at ISI.EDU Tue Sep 22 16:16:41 1998 From: bmanning at ISI.EDU (Bill Manning) Date: Tue, 22 Sep 1998 07:16:41 -0700 (PDT) Subject: Recommendations for DNS In-Reply-To: <009CC9AA.61D34DB2.12@cc.univie.ac.at> from "Wilfried Woeber, UniVie/ACOnet" at Sep 22, 98 12:09:58 pm Message-ID: <199809221416.HAA13322@zephyr.isi.edu> > On top of that, I suggest to clearly describe the requirement to quote > any "leading" dot(s) that are *not* supposed to be converted to an '@' > character. > Like in wilfried\.woeber.univie.ac.at ! > > Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at While this particular hack works, it is a clear violation of the spec. --bill From BERI at etf.bg.ac.yu Tue Sep 22 17:32:00 1998 From: BERI at etf.bg.ac.yu (Berislav Todorovic) Date: Tue, 22 Sep 1998 16:32 +0100 Subject: Recommendations for DNS Message-ID: >> > On top of that, I suggest to clearly describe the requirement to quote >> > any "leading" dot(s) that are *not* supposed to be converted to an '@' >> > character. >> > Like in wilfried\.woeber.univie.ac.at ! >> >> While this particular hack works, it is a clear violation of the spec. The simplest solution to the problem is to stick with the recommendation, already given in the proposed document: instead of using real addresses, usage of role accounts is preferred. A very good practice is to create the role account . Besides, it's recommended by the RFC 2142, which has STD status. Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI at etf.bg.ac.yu | /|\ Hostmaster of the YU TLD | |-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419 | \|/ Bulevar Revolucije 73 | 3370-106 | --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681 `-------' -------------------------------------------------------------------- From bmanning at ISI.EDU Tue Sep 22 18:10:46 1998 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Tue, 22 Sep 1998 09:10:46 -0700 (PDT) Subject: Recommendations for DNS In-Reply-To: <199809221602.SAA36808@snoopy.cc.univie.ac.at> from "andreas.papst@univie.ac.at" at Sep 22, 98 06:02:13 pm Message-ID: <199809221610.AA09610@zed.isi.edu> > > Bill Manning wrote: > > > > > On top of that, I suggest to clearly describe the requirement to quote > > > any "leading" dot(s) that are *not* supposed to be converted to an '@' > > > character. > > > Like in wilfried\.woeber.univie.ac.at ! > > > > > > Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at > > > > > > While this particular hack works, it is a clear violation of the spec. > > > > --bill > > > Which specs? At least this recommendation is part of RFC 1912: > > 2.2 SOA records > > In the SOA record of every zone, remember to fill in the e-mail > address that will get to the person who maintains the DNS at your > site (commonly referred to as "hostmaster"). The `@' in the e-mail > must be replaced by a `.' first. Do not try to put an `@' sign in > this address. If the local part of the address already contains a > `.' (e.g., John.Smith at widget.xx), then you need to quote the `.' by > preceding it with `\' character. (e.g., to become > John\.Smith.widget.xx) Alternately (and preferred), you can just use > the generic name `hostmaster', and use a mail alias to redirect it to > the appropriate persons. There exists software which uses this field > to automatically generate the e-mail address for the zone contact. > This software will break if this field is improperly formatted. It > is imperative that this address get to one or more real persons, > because it is often used for everything from reporting bad DNS data > to reporting security incidents. > > Andreas Ok, I was overly zelous in my reading of RFC1035. I like what Dave has published in RFC1912. --bill From bp at nic.dtag.de Tue Sep 22 16:34:14 1998 From: bp at nic.dtag.de (Berthold Paffrath) Date: Tue, 22 Sep 1998 16:34:14 +0200 Subject: Recommendations for DNS In-Reply-To: Your message of Tue, 22 Sep 1998 12:09:58 +0700. <009CC9AA.61D34DB2.12@cc.univie.ac.at> Message-ID: <199809221434.QAA05304@kronos.NIC.DTAG.DE> > On top of that, I suggest to clearly describe the requirement to quote > any "leading" dot(s) that are *not* supposed to be converted to an '@' > character. > Like in wilfried\.woeber.univie.ac.at ! and add a warning that, at least with versions of BIND before 4.9.3 and perhaps some of the usual tools, this does not always work as expected, so you better avoid having a dot in the username part if possible. Berthold Paffrath From pk at TechFak.Uni-Bielefeld.DE Tue Sep 22 17:20:29 1998 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Tue, 22 Sep 1998 17:20:29 +0200 Subject: Recommendations for DNS In-Reply-To: Your message of "Tue, 22 Sep 1998 07:16:41 PDT." <199809221416.HAA13322@zephyr.isi.edu> Message-ID: <199809221520.RAA21649@gunilla.TechFak.Uni-Bielefeld.DE> > > Like in wilfried\.woeber.univie.ac.at ! > > While this particular hack works, it is a clear violation of the spec. Which spec? This is exactly what RFC 1035, sections 5.1 and 5.3, say. However, it will not work properly with older versions of BIND, because between the AXFR and parsing of the zone the secondaries tend to 'forget' the quote. And older versions of dig & friends won't be able to tell whether a particular '.' is the label separator or part of a label. -Peter From simon at limmat.switch.ch Tue Sep 22 17:28:00 1998 From: simon at limmat.switch.ch (Simon Leinen) Date: 22 Sep 1998 17:28:00 +0200 Subject: Recommendations for DNS In-Reply-To: Bill Manning's message of "Tue, 22 Sep 1998 07:16:41 -0700 (PDT)" References: <199809221416.HAA13322@zephyr.isi.edu> Message-ID: >> Like in wilfried\.woeber.univie.ac.at ! > While this particular hack works, it is a clear violation of the spec. Well, RFC 1035 explicitly uses this in its examples, and RFC 1912 also mentions this in section 2.2 "SOA records". So it may be a hack, but it's an IETF-sanctioned hack :-) -- Simon. From andreas.papst at univie.ac.at Tue Sep 22 18:02:13 1998 From: andreas.papst at univie.ac.at (andreas.papst at univie.ac.at) Date: Tue, 22 Sep 1998 18:02:13 +0200 (MSZ) Subject: Recommendations for DNS In-Reply-To: <199809221416.HAA13322@zephyr.isi.edu> from "Bill Manning" at Sep 22, 98 07:16:41 am Message-ID: <199809221602.SAA36808@snoopy.cc.univie.ac.at> Bill Manning wrote: > > > On top of that, I suggest to clearly describe the requirement to quote > > any "leading" dot(s) that are *not* supposed to be converted to an '@' > > character. > > Like in wilfried\.woeber.univie.ac.at ! > > > > Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at > > > While this particular hack works, it is a clear violation of the spec. > > --bill > Which specs? At least this recommendation is part of RFC 1912: 2.2 SOA records In the SOA record of every zone, remember to fill in the e-mail address that will get to the person who maintains the DNS at your site (commonly referred to as "hostmaster"). The `@' in the e-mail must be replaced by a `.' first. Do not try to put an `@' sign in this address. If the local part of the address already contains a `.' (e.g., John.Smith at widget.xx), then you need to quote the `.' by preceding it with `\' character. (e.g., to become John\.Smith.widget.xx) Alternately (and preferred), you can just use the generic name `hostmaster', and use a mail alias to redirect it to the appropriate persons. There exists software which uses this field to automatically generate the e-mail address for the zone contact. This software will break if this field is improperly formatted. It is imperative that this address get to one or more real persons, because it is often used for everything from reporting bad DNS data to reporting security incidents. Andreas ________________________________________________________________________ Andreas Papst | E-Mail: andreas.papst at univie.ac.at | Phone: Vienna University Computer Center | +43 1 4277 / 140 36 Universitaetsstrasse 7 | Fax.: A-1010 Vienna, Austria, Europe | +43 1 4277 / 9 140