Information Sources: - Baylor University



DNS – Domain Name System

• Designed to look up information (e.g., IP address) by name

• Originally host name to address mappings maintained in a single file (host.txt) by the Network Information Center (NIC). This files was periodically transferred to all hosts. The bandwidth complexity of this approach is N2 (where N is the number of hosts) because the host file contains N records and each of those records must be sent to N hosts.

• DNS proposes a distributed name service organized as a hierarchy.

• Fig. 7-25.

• Root is ‘.’

• The root is subdivided into subdomains (e.g., edu, com, and etc.). These subdomains can be further subdivided.

• Names are read from leaf to root.

• Names can be relative or absolute (absolute always includes root ‘.’)

• Labels (e.g., Baylor) can be up to 63 characters long and the full path may not exceed 255 characters

• Names are not case sensitive

• Each domain controls how it allocates the domains under it (e.g., baylor.edu gives out ecs.baylor.edu)

• DNS Components

1. Resource Records: Every domain (single host or top-level) has a set of resource records associated with names in its domain space.

2. Name Servers: Program that holds information about the domain tree structure and resource records

3. Resolvers: Program that retrieves information from name servers. Web browsers use a resolver to convert names to IP addresses.

• Resource Records (Records in Database)

• Five tuple: Domain_Name Time_to_Live Class Type Value

• Domain_Name – Domain record applies to

• Time_to_Live – How long (secs) is record valid

• Class – Type of network this refers to (IN for internet)

• Type – Fig. 7-26

• SOA – Name of primary information source about name server’s zone (admin. email address, timeouts, etc.)

• A – Hold the address (32-bit IP address for internet) for the domain name

• MX – Domain willing to accept email for given domain (e.g., You may have domain name ; however, since you are not always connected to the Internet you need another server to accept your email. You might get to accept it. This type of RR would redirect bob@ to bob@.

• NS – Name server for specified domain

• CName – Canonical name (alias creation, e.g., could alias cs.baylor.edu to ecs.baylor.edu)

• Ptr – Maps IP addresses to name for reverse lookups

• Hinfo – Host info (e.g., CPU, OS, etc.)

• Txt – General text

• Value – Depends on type

• Search: Single name server with RR for everything.

• Problem: Single point of failure and network bottleneck

• Optimization 1: Distributed resource records

• Every domain and subdomain maintains its own name server with resource records

• Each domain either has resource record or can send you to next closest domain. All domains must know root name servers. All domains must also know children.

• Search: Ex: From eng.. I want to know address of flits.cs.vu.nl (Fig. 7-25).

• Machine eng. server does not know address so it returns the edu root server

• eng. asks the edu root server which also does not know the address; however, it knows all of its children so it returns the nl (Netherlands) server.

• eng. asks the nl server which does not know the address; however, it knows all of its children so it returns the vu server (Vrije Universiteit in Amsterdam)

• eng. asks the vu server which does not know the address; however, it knows all of its children so it returns the cs server

• eng. asks the cs server which does not know the address; however, it knows all of its children so it returns the fluit server which contains the RRs about itself.

• See stanford.edu and colorado.edu examples.

• Problem: Querying machine must submit several queries to derive answer.

• Optimization 2: Recursion

• When a name server doesn’t know the answer, it asks the next name server instead of returning the next name server. This way a single query gets the answer.

• eng. > edu > nl > vu > cs >flit

• Problem: Each machine maintains a name server = maintenance nightmare!

• Optimization 3: Zones

• Group domains in tree together into zones (see Fig. 7-28). Each zone has a primary name server

• Problem: Every query for bugs com root server and cnn root server.

• Optimization 4: Caching (See neptune example)

• After a query is answered, the response is cached for future use. The cache entry expires after TTL.

• The answer from the primary server of the target domain is an authoritative record

• Cached entries are non-authoritative records

•

> set type=ANY

> set norecurse

> stanford.edu

Server: ada.ecs.baylor.edu

Address: 129.62.149.97

Authoritative answers can be found from:

edu nameserver = a.root-

edu nameserver = h.root-

edu nameserver = c.root-

edu nameserver = g.root-

edu nameserver = f.root-

edu nameserver = b.root-

edu nameserver = i.root-

edu nameserver = e.root-

edu nameserver = d.root-

a.root- internet address = 198.41.0.4

h.root- internet address = 128.63.2.53

c.root- internet address = 192.33.4.12

g.root- internet address = 192.112.36.4

f.root- internet address = 192.5.5.241

b.root- internet address = 128.9.0.107

i.root- internet address = 192.36.148.17

e.root- internet address = 192.203.230.10

d.root- internet address = 128.8.10.90

> stanford.edu 198.41.0.4

Server: [198.41.0.4]

Address: 198.41.0.4

Authoritative answers can be found from:

STANFORD.EDU nameserver = AVALLONE.STANFORD.EDU

STANFORD.EDU nameserver = ATALANTE.STANFORD.EDU

STANFORD.EDU nameserver = ARGUS.STANFORD.EDU

AVALLONE.STANFORD.EDU internet address = 171.64.2.210

ATALANTE.STANFORD.EDU internet address = 171.64.2.220

ARGUS.STANFORD.EDU internet address = 171.64.2.230

> stanford.edu 171.64.2.210

Server: [171.64.2.210]

Address: 171.64.2.210

stanford.edu canonical name = LB-A.Stanford.EDU

Stanford.EDU nameserver = Argus.Stanford.EDU

Stanford.EDU nameserver = Avallone.Stanford.EDU

Stanford.EDU nameserver = Atalante.Stanford.EDU

Argus.Stanford.EDU internet address = 171.64.2.230

Avallone.Stanford.EDU internet address = 171.64.2.210

Atalante.Stanford.EDU internet address = 171.64.2.220

> lb-a.stanford.edu 171.64.2.230

Server: [171.64.2.230]

Address: 171.64.2.230

Authoritative answers can be found from:

lb-a.Stanford.EDU nameserver = quack.Stanford.EDU

lb-a.Stanford.EDU nameserver = quark.Stanford.EDU

quack.Stanford.EDU internet address = 171.64.7.75

quark.Stanford.EDU internet address = 171.64.7.120

> lb-a.stanford.edu 171.64.7.75

Server: [171.64.7.75]

Address: 171.64.7.75

lb-a.stanford.edu internet address = 171.64.14.238

> colorado.edu

Server: ada.ecs.baylor.edu

Address: 129.62.149.97

Authoritative answers can be found from:

edu nameserver = a.root-

edu nameserver = h.root-

edu nameserver = c.root-

edu nameserver = g.root-

edu nameserver = f.root-

edu nameserver = b.root-

edu nameserver = i.root-

edu nameserver = e.root-

edu nameserver = d.root-

a.root- internet address = 198.41.0.4

h.root- internet address = 128.63.2.53

c.root- internet address = 192.33.4.12

g.root- internet address = 192.112.36.4

f.root- internet address = 192.5.5.241

b.root- internet address = 128.9.0.107

i.root- internet address = 192.36.148.17

e.root- internet address = 192.203.230.10

d.root- internet address = 128.8.10.90

> colorado.edu 198.41.0.4

Server: [198.41.0.4]

Address: 198.41.0.4

Authoritative answers can be found from:

COLORADO.EDU nameserver = BOULDER.COLORADO.EDU

COLORADO.EDU nameserver = NS1.

COLORADO.EDU nameserver = CUJO.COLORADO.EDU

COLORADO.EDU nameserver = RS0.

BOULDER.COLORADO.EDU internet address = 128.138.238.18

BOULDER.COLORADO.EDU internet address = 128.138.240.1

NS1. internet address = 128.138.213.13

CUJO.COLORADO.EDU internet address = 128.138.238.154

RS0. internet address = 198.41.0.5

> colorado.edu 128.138.238.18

Server: [128.138.238.18]

Address: 128.138.238.18

colorado.edu canonical name = patch.Colorado.EDU

Colorado.EDU nameserver = boulder.Colorado.EDU

Colorado.EDU nameserver = cujo.Colorado.EDU

Colorado.EDU nameserver = ns1.

Colorado.EDU nameserver =

boulder.Colorado.EDU internet address = 128.138.240.1

boulder.Colorado.EDU internet address = 128.138.238.18

cujo.Colorado.EDU internet address = 128.138.238.154

ns1. internet address = 128.138.213.13

internet address = 216.168.224.206

> patch.colorado.edu 128.138.240.1

Server: [128.138.240.1]

Address: 128.138.240.1

patch.colorado.edu CPU = Sun UE 450 OS = Solaris 2.6

patch.colorado.edu preference = 10, mail exchanger = patch.colorado.edu

patch.colorado.edu internet address = 128.138.129.25

colorado.edu nameserver = boulder.colorado.edu

colorado.edu nameserver = cujo.colorado.edu

colorado.edu nameserver = ns1.

colorado.edu nameserver =

patch.colorado.edu internet address = 128.138.129.25

boulder.colorado.edu internet address = 128.138.240.1

boulder.colorado.edu internet address = 128.138.238.18

> neptune.baylor.edu

Server: ada.ecs.baylor.edu

Address: 129.62.149.97

HEADER:

opcode = QUERY, id = 34954, rcode = NOERROR

header flags: response, auth. answer, want recursion, recursion avail.

questions = 1, answers = 1, authority records = 4, additional = 4

QUESTIONS:

neptune.baylor.edu, type = A, class = IN

ANSWERS:

-> neptune.baylor.edu

internet address = 129.62.162.65

ttl = 86400 (1D)

AUTHORITY RECORDS:

-> baylor.edu

nameserver = is.baylor.edu

ttl = 86400 (1D)

-> baylor.edu

nameserver = buvax2.baylor.edu

ttl = 86400 (1D)

-> baylor.edu

nameserver = ccis03.baylor.edu

ttl = 86400 (1D)

-> baylor.edu

nameserver = jerry.baylor.edu

ttl = 86400 (1D)

ADDITIONAL RECORDS:

-> is.baylor.edu

internet address = 129.62.1.2

ttl = 86400 (1D)

-> buvax2.baylor.edu

internet address = 129.62.1.1

ttl = 86400 (1D)

-> ccis03.baylor.edu

internet address = 129.62.16.4

ttl = 86400 (1D)

-> jerry.baylor.edu

internet address = 129.62.1.14

ttl = 86400 (1D)

------------

Name: neptune.baylor.edu

Address: 129.62.162.65

> neptune.baylor.edu

Server: ada.ecs.baylor.edu

Address: 129.62.149.97

HEADER:

opcode = QUERY, id = 34955, rcode = NOERROR

header flags: response, want recursion, recursion avail.

questions = 1, answers = 1, authority records = 0, additional = 0

QUESTIONS:

neptune.baylor.edu, type = A, class = IN

ANSWERS:

-> neptune.baylor.edu

internet address = 129.62.162.65

ttl = 86384 (23h59m44s)

------------

Non-authoritative answer:

Name: neptune.baylor.edu

Address: 129.62.162.65

+---------------------+

| Header |

+---------------------+

| Question |

+---------------------+

| Answer |

+---------------------+

| Authority |

+---------------------+

| Additional |

+---------------------+

Header: Always present

Question: Query to name server

Answer: Answer to name server query

Authority: Name of authoritative servers closer to answering question

Additional: Potentially helpful information (e.g., IP address of name servers in authority section)

1 1 1 1 1 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| ID |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

|QR| Opcode |AA|TC|RD|RA| Z | RCODE |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| QDCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| ANCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| NSCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| ARCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

ID A 16 bit identifier assigned by the program that

generates any kind of query. This identifier is copied

the corresponding reply and can be used by the requester

to match up replies to outstanding queries.

QR A one bit field that specifies whether this message is a

query (0), or a response (1).

OPCODE A four bit field that specifies kind of query in this

message. This value is set by the originator of a query

and copied into the response. The values are:

0 a standard query (QUERY)

1 an inverse query (IQUERY)

2 a server status request (STATUS)

3-15 reserved for future use

AA Authoritative Answer - this bit is valid in responses,

and specifies that the responding name server is an

authority for the domain name in question section.

Note that the contents of the answer section may have

multiple owner names because of aliases. The AA bit

corresponds to the name which matches the query name, or

the first owner name in the answer section.

TC TrunCation - specifies that this message was truncated

due to length greater than that permitted on the

transmission channel.

RD Recursion Desired - this bit may be set in a query and

is copied into the response. If RD is set, it directs

the name server to pursue the query recursively.

Recursive query support is optional.

RA Recursion Available - this be is set or cleared in a

response, and denotes whether recursive query support is

available in the name server.

Z Reserved for future use. Must be zero in all queries

and responses.

RCODE Response code - this 4 bit field is set as part of

responses. The values have the following

interpretation:

0 No error condition

1 Format error - The name server was

unable to interpret the query.

2 Server failure - The name server was

unable to process this query due to a

problem with the name server.

3 Name Error - Meaningful only for

responses from an authoritative name

server, this code signifies that the

domain name referenced in the query does

not exist.

4 Not Implemented - The name server does

not support the requested kind of query.

5 Refused - The name server refuses to

perform the specified operation for

policy reasons. For example, a name

server may not wish to provide the

information to the particular requester,

or a name server may not wish to perform

a particular operation (e.g., zone

6-15 Reserved for future use.

QDCOUNT an unsigned 16 bit integer specifying the number of

entries in the question section.

ANCOUNT an unsigned 16 bit integer specifying the number of

resource records in the answer section.

NSCOUNT an unsigned 16 bit integer specifying the number of name

server resource records in the authority records

section.

ARCOUNT an unsigned 16 bit integer specifying the number of

resource records in the additional records section.

Question Section

1 1 1 1 1 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| |

/ QNAME /

/ /

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| QTYPE |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| QCLASS |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

QNAME a domain name represented as a sequence of labels, where

each label consists of a length octet followed by that

number of octets. The domain name terminates with the

zero length octet for the null label of the root. Note

that this field may be an odd number of octets; no

padding is used.

EX: F.ISI.ARPA

1 1 1 1 1 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

20 | 1 | F |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

22 | 3 | I |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

24 | S | I |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

26 | 4 | A |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

28 | R | P |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

30 | A | 0 |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

QTYPE a two octet code which specifies the type of the query.

TYPE value and meaning

A 1 a host address

NS 2 an authoritative name server

MD 3 a mail destination (Obsolete - use MX)

MF 4 a mail forwarder (Obsolete - use MX)

CNAME 5 the canonical name for an alias

SOA 6 marks the start of a zone of authority

MB 7 a mailbox domain name (EXPERIMENTAL)

MG 8 a mail group member (EXPERIMENTAL)

MR 9 a mail rename domain name (EXPERIMENTAL)

NULL 10 a null RR (EXPERIMENTAL)

WKS 11 a well known service description

PTR 12 a domain name pointer

HINFO 13 host information

MINFO 14 mailbox or mail list information

MX 15 mail exchange

TXT 16 text strings

QCLASS a two octet code that specifies the class of the query.

For example, the QCLASS field is IN for the Internet.

IN 1 the Internet

CS 2 the CSNET class (Obsolete)

Answer, Authority, and Additional Resource Record

1 1 1 1 1 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| |

/ /

/ NAME /

| |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| TYPE |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| CLASS |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| TTL |

| |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| RDLENGTH |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|

/ RDATA /

/ /

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

NAME a domain name to which this resource record pertains.

TYPE two octets containing one of the RR type codes. This

field specifies the meaning of the data in the RDATA

field.

CLASS two octets which specify the class of the data in the

RDATA field.

TTL a 32 bit unsigned integer that specifies the time

interval (in seconds) that the resource record may be

cached before it should be discarded. Zero values are

interpreted to mean that the RR can only be used for the

transaction in progress, and should not be cached.

RDLENGTH an unsigned 16 bit integer that specifies the length in

octets of the RDATA field.

RDATA a variable length string of octets that describes the

resource. The format of this information varies

according to the TYPE and CLASS of the resource record.

For example, the if the TYPE is A and the CLASS is IN,

the RDATA field is a 4 octet ARPA Internet address.

Message compression

In order to reduce the size of messages, the domain system utilizes a

compression scheme which eliminates the repetition of domain names in a

message. In this scheme, an entire domain name or a list of labels at

the end of a domain name is replaced with a pointer to a prior occurrence

of the same name.

The pointer takes the form of a two octet sequence:

1 1 1 1 1 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| 1 1| OFFSET |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The first two bits are ones, allowing a pointer to be distinguished

from a label, since the label must begin with two zero bits because

labels are restricted to 63 octets or less. The OFFSET field specifies

an offset from the start of the message (i.e., the first octet of the ID

field in the domain header). A zero offset specifies the first byte of

the ID field, etc.

The compression scheme allows a domain name in a message to be

represented as either:

- a sequence of labels ending in a zero octet

- a pointer

- a sequence of labels ending with a pointer

For example, a datagram might need to use the domain names F.ISI.ARPA,

FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the

message, these domain names might be represented as:

1 1 1 1 1 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

20 | 1 | F |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

22 | 3 | I |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

24 | S | I |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

26 | 4 | A |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

28 | R | P |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

30 | A | 0 |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

40 | 3 | F |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

42 | O | O |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

44 | 1 1| 20 |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

64 | 1 1| 26 |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

92 | 0 | |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Query: MOLAR.ECS.BAYLOR.EDU

1 1 1 1 1 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

0 | ID |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

2 |QR| Opcode |AA|TC|RD|RA| Z | RCODE |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

4 | QDCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

6 | ANCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

8 | NSCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

10 | ARCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

12 | 5 | M |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

14 | O | L |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

16 | A | R |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

18 | 3 | E |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

20 | C | S |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

22 | 6 | B |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

24 | A | Y |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

26 | L | O |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

28 | R | 3 |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

30 | E | D |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

33 | U | 0 |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

34 | QTYPE |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

36 | QCLASS |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Response: MOLAR.ECS.BAYLOR.EDU

1 1 1 1 1 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

0 | ID |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

2 |QR| Opcode |AA|TC|RD|RA| Z | RCODE |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

4 | QDCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

6 | ANCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

8 | NSCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

10 | ARCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

12 | 5 | M |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

14 | O | L |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

16 | A | R |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

18 | 3 | E |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

20 | C | S |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

22 | 6 | B |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

24 | A | Y |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

26 | L | O |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

28 | R | 3 |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

30 | E | D |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

32 | U | 0 |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

34 | QTYPE |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

36 | QCLASS |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

38 | 1 1 12 |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

40 | TYPE |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

42 | CLASS |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

44 | |

+ TTL +

46 | |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

48 | RDLENGTH |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

50 | 129 | 62 |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

52 | 148 | 18 |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

DNS Factoids:

- Originally, the authority for IP numbers and DNS names fell to IANA. In 1992, NSF (the agency in charge of the non-military part of the Internet) gave NSI sole control over the "generic" (.com, .org, .net) domain names. Individual countries can manage their own top-level DB. Of course, the military runs .mil.

- A set of thirteen root servers is responsible for forwarding requests for the top-level domains. Official top-level domains currently include com, edu, gov, mil, net, org, arpa (obsolete), int (international organizations), (e.g. ca for Canada) [1]. Clearly, an IP address can exist in multiple top-level domains.

- Commercial attempts at forcing competition and the ability to add new top-level domains began in 1996. Companies include Enhanced DNS - eDNS - () and Name.space (). You can establish these companies as your domain name server. They resolve all "standard" DNS names in addition to a large collection of additional names. This extended collection of names includes many new top-level domains such as ".mars."

- The privatization of DNS began with the Clinton Administration's Framework for Global Electronic Commerce (1997) when the President directed the Secretary of Commerce to privatize the domain name system (DNS) in a manner that increases competition and facilitates. A proposal, called the "Green Paper," was created for privatizing DNS which included provisions for adding additional top-level domains[4]. A follow-up document was created by the NTIA describing the comments made by various communities about the Green Paper. I was unable to find anything that indicates a consensus on how this will happen.

- NSI, ICANN, and DoC reached an agreement on domain name registration on Sept 28, 1999 [2] allowing Network Solutions to continue to be a domain name registrar for indefinitely. A Shared Registry System is currently being tested to allow competition for domain names with the gTLDs. My guess is that alternate (to NSI) gTLD name registration will be available soon.

Sources:

[1] Douglas E. Comer, Internetworking with TCP/IP Volume I: Principles, Protocols, and Architecture. Third Edition, Prentice Hall, 1995

[2] Network Solutions. "Network Solutions, Department of Commerce and ICANN Reach Long-Term Agreements for Internet's Domain Name System," , Sept 28,.1999

[3] United States Department of Commerce, "Management of Internet Names and Addresses", 6/5/98.

[4] National Telecommunications and Information Administration. " A Proposal to Improve the Technical Management of Internet Names and Addresses", January 30, 1998.

Terminology:

DoC - Department of Commerce. Seems to be the federal organization charged with domain name assignment issues.

gTLDs - generic top level domains (.com, .org, .net)

IANA Internet Assigned Numbers Authority. Assigns IP (numeric) addresses (still).

ICANN - Internet Corporation for Assigned Names and Numbers ()

Information Sources:

INTERNIC - INTERnet Network Center. Replaced NIC [1] (). Operated by NSI for now.

ISOC - Internet Society

ITU - International Telecommunications Union

NIC - Network Information Center. Original name assigner. [1]

NSF - National Science Foundation

NSI - Network Solutions Incorporated. ()

NTIA - National Telecommunications and Information Administration, a agency of the Department of Commerce. ( )

WIPO - World Intellectual Property Organization

Questions:

Q: What is the Shared Registry System? ()

A: As defined in Amendment 11 to the Cooperative Agreement between NSI and the U.S. Government, the Shared Registry System is "a protocol and associated software supporting a system that permits multiple registrars to provide registration services within the gTLDs for which NSI now acts as a registry."Under Amendment 11, the purpose of the Shared Registry System is "to create an environment conducive to the development of robust competition among domain name registrars." Other top-level domains (notably .uk – serving the United Kingdom) have successfully implemented shared registration systems. (Source: )

Q: What are the "root" servers?

A: 3) The root server system is a set of thirteen file servers, which together contain authoritative databases listing all TLDs. Currently, NSI operates the "A" root server, which maintains the authoritative root database and replicates changes to the other root servers on a daily basis. Different organizations, including NSI, operate the other 12 root servers. The U.S. Government plays a role in the operation of about half of the Internet's root servers. Universal name consistency on the Internet cannot be guaranteed without a set of authoritative and consistent roots. Without such consistency, messages could not be routed with any certainty to the intended addresses.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download