1 / 99

Applications

Applications. Chapter 9. Host Names (DNS). Overview. Names versus Addresses names are variable length, mnemonic, easy for humans to remember addresses are fixed length, tied to routing, and easy for computers to process Name Space defines set of possible names flat versus hierarchical

jalila
Download Presentation

Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Applications Chapter 9

  2. Host Names (DNS)

  3. Overview • Names versus Addresses • names are variable length, mnemonic, easy for humans to remember • addresses are fixed length, tied to routing, and easy for computers to process • Name Space • defines set of possible names • flat versus hierarchical • consists of a set of name to value bindings

  4. Address Assignment • Network Information Center (NIC) used to maintain all name to address bindings • Limited scalability • Distributed name servers now used

  5. Domain Hierarchy • Example hierarchy • Example name: cheltenham.cs.arizona.edu

  6. Name Servers • Partition hierarchy into zones • Each zone implemented by two or more name servers

  7. Resource Records • Each name server maintains a collection of resource records • <Name, Value, Type, Class, TTL> • Name/Value: not necessarily host names to IP addresses • Type • NS: the Value field gives the domain name for a host running a name server that knows how to resolve names within the specified domain. • CNAME: the Value field gives the canonical name for a particular host; it is used to define aliases. • MX: the Value field gives the domain name for a host running a mail server that accepts messages for the specified domain. • Class: allow other entities to define types • TTL: how long the resource record is valid

  8. Example The edu Root server has a record for each second level server <arizona.edu, telcom.arizona.edu, NS, IN> <telcom.arizona.edu, 128.196.128.233, A, IN> <bellcore.com, thumper.bellcore.com, NS, IN> <thumper.bellcore.com, 128.96.32.20, A, IN>

  9. Arizona server: <cs.arizona.edu, optima.cs.arizona.edu, NS, IN> <optima.cs.arizona.edu, 192.12.69.5, A, IN> Third level name server <ece.arizona.edu, helios.ece.arizona.edu, NS, IN> <helios.ece.arizona.edu, 128.196.28.166, A, IN> Third level name server <jupiter.physics.arizona.edu, 128.196.4.1, A, IN> <saturn.physics.arizona.edu, 128.196.4.2, A, IN> <mars.physics.arizona.edu, 128.196.4.3, A, IN> <venus.physics.arizona.edu, 128.196.4.4, A, IN> Final address records

  10. CS server: <cs.arizona.edu, optima.cs.arizona.edu, MX, IN> Mail server for domain translation <cheltenham.cs.arizona.edu, 192.12.69.60, A, IN> <che.cs.arizona.edu, cheltenham.cs.arizona.edu, CNAME, IN> Alias definition <optima.cs.arizona.edu, 192.12.69.5, A, IN> <opt.cs.arizona.edu, optima.cs.arizona.edu, CNAME, IN> <baskerville.cs.arizona.edu, 192.12.69.35, A, IN> <bas.cs.arizona.edu, baskerville.cs.arizona.edu, CNAME, IN>

  11. Name Resolution • Strategies • forward • iterative • recursive • Local server • need to know root at only one place (not each host) • site-wide cache

  12. Names • Domain Name used by humans • Translated to IP number by name server • IP number used to route in internet • Forwarding occurs until packet reaches physical network • ARP is used to translate into a physical address • Physical address is unique and will be used to direct the packet to the correct machine

  13. SMTP Mail Mail gateway Mail reader reader Mail Mail Mail daemon daemon daemon SMTP/TCP SMTP/TCP Chapter 9, Figure 6

  14. Internet IMAP store POP Store A Typical Mail Environment SMTP IMAP Mail Server Mail Server Mail Client SMTP POP SMTP Mail Client

  15. ‘Email’ is defined by RFC 821 and RFC 822 • Internet email, that is; not to be confused with LAN email such as cc:Mail or MS Mail, which use proprietary protocols • RFC 821 defines the SMTP protocol • How mail MTAs exchange messages • RFC 822 defines what a mail message looks like

  16. How Email Really Works Your Computer My computer “Hey, I’ve got some mail here! Anybody home?” “(yawn) Yeah, yeah, I’m here...” “This is for Joe Schmoe - you know him?” “I’ll take it ...” “OK, here it comes!” “Got it!” “See ya later!” “Bye!”

  17. SMTP looks exactly like this $ telnet/port=25 arizona.edu Trying... Connected to ARIZONA.EDU. 220 Arizona.EDU -- Server ESMTP (PMDF V4.3-10 #2381) helo opus1.com 250 Arizona.EDU OK, Tennis.Opus1.COM. mail from:<trumbo@opus1.com> 250 Address Ok. rcpt to:<face@arizona.edu> 250 face@arizona.edu OK. data 354 Enter mail, end with a single ".". This is where all the rest of the headers go ... . 250 Ok. quit 221 Bye received. Goodbye. $ red sending mailer blue receiving mailer

  18. The Commands areFew and Specific $ telnet/port=25 arizona.edu Trying... Connected to ARIZONA.EDU. 220 Arizona.EDU -- Server ESMTP (PMDF V4.3-10 #2381) helo opus1.com 250 Arizona.EDU OK, Tennis.Opus1.COM. mailfrom:<trumbo@opus1.com> 250 Address Ok. rcptto:<face@arizona.edu> 250 face@arizona.edu OK. data 354 Enter mail, end with a single ".". This is where all the rest of the headers go ... . 250 Ok. quit 221 Bye received. Goodbye.

  19. SMTP Reply Codes $ telnet/port=25 arizona.edu Trying... Connected to ARIZONA.EDU. 220 Arizona.EDU -- Server ESMTP (PMDF V4.3-10 #2381) helo opus1.com 250 Arizona.EDU OK, Tennis.Opus1.COM. mail from:<trumbo@opus1.com> 250 Address Ok. rcpt to:<face@arizona.edu> 250 face@arizona.edu OK. data 354 Enter mail, end with a single ".". This is where all the rest of the headers go ... . 250 Ok. quit 221 Bye received. Goodbye.

  20. 354 Reply Codes Contain a Lot of Information The first digit indicates success, failure, or incomplete The third digit is the specific message for that category The second digit is the category of error message In fact, only the reply codes count. Other information in a reply is purely for human consumption.

  21. Most Common Reply Codes 500 Syntax error, command unrecognized 501 Syntax error in parameters or arguments 502 Command not implemented 503 Bad sequence of commands 220 <domain> Service ready 221 <domain> Service closing transmission channel 421 <domain> Service not available, closing transmission channel[This may be a reply to any command if the service knows it must shut down] 250 Requested mail action okay, completed 354 Start mail input; end with <CRLF>.<CRLF> 550 Requested action not taken: mailbox unavailable[E.g., mailbox not found, no access] 553 Requested action not taken: mailbox name not allowed[E.g., mailbox syntax incorrect] 554 Transaction failed The first digit indicates status: 1 - 3 success 4 temp negative 5 failure The second digit is type of error: 0 syntax 2 connection 5 mail

  22. RFC821 Defines all the Reply Codes • The numeric codes are definitive • The text is just for us humans • Most mailers follow the RFC821 suggeted text, but some of them get fun and creative • You can’t make up new reply codes for a special situation • That’s what being a protocol is all about

  23. How to Forge Email $ telnet/port=25 arizona.edu Trying... Connected to ARIZONA.EDU. 220 Arizona.EDU -- Server ESMTP (PMDF V4.3-10 #2381) helo big.brother 250 Arizona.EDU OK, Tennis.Opus1.COM. mail from:<watcher@Arizona.EDU> 250 Address Ok. rcpt to:<trumbo@Arizona.EDU> 250 trumbo OK. data 354 Enter mail, end with a single ".". Do you know where your kids are at 10 pm?? . 250 Ok. quit 221 Bye received. Goodbye. Connection closed by Foreign Host

  24. ... and the resultant raw mail Return-path: <watcher@Arizona.EDU> Received: from big.brother (Tennis.Opus1.COM) by Arizona.EDU (PMDF V4.3-10 #2381) id <01HQ2SPP1T68A8CC48@Arizona.EDU>; Wed, 03 May 1995 19:17:47 -0700 (MST) Date: Wed, 03 May 1995 19:17:47 -0700 (MST) Date-warning: Date header was inserted by Arizona.EDU From: watcher@Arizona.EDU To: trumbo@Arizona.EDU Message-id: <01HQ2SQE2ZKYA8CC48@Arizona.EDU> Do you know where your kids are at 10 pm??

  25. Using VRFY/EXPN $ telnet/port=25 cs.arizona.edu Trying... Connected to OPTIMA.CS.ARIZONA.EDU, a SUN-4/75 running SUN4.1.1. 220 optima.cs.arizona.edu Sendmail 5.65c/15 ready at Fri, 4 Dec 1994 14:21:53 MST vrfy ric 250 Ric Anderson <ric> expn live-music 550 live-music... User unknown expn live_music 250-<menze@univers> 250-<cliff@javelina> 250-<trumbo@arizona.edu> 250-<FICO@arizona.edu> ... 250 <face@dirnet.ccit.arizona.edu> quit 221 optima.cs.arizona.edu closing connection $

  26. Beware of vrfyon some mailers! $ telnet/port=25 arizvm1.ccit.arizona.edu Trying... Connected to ARIZVM1.CCIT.ARIZONA.EDU, an IBM 3090-300E running VM/XA. 220 ARIZVM1.ccit.arizona.edu running IBM VM SMTP V2R2 on Sun, 09 Oct 94 13:50:11 MST vrfy foo 250 <foo@ARIZVM1.ccit.arizona.edu> via MAILER@ARIZVM1 vrfy blatz 250 <blatz@ARIZVM1.ccit.arizona.edu> via MAILER@ARIZVM1 vrfy thiscouldnotbearealusername 250 <thiscouldnotbearealusername@ARIZVM1.ccit.arizona.edu> via MAILER@ARIZVM1 vrfy taryn 250 <taryn@ARIZVM1.ccit.arizona.edu> via MAILER@ARIZVM1 quit 221 ARIZVM1.ccit.arizona.edu running IBM VM SMTP V2R2 closing connection Connection closed by Foreign Host

  27. SMTP Extensions (EHLO) • After careful consideration, a few extensions have been added to the SMTP protocol • A mailer supporting extensions uses EHLO instead of HELO in the greeting • The server will respond to indicate it can negotiate extensions • If the server gives a failure to the EHLO, the client SMTP reverts back to plain ol’ SMTP • Sometimes called the ‘eight-bit HELO’, but other extensions are included as well • Described in RFC1651

  28. An EHLO with Extensions $ telnet/port=25 dbc.mtview.ca.us Trying... Connected to DBC.MTVIEW.CA.US, a SUN-SPARC running UNIX. 220 dbc.mtview.ca.us SMTP server ready. ehlo 250-Hello , pleased to meet you 250-HELP 250-SIZE 250-XONE 250-XVRB 250 XQUE quit 221 dbc.mtview.ca.us closing connection Connection closed by Foreign Host A mailer that supports extensions responds with a list of which ones it can do

  29. EHLO with an Old Mailer $ telnet/port=25 arizvm1.ccit.arizona.edu. Trying... Connected to ARIZVM1.CCIT.ARIZONA.EDU, an IBM 3090-300E running VM/XA. 220 ARIZVM1.ccit.arizona.edu running IBM VM SMTP V2R2 on Tue, 25 Apr 95 21:09:1T ehlo arizona.edu 500 Unknown command, 'ehlo'

  30. Defined SMTP Extensions The non-required SMTP command set: Service Ext EHLO Keyword Parameters Verb Added Behavior ------------- ------------ ---------- ---------- ------------------ Send SEND none SEND defined in RFC 821 Send or Mail SOML none SOML defined in RFC 821 Send and Mail SAML none SAML defined in RFC 821 Expand EXPN none EXPN defined in RFC 821 Help HELP none HELP defined in RFC 821 Turn TURN none TURN defined in RFC 821 Later additions, defined in other RFCs: EHLO RFC1651 “SMTP Service Extensions” 8BITMIME RFC1652, “SMTP Service Extension for 8bit-MIME transport” SIZE RFC1653, “SMTP Service Extension for Message Size Declaration” X extensions (defined to be undefined)

  31. SMTP ProtocolKey Concepts • Get copies of the RFCs and have them on-disk and on-desk for easy perusal • You need to know the basics of SMTP by heart • Using SMTP as a debugging tool is a favorite technique of effective postmasters

  32. DECUS Fall 1996 Barcelona RFC-822 Email Headers and How to Read Them

  33. A TypicalMail Message Return-path: <CAPUTO@decus.org> Received: from DIRECTORY-DAEMON by Spring.Tucson.AZ.US (PMDF V4.3-12 #2381) id <01HPLO2VX9YO934XSG@Spring.Tucson.AZ.US>; Fri, 21 Apr 1995 13:00:23 -0700 (MST) Received: from Topaz.DECUS.Org by Spring.Tucson.AZ.US (PMDF V4.3-12 #2381) id <01HPLO2XDUE891WFCC@Spring.Tucson.AZ.US>; Fri, 21 Apr 1995 13:00:25 -0700 (MST) Received: from mr.decus.org by DECUS.Org (PMDF V4.2-13 #7924) id <01HPLU4NRVK09APFGQ@DECUS.Org>; Fri, 21 Apr 1995 15:53:47 EST Received: with PMDF-MR; Fri, 21 Apr 1995 15:46:10 GMT MR-Received: by mta TOPAZ; Relayed; Fri, 21 Apr 1995 15:46:10 +0000 Alternate-recipient: prohibited

  34. A Typical Mail Message (continued) Subject: Seminar S306 To: trumbo@Opus1.COM, jms@Opus1.COM Message-id: <E437ZVSNMJW0T*/R=TOPAZ/R=A1/U=CAPUTO/@MHS> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Posting-date: Fri, 21 Apr 1995 20:46:00 +0000 (GMT) Importance: normal Priority: normal Sensitivity: Company-Confidential UA-content-id: E437ZVSNMJW0T X400-MTS-identifier: [;01645112405991/423375@TOPAZ] A1-type: MAIL Hop-count: 0 Jan and Joel, your seminar is a GO with an attendee count of 10. See ya there! -Gloria

  35. Some Headers are More Important than Others • Required headers • From: [ Resent-From ] • Date: [ Resent-Date ] • one recipient address: To [ Resent-To ] cc [ Resent-cc ] bcc [ Resent-bcc ] (“Blind” carbon copy) From: IN%"SYSTEM@Arizona.EDU" To: IN%"trumbo@Arizona.EDU" Date: Thu, 20 Apr 1995 01:00:24 -0700 (MST)

  36. Anatomy of a Mail Message Order of headers is not important Some headers are required Return-path: <SYSTEM@Arizona.EDU> Received: from Arizona.EDU by Arizona.EDU (PMDF V4.3-10 #2381) id <01HPJKMXKY1C9JEUK1@Arizona.EDU>; Thu, 20 Apr 1995 01:00:24 -0700 (MST) Date: Thu, 20 Apr 1995 01:00:24 -0700 (MST) From: SYSTEM@Arizona.EDU Subject: Scheduler Job #23 (NAME: TMS-CHECK-DAILY-MVS-JOBS) finished, Status: %NONAME-W-NOMSG, Message number 00000000 To: trumbo@Arizona.EDU Message-id: <01HPJKMXLHBM9JEUK1@Arizona.EDU> X-VMS-To: TMS_DBA X headers are for private use Blank line separates message body Job TMS-CKECK-DAILY-MVS-JOBS complete. Status: %NONAME-W-NOMSG, Message number 00000000 Return-path: <SYSTEM@Arizona.EDU> Received: from Arizona.EDU by Arizona.EDU (PMDF V4.3-10 #2381) id <01HPJKMXKY1C9JEUK1@Arizona.EDU>; Thu, 20 Apr 1995 01:00:24 -0700 (MST) Headers at the bottom don’t count as headers

  37. Originator Headers: who it comes from • From [ Resent-From ] • The agent (person, system or process) that created the message. Should be a single, authenticated machine address generated by the sending agent.

  38. Originator Headers:who sent it on to you • Sender [ Resent-Sender ] • The agent(person, system or process) that sends the message. Intended for use when the sender is not the author of the message, or is one of a group of authors. Not to be used if identical to From field. The Sender field must be present if different from the From field. • Used by lists in this way: From: "Frits A.M. Storms" <STO@MH.NL> Sender: INFO-VAX Discussion <INFO-VAX@UGA.BITNET> To: Multiple recipients of list INFO-VAX <INFO-VAX@UGA.BITNET>

  39. Originator Headers:best reply address • Reply-To [ Resent-Reply-To ] • a mailbox where responses are to be sent, often used by list mail: From: "Frits A.M. Storms" <STO@MH.NL> Subject: Re: Can Satellite Node Crash-Dump into Page File on Local Disk? In-reply-to: Mike's message of 20 May 1995 20:17:28 GMT Sender: INFO-VAX Discussion <INFO-VAX@UGA.BITNET> To: Multiple recipients of INFO-VAX <INFO-VAX@UGA.BITNET> Reply-to: INFO-VAX@SRI.COM Note how the Reply-to: field is used intelligently to direct mail to their preferred address.

  40. Date Header is Required • Orig-date or Resent-date field • Just what it looks like: Date: Sat, 22 May 1993 05:46:55 +0000 (GMT) • The only optional parts of the date specification are the day of the week and the seconds. • Timezone may be given in the usual ways: EST, EDT, etc, UT, GMT, even military (Z,A,B,M,N). • Timezone is preferred as a numeric offset from GMT

  41. Recipient Headers At least one from this list must be present. • To [ Resent-To ] • cc [ Resent-cc ] • bcc [ Resent-bcc ] • Some systems show the bcc list only to the author; others show the bcc list to everyone on the bcc list Class quiz: What do we mean by ‘systems’ here? Is it the MTA or the MUA that hides the bcc list? A: It could be either the MUA or the MTA on the sending system.

  42. The Crucial Received Header Received: from CGNET.COM by Arizona.EDU (PMDF V4.3-9 #2381) id <01HGUMM9OTUO9AR7DY@Arizona.EDU>; Thu, 08 Sep 1994 00:39:13 -0700 (MST) Received: from faop.cgnet.com by CGNET.COM (PMDF V4.3-9 #7702) id <01HGUMN7N4S000370I@CGNET.COM>; Thu, 08 Sep 1994 00:40:08 -0700 (PDT) Received: from msmail.fao.org (191.0.1.130) by FAOVMS.CGNET.COM (PMDF V4.3-8 #3703) id <01HGV4ZD1XTC8WW39N@FAOVMS.CGNET.COM>; Thu, 08 Sep 1994 09:25:10 +0200 Received: by msmail.fao.org with Microsoft Mail id <2E79C6AC@msmail.fao.org>; Thu, 08 Sep 94 09:24:12 +02

  43. Received Lines are Key to What’s Going On • The postmaster’s primary debugging tool • Tells you which systems have touched (or possibly mangled) the mail • Each MTA that relays a message attaches its own Received header line • This is so important that MTA’s are required by RFC to add a Received line when they handle mail, and they are prohibited by RFC from touching the Received lines put on by other mailers.

  44. Received HeadersShow You the Path Received: from host 2 by host 3 Received: by host 2 from host 1 Received: by host 1 from host 0 Received: by host 0 3 2 1 2 Sender 1 0

  45. Hop by Hop You Can Follow Each Email Message Received: from CGNET.COM by Arizona.EDU (PMDF V4.3-9 #2381) id <01HGUMM9OTUO9AR7DY@Arizona.EDU>; Thu, 08 Sep 1994 00:39:13 -0700 (MST) Received: from faop.cgnet.com by CGNET.COM (PMDF V4.3-9# 7702) id <01HGUMN7N4S000370I@CGNET.COM>; Thu, 08 Sep 1994 00:40:08 -0700 (PDT) Received: from msmail.fao.org (191.0.1.130) by FAOVMS.CGNET.COM (PMDF V4.3-8 #3703) id <01HGV4ZD1XTC8WW39N@FAOVMS.CGNET.COM>; Thu, 08 Sep 1994 09:25:10 +0200 Received: by msmail.fao.org with Microsoft Mail id <2E79C6AC@msmail.fao.org>; Thu, 08 Sep 94 09:24:12 +02 host 2 ??? host 1 host 0 ??? Notice the difference in timezones!

  46. Received Line Information Received: from CGNET.COM by Arizona.EDU (PMDF V4.3-9 #2381) id <01HGUMM9OTUO9AR7DY@Arizona.EDU>; Thu, 08 Sep 1994 00:39:13 -0700 (MST) • Many optional fields: from sending host by receiving host via physical path (predefined values) with link/mail protocol (predefined values) id reciever message id for initial form • And one required field: date-time timestamp when message received

  47. Received: from fake.com (Penny.Telcom.Arizona.EDU)by Arizona.EDU (PMDF V4.3-10 #2381) id 01HPRDGE23PSA3CYNG@Arizona.EDU>; Tue, 25 Apr 1995 15:02:41 -0700 (MST) Received LineIP Address Authentication • Some mailers check to see that the domain name in the SMTP HELO command matches the IP address making the SMTP connection, and put this verified information in the Received line: • RFC1123, Requirements for Internet Hosts, requires that the receiver MUST NOT refuse to accept a message, even if the sender’s HELO command fails verification.

  48. The Crucial Message-ID Field • An optional but universally implemented header field • This is a unique identification in the context of the handling mailer • There is no defined format for message ids, except that they be unique identifiers • Invaluable for determining the source of mailing loops • Examples: <01GSJUORQXTW8Y4WV2@mr.gov.bc.ca> <9409011457.aa13678@clb_sj.clbooks.COM> <2D3D6235@courier.sscnet.ucla.edu> <9311087554.AA755405259@ccmail.orst.edu> <01GUH93WL9WI9377KN@Arizona.edu> <01HH17GNOB1U8WVYX1@CCIT.ARIZONA.EDU>

  49. Received Headers often contain the Message-ID • An optional, but widely implemented, component of the Received line • The same information as the orginating mailer’s Message-ID field, provided by all the intermediate mailers that handle the message • Lets you figure out if a repeated message is being regenerated by the sender, or if the same message is being resent by the sender. • Often lets you figure out which mailer is mailbombing you

More Related