+ All Categories
Home > Documents > The Rapid Fire Survey of Management in IP Networks Dirk Grunwald Assoc. Professor Dept. of Computer...

The Rapid Fire Survey of Management in IP Networks Dirk Grunwald Assoc. Professor Dept. of Computer...

Date post: 27-Dec-2015
Category:
Upload: noel-shepherd
View: 216 times
Download: 2 times
Share this document with a friend
36
The Rapid Fire Survey of Management in IP Networks Dirk Grunwald Assoc. Professor Dept. of Computer Science University of Colorado, Boulder
Transcript

The Rapid Fire Survey ofManagement in IP Networks

Dirk GrunwaldAssoc. Professor

Dept. of Computer ScienceUniversity of Colorado, Boulder

What’s the problem?

Nodes in an IP network need names Map computer name to IP address Map IP address to ethernet address

How are names distributed, recorded and discovered?

We already discussed ARP / RARP

We’ll focus on DHCP here

DNS Overview

The problem: mapping hostnames like “foobar.cs.colorado.edu” to an IP address like 128.138.241.71

Terms Queries Response types Pragmatics

Terminology

The Domain Name System (DNS) is an unreliable database with distributed data and mangement

A resolver maps names to IP addresses using name servers

Hierarchical Naming

arpa com edu gov mil net org us

arpa

colordao

cs

foobar

in-addr

71

241

138

128

Naming

A host has a domain name specified using a sequence of names, each of which may be up to 63 characters long, separated by periods.

Names are case insensitive A domain is an absolute domain name or a fully qualified

domain name (FQDN) if it ends with a period. E.g., “foobar.cs.colorado.edu.”

Most generic domains (.com, .edu, etc) are international, but .gov and .mil are US-specific.

Hierarchical Administration - “Zones”

arpa com edu gov mil net org us

arpa

colordao

cs

foobar

Administration - Zones

A zone is a subtree of the DNS tree that is independently managed

Second-level domains (“colorado.edu”) are usually an independent zone

Most sub-domains (“cs.colorado.edu”) are independent.E.g., most universities (not ours!) have departmental domains that are then independently administered

A zone must provide multiple name servers. This server records the members in the domain.

You typically need a primary name server and one or more secondary name servers.

Secondary retrieves information from primary using a zone transfer.

Resolving an address

A.C.D wants to know about F.E.D

A

C

D

E

GB F

H

Resolving an address

Host “A.C.D” asks “B.C.D” (the local name server) to resolve “F.E.D”

B.C.D doesn’t know the answer. It wants to ask the primary domain server for the “E.D” domain, so it asks the parent of the “B.C” domain (hose “B.H” in this example) to resolve “E.D”.

B.H (the root server) doesn’t know the answer, but it’s the top-level domain and knows that “G.E.D” is the primary domain server for the “E.D” domain

B.C.D now knows the primary domain server for the E.D domain, and can now ask “G.E.D” about “F.E.D”

DNS Message Format

Number of additional RR’s

Question

Number of authority RR’s

Number of answer RR’sNumber of questions

FlagsIdentification

Answers

Authority

Additional Information

DNS Message Format

Identification - set by client, returned by server. Used to let clients match questions & answers

Questions - a hostname you want resolved - send by a query, returned by responses

Answers - answers to the questions, only in a response. You may get multiple answers per question.

Authority - what host is the authoritative name server for this query?

Additional information - cover later

DNS Message Flags

QR - 0 for query, 1 for response opcode - 0-query, 1-inverse query, 2-status AA - Response is “authoritative answer” TC - Response was truncated RD - Recursion desired -- keep asking if you don’t know RA - Recursion available for a response rcode - return code (0 - no error, 3 - name error)

QR rcodeMBZAA TC RD RAopcode

Recursion Desired & Available

If the name server doesn’t know the answer, it can contact other name servers to find the answer

You need to set the RD flag to ask for this

On a reply, a name server may set the RA flag - recursion is available if you want it

Some name servers don’t do this to avoid poor configurations In particular, the root servers don’t honor RD and don’t respond

with RA

Resource Records

A - IP address returned as 32-bit value (see example) PTR - “pointer queries”. IP address is represented as a

domain name (70.241.138.128.in-addr.arpa). CNAME - “canonical name” HINFO - host info MX - mail exchange NS - name server record

[grunwald@linux grunwald]$ nslookup foobar.cs.colorado.edu

Server: localhost

Address: 127.0.0.1

Non-authoritative answer:

Name: foobar.cs.colorado.edu

Address: 128.138.241.78

[grunwald@linux grunwald]$ nslookup

Default Server: localhost

Address: 127.0.0.1

> foobar

Server: localhost

Address: 127.0.0.1

Non-authoritative answer:

Name: foobar.cs.colorado.edu

Address: 128.138.241.78

>

Querying the Name Server Using nslookup

Address of name serverproviding the answer Query & Respomse

Interactive sessionalso possible

Mail Exchange Records

> set q=mx

> foobar.cs.colorado.edu

Server: localhost

Address: 127.0.0.1

Non-authoritative answer:

foobar.cs.colorado.edu preference = 10, mail exchanger = foobar.cs.colorado.edu

foobar.cs.colorado.edu preference = 99, mail exchanger = cs.colorado.edu

Authoritative answers can be found from:

cs.colorado.edu nameserver = cs.colorado.edu

cs.colorado.edu nameserver = moet.cs.colorado.edu

Mail Exchange Records

You can provide an MX record for a “virtual host” cs.colorado.edu

You can provide an MX record for a client that is off-line or isn’t directly connected to the net

Allows delayed delivery of email

You can direct the MX of many domains to a single host Mail servers for a number of domains

PTR (Reverse Query) lookups

> set q=ptr

> 78.241.138.128.in-addr.arpa

Server: localhost

Address: 127.0.0.1

Non-authoritative answer:

78.241.138.128.in-addr.arpa name = foobar.cs.Colorado.EDU

Authoritative answers can be found from:

241.138.128.in-addr.arpa nameserver = cs.Colorado.EDU

241.138.128.in-addr.arpa nameserver = anchor.cs.Colorado.EDU

Reverse Queries

Reverse queries are used as a (weak) mechanism to avoid spoofing

My home linux system is named “linux” and doesn’t appear in the DNS. When I connect via PPP, I’m given an IP address of e.g. dialup-85-185.colorado.edu

Sendmail uses an identity message (“HELO”) to identify sender and receiver. You can spoof this (send mail as if you are [email protected])

mail.cs.colorado.edu doesn’t forward mail if you’re not in cs.colorado.edu (anti-spam) & doesn’t accept mail if it can’t reverse-query your IP address (anti-user spoof)

Keeps the “script-kiddies” out, not totally secure Host on same physical network can spoof IP headers

Other things you can do with nslookup

“ls -d cs.colorado.edu” lists all records in the DNS server for the cs.colorado.edu domain

You can also list specific classes (“all MX”)

You can use named to distribute other kinds of information as well

TXT fields that describe machines location, etc Public keys for cryptographic systems, etc

Tricks with DNS - Round-Robin DNS

> www.yahoo.comNon-authoritative answer:Name: www.yahoo.comAddresses: 204.71.200.75, 204.71.200.74, 204.71.200.67,

204.71.200.68

> www.yahoo.comNon-authoritative answer:Name: www.yahoo.comAddresses: 204.71.200.68, 204.71.200.75, 204.71.200.74,

204.71.200.67

Possible DNS Mappings

128.138.202.71.

128.138.241.78foobar.cs.colorado.edu

128.138.241.72www.itsy.org

202.71.200.68www.yahoo.com

202.71.200.74www.yahoo.com

202.71.200.80ns.itsy.org

Nodes in a domaincan span multiple

IP networks!(hypothetical)

Multiple nodes canhave the same name

Dynamic DNS

DNS maps domain names to specific IP addresses This requires that each domain name is statically assigned,

since the zone table is typically stored on disk

This implies that using a host using a dynamically assigned IP address means you “connect” to that host

This is what Dynamic DNS is for [RFC 2136] Host gets an IP address Uses a secure connection [RFC 2137] to update the DNS

database

Importance of DNS

From http://www.keynote.com/measures/top10.html 3. Internet performance problems are generally not server problems.

For many web sites, Keynote's measurements demonstrate that most of their performance problems occur out in the Internet's infrastructure somewhere between the web site and its users: at the NAPs (Network Access Points) where backbone providers interconnect, in one or more routers along the communication path, or in a DNS (Domain Name Service) close to the user.

Determining Configuration Information

BOOTP was an early protocol to let systems boot over IP networks

Not routed, bridge support available Client would use a broadcast, server would look up MAC

address in table, provide both IP address and optionally information for downloading additional information using TFTP

DHCP is the big brother of BOOTP Main function is to serve IP addresses Lease / renewal model DHCP has a number of “OPTIONS”

• Clients can request specific options• Simplifies configuration

BOOTP

Ports 67 for server, 68 for client

Usually initiated by broadcast (Src IP == 0.0.0.0) Server doesn’t have client address at that point Server either does “arp stuffing” and sends unicast or issues

broadcast In either case, client than tries again with proper IP address to

confirm Usually does gratuitous ARP to insure the network isn’t

misconfigured.

/etc/dhcpd.conf

server-identifier linux;default-lease-time 7200;max-lease-time 7200;option broadcast-address 192.168.1.255;option domain-name "cs.colorado.edu";option domain-name-servers 192.168.1.1, 208.163.60.10, 205.216.172.10, 205.216.172.7;option routers 192.168.1.1;option subnet-mask 255.255.255.0;option time-servers 192.168.1.1;subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.2 192.168.1.254;}group { host grok { hardware ethernet 0:a0:cc:3b:95:4b; fixed-address 192.168.1.2; }}

/etc/dhcpd.leases

lease 192.168.1.2 {

starts 4 1970/01/01 00:00:00;

ends 5 1999/09/24 22:12:27;

}

lease 192.168.1.2 {

starts 4 1970/01/01 00:00:00;

ends 5 1999/09/24 23:12:27;

}

Pragmatics of DHCP

Currently, DHCP isn’t well integrated into UNIX-like operating systems

Dhclient implementation available from http://www.isc.org/

Current version is dhcp-3.0b1pl17 Uses a script to invoke OS-specific actions, such as interface

configuration That script may reconfigure various system files

(/etc/resolv.conf)

Projects

Our projects are to implement dynamic dns Or, multicast DNS

Zero Configuration Networking (ZEROCONF) Working Group

Enable networking in the absence of configuration and administration.

Zero configuration networking is required for environments where administration is impractical or impossible, such as in the home or small office, embedded systems 'plugged together' as in an automobile, or to allow impromptu networks as between the devices of strangers on a train.

In some cases other considerations may dominate ease of use. For example, network security requires some configuration which may not be as easy as the unacceptable alternative of 'no security.'

Networks where ZEROCONF protocols apply can include (but are not limited to) environments where no DHCP, MADCAP or DNS servers are present.

This working group will address both IPv4 and IPv6.

Management and Naming

Requirements Specification available http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-reqts-04.txt

AutoConfig

http://www.ietf.org/internet-drafts/draft-ietf-dhc-autoconfig-04.txt

Operating Systems are now attempting to support ad-hoc networks of two or more systems, while keeping user configuration at a minimum. To accommodate this, in the absence of a central configuration mechanism (DHCP), some OS's are automatically choosing a link-local IP address which will allow them to communicate only with other hosts on the same link. This address will not allow the OS to communicate with anything beyond a router.

However, some sites depend on the fact that a host with no DHCP response will have no IP address. This document describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not generate an IP address it's own.

AutoIP

http://www.ietf.org/internet-drafts/draft-ietf-dhc-ipv4-autoconfig-05.txt

With operating systems appearing in more and more devices, as well as computers appearing in more and more aspects of everyday life, communication between networked devices is increasingly important. The communication mechanism between these devices must be able to not only support the office LAN environment, but must also scale to larger WANS and the internet.

This draft describes a method by which a host may automatically give itself a link-local IPv4 address, so that it will be able to use IP applications in the absence of an IP address management mechanism, such as DHCP. This mechanism is in use today by a few operating systems, and additional information on those implementations is also provided.

Multicast DNS

See http://www.cs.colorado.edu/~grunwald/MobileComputing/RFCs


Recommended