Fragmentation and DNS

The data link layer

• Ethernet II -> 1500 B

• IEEE 802.3 -> 1492 B

• 576 Bytes

• requires fragmentation

• of if DF flag set -> gets discarded

• IP payload gets split into multiple splits

• each payload of individual ip packet

• each satisfies the MTU limit

• IPv4 -> Sender or intermediate node

• IPv6 -> ONLY sender

yes

• reassembled directly at receiver (not inbetween)

• buffers fragments

• -> if no new fragments arrive (and not all fragments arrived yet) in a certain timeout period (usually 60-120s)

• -> discard all fragments of the original datagram received so far

• total length

• identification

• DF

• MF flags

• fragment offset

• when packet gets fragmented

• -> assign same ID to all fragments…

• when packets get fragmented

• -> are identified with identification

• -> and ordered with the offset (describes position of fragment in original packet)

• indicates wether more fragments for this identification will arive

• >-> if 0- -> knows this is the last fragment one needs before reassembly… (of coure if all previous packets already arrived…)

• must fit to the offset which is in multiple of 8B

• -> can only be split in multiples of 8B…

• try to avoid

• ->TCP: set max size to smallest MTU on path

• -> UDP: limit size to 512 bytes .> ensure that IP datagram smaller than minimum 576 byte…

• offers flexibility to deal with heterogeneity on data link layer

• involves significant processing overhead

• if single fragment is lost, entire IP datagram needs to be rentransmitted

  
  

• used to be exchanged during 3-way handshake and set in the header -> indicating buffer size of host

  • need generally not be smaller than MTU - 40, as it can be fragmented on IP layer

• in certain scenarios, computed comparing MTU of local ethernet interface - 40 bytes and the MSS from the 3-way handshake and use the min of the two values

• PMTUD (path mtu discovery) can be used and thus determine the MSS as the minimum of initial MSS and PMTUD - 40 bytes

• destination unreachable with code indicating fragmentation needed

• type 3 code 4

  
  

• drop packet and send ICMP packet beginning with 0x0304 (type3 code 4)

• domain name system

• decentralized naming scheme for resources connected to the inernet or a private network

• hierarchical tree-like structure called domain namespace

• domain

• domain name

• administrative entities

• -> within the internet:

  • set of network addresses and the corresponding hardware

  • administered by single authority (beside the rt domain)

  • can be identified by an identification string named domain name (e.g. “de”-domain)

• the further dividion of domains

• -> e.g. domain de

• sub-domains: tum.de; moodle.de;…

• => autonomous domains that may be administered by different authorities from the domain above

• root domain (level 0)

• top level domains (level 1; e.g. de, com, org, net,…)

• second level domains (subdomains of the top-level domains)

• -> everything below has no specific name…

• geographical

• organizational

• the individual parts of a fully qualified domain name

• e.g. www.tum.de. -> labels www, tum, de

• not a single authority controlling root servers

• 13 root serveres (with more physical instances…)

• name servers

• resolvers

• server programs which hold infrmatoinp about the domain tree’s structure and set information

• a particula nameserver has complete information about a subset of the domain space

• said to be the authority for these parts of the namespace

=> NS is authorative for zones

• has also domain name and IP address

• must be able to serve queries addressing the name space it is respobsible for

• => helos with address resolution process within the subtree it is authorative of

• complete database for a “pruned” and contiguous subtree of the domain space

• => partitioned at points where a particular organization wants to take over control of a subtree… (-> resulting in a zone…)

• change data in zone

• grow new tree sections connected to the zone

• delete existing nodes

• delegate new subszones under its zone

• zone file on the nameserver

• consists of set of resource records

• zero

• one

• multiple

• identifies specific resource (e.g. FQDN)

• holds different entries

  • resource record name (FQDN)

  • record TTL

  • resource record type

  • resource record class (for us, only internet IN is relevant…)

  • resource data

• SOA

• A

• NS

• MX

• CNAME

• must be SOA record

• -> start of authority

• contains global parameters for the zone

  • name of the zone

  • name server that holds the zonefile

  • several update timers

• no !

• -> must have exactly one…

• zone starts at certain domain and extends donward in the tree to the leaf nodes or TLD of sub domains where other tones start (-> thus may only contain pruned subtree of DNS name space)

• => each zone requires NS which responds authorative for queries addressed to domain names within zone

• => delegating the authority of sub-zones to other NS

• => this delegation has to be registered in the superior zone by adding RR of the type NS to the zone file of the superior zone

• -> containts fields for the domain name of the NS and the corresponding IP address

• -> e.g. zone tum.de

• sub-zone delegation (in zone file of tum.de)

  • ns.in.tum.de NS IP_of_ns_in_tum_de_nameserver

• yes

• no!!

• -> e.g. domain is tum

• and zone is e.g. in.tum; net.in.tum; …

• yes

• yes

• ilab.net.in.tum.de

• -> part of zone net; in; tum; de; root

• => one domain 5 zones…

• in the zone file of its authorative nameserver

• resolvers

• name servers

• domain name space

• yes, they can

• no -> each zone is assigned to at least one ANS

• for the zones defined in the zone files in the ANSs DNS database

• programs that interface users programs to domain name servers

• formulate a query which will answer the clients request

• and direct that query to name servers wichi can provide the information

• maximize probability that the request ins answered

• minimize the time that the request takes

• avoid excessive transmissions

1. examine its cache for relevant entry

   • first look for e.g. info.tum.de

   • then if no entry is there, look for tum.de

   • then .de

   • then .

2. if no cache entry matches, start with list of name servers to query

   • all NS RRs which correspond to the nearest ancestor zone that the resolver knows about i.e. .de if cached…)

3. to avoid startup problems -> resolver should have set of default servers which it will ask in case it has no current NS RRs which are appropriate…

4. Send out query to that NS

   
   

• recursive: between client and resolver

• iterative: between the reolver and the NSs

• if a A record is answered, reply it to client

• if delegated to other NS, cache the result and query next NS

• in iterative queries, the DNS client/resolver iteratively asks name servers

• in recursive queries, this is done by the name server

=> iterative: NS replies either with IP od IP of NS that might know the IP

=> Recursive: NS returns IP or an error if it does not know the IP it asks other NS that may know it

• load balancing

• -> e.g round robin resolve the FQDN to different IP addresses to servers that are copies of each other…

• hughe number of servers

• highly distributed

• organized in hierarchical topology

• e.g. 2.1.168.192.in-addr.arpa

• get the friendly name for the IP address 192.169.1.2

• web caches closer to client temporarily store data that was recently requested and many users are still requesting (e.g. static HTML pages and file transfer)

• -> these web caches than handle the requests for this frequently accessed data in a more time and resource efficient manner…

• reduced network load

• reduced server load

• reduced latency

• web cahces can be deployed anywhere, e.g. at the local ISP

• forward proxy

• reverse proxy

• proxy acts on behalf of the client

• -> helps the client to get the desired content (also called avatar or delegate)

• -> forward proxy should be close to the client

  
  

• proxy acts on behalf of server

• helps the server to deliver data (also called surrogate)

• -> can be deployed either in front of the server or at the network edge

• caching policy

• -> decides what documents to delete in case the cache is full and new data has to be stored

• last recently used (LRU)

• last frequently used (LFU)

• has to check if data stored is up to date

• -> can be done using HTML conditional GET request (standard get request with “if-modified-since:<date>”)

• -> sometimes web servers provide information when a document expires

• -> today this ifnromatino is usually only given when the document must not be cached and expires immediately…

• security issues (web caches that respond to DNS queries usually not authorative for requested domain; caches can be poisoned)

• web cache (may) provide outdated data (no cache consistency)

• NS have several entries for same domain

• -> e.g. resolve them round robin (first respond with IP 1, then IP2,…

  • -> requesting same domain results in different IP of NS that cache the same thing…

• or distribute content and servers locally globally

• -> NS in different countriese may answer with different IPs located closer to client resulting in more responsive replies

• => e.g. resolving netflix in asia results in IP to netflix server in asia and not in europe…

• IP addresses are hard to remember for humans

• -> map symbolic names to addresses

• /etc/hosts file

• label concatenation on path from a leaf to rood node

• resolver

• authorative name server

• usually primary and secondary NS

• -> syncronize with zone transfer (transfer zone file…)

  
  

• avoid disappearance of zone in case of outage

• load balancing

-> you e.g. have a NS entry (RDATA is FQDN of NS)

-> to resolve it, you need glue record that provides the IP address of this nameserver (A or AAAA entry…)

• start to resolve the ns -> resolve loop…

• IP

• UDP

• DNS Header (ID, flags, number of RRs)

== records ==

• query

• answer

• authorative

• additional

• OR (query or response)

• authorative answer?

• truncation

• Recursion desired

• Recursion available

• 4 bit response code -> no error, name error, sever failure, refused

• query: only one record with owner, type, class

• answer: answers RR

• authorative section: name server delegation

• additional section: glue refcords…

packet size limited to 512 octets

Client -> NS1

NS1 -> NS2

NS2 -> NS3

NS3 -> NS4

NS4 finds A record

NS4 -> NS3

NS3 -> NS2

NS2 -> NS1

NS1 -> Client

Client -> NS1

NS1 -> Client go to NS2

Cient -> NS2

NS2 -> Client go to NS3

Client -> NS3

NS3 -> Client go to NS4

Client -> NS4

NS4 -> Client, A record to query is…

• send many packets with fake responses to resolver

• spoofed source iP -> address of an authorative nameserver

• try to answer query before the legitimate server does

• => Counter: randomize as much as possible (source port, query id,…)

• send queries with spoofed source addres to open resolvers

• spoofed source address is attack target

• queries with high amplification factor

• => counter: no open resolvers, ingress filtering

• security extension to DNS

• data origin authentication

• data integrity

• no confidentiality

• inside the protocol, no additional layer…

• no flag day

• signatures with pub key crypto

• zone owners sings RRsets offline using private key

• fulll resolvers verify signatures using pub key

• => how do we know that signing key really belongs to zone owner?

• RRSIG -> signature over RRset

• DS (delegation signer) : hash of pub key

• DNSKEY: pub key

• NSEC, NSEC3: for nonexisting domains

• CD checking disabled -> request delivery of DNSSEC records

• AD andwer authenticated: DNSSEC succesfully verified

Vorlesung anschauen!!!

• option -M want in ping

• begin by sending packet with DF bit

• -> get answer with fragmentation needed and max MTU size of that node

• -> send packet with that size and DF bit

• -> and so on until again MTU has to be adjusted or echo reply…

• => used MTU size stored in PLPTMU (packetization layer path mtu) value

• same as IPv4 plus next header

• -> id, offset, M flag(last fragment = 1; more follow = 0)

• none!!!

• => fragmentaiton happens at layer 3 thus invisible for TCP / UDP

• yes, if it acts as resolver… (else can ask resoler specified in resolv.conf)

• -> in roots.hints file…

• TTL: time in seconds a client/resolver/NS may hold SOA file in cache after querying it; when hits 0, should be queried again

• . -> what zone is the SOA file associated with?

• IN -> class internet

• Type: SOA

• MNAME: domain name of authorative name server

• RNAME: mail of administrator responsible for the zone

• serial number -> in case slave is used -> if file is updated, serial number increases allows to see wether cached is up to date or wether to intialize zone transfer

• refresh timer -> for slave, when hits 0 should be queried again

• retry timer -> how much time should pass before try to query master after previously failed query where master did not respond

• expire timer: after when SOA is invalid/expired in case refresh not possible (master does not respond) -> should not answer queries anymore when hits 0

• negative caching -> allowed time for caching negative entries (meaning query failed -> cache that it failed -> only assum the failed response until timer hits 0) e.g. nodata

• can get quite large

• -> e.g. not every domain level requires own authorative name server to solve this… -> decreases number of requiured iterative resolves

• prefer IPv6

• type 11 code 0 -> fragmentation assembly time exceed

• slaac configure itself based on prefix from router

• DHCPv6 get dns information and full global unique adress…