140 lines
4.1 KiB
Markdown
140 lines
4.1 KiB
Markdown
# Naming
|
||
|
||
IPs are not human-readable.
|
||
|
||
Not always the appropriate granularity
|
||
|
||
- The address names an interface
|
||
- This however does not give information about the kind of service / hardware
|
||
|
||
A file maps names to addresses
|
||
|
||
- Unix & Linux
|
||
- `/etc/hosts`
|
||
- Windows
|
||
- `C:\Windows\System32\drivers\etc\hosts`
|
||
|
||
These are simple but neither automatic nor scalable, which led to **DNS**.
|
||
|
||
- Was initially `RFC882`
|
||
- Now is `RFC1035, 1987`
|
||
|
||
DNS is a consistent namespace
|
||
|
||
- No reference to addresses, routes etc
|
||
- Is hierarchical, distributed and cached
|
||
- All of which help with scalability
|
||
- **Federated** - sources control trade-off
|
||
- This just means DNS is worldwide
|
||
- **Flexible** - many records
|
||
- Simple client-server name resolution protocol
|
||
|
||
#### Components
|
||
|
||
- *Domain name space* and *resource records*
|
||
- Tree-structured name space
|
||
- Data associated with names
|
||
- *Name server*
|
||
- Contains records for a subtree
|
||
- May cache information about any part of the tree
|
||
- Resolver
|
||
- Extracts information from the tree upon client requests
|
||
- `gethostbyname()`
|
||
|
||
|
||
|
||
###### Root
|
||
|
||
- Ultimate authority with the US Dept. of commerce (NITA)
|
||
- Managed by IANA, operated by ICANN, maintained by Verisign
|
||
- Started with only thirteen root server clusters
|
||
- Now many more
|
||
- Top-level domains, TLDs
|
||
- Operated by registrars, delegated by ICANN
|
||
- Delegate zones to other registrars
|
||
- and so on down the hierarchy
|
||
- Eventually, a customer rents a name - their **zone**
|
||
- Registrar installs appropriate *resource records*
|
||
- Associated with names within the zone
|
||
|
||
#### Query
|
||
|
||
- Query generated by resolver
|
||
- e.g. call to `gethostbyname()`, `gethostbyaddr()`
|
||
- Carried in single UDP/53 packet
|
||
- Or more rarely TCP/53 in case of truncation
|
||
- UDP is not smart and therefore does not follow traffic routing (it is selfish)
|
||
- It is beneficial for the internet as a whole to use UDP sometimes
|
||
- Header followed by question
|
||
- ID, Q/R, opcode, AA/TC/RD/RA, response code, counts
|
||
- Query type, query class, query name
|
||
|
||
Response consists of three RRsets following the header and question
|
||
|
||
- **Answers**: RRs that the server had for the QNAME
|
||
- **Authoritatives**: RRs pointing to an authority for the name
|
||
- **Additionals**: RRs related to the question but don’t answer it
|
||
|
||
###### Common Resource Records
|
||
|
||
- `A` / `CNAME` / `PTR`
|
||
|
||
```
|
||
www.cs.nott.ac.uk. 61272 IN CNAME pat.cs.nott.ac.uk.
|
||
|
||
pat.cs.nott.ac.uk. 68622 IN A 128.243.20.9
|
||
|
||
pat.cs.nott.ac.uk. 68622 IN A 128.243.21.19
|
||
|
||
9.20.243.128.in-addr.arpa. 39617 IN PTR pat.cs.nott.ac.uk.
|
||
```
|
||
|
||
`cname` refers to the mapping of the domain name to its IP (or another domain) & ports
|
||
|
||
Can have 2 authoritative records
|
||
|
||
- `NS`
|
||
|
||
```
|
||
cs.nott.ac.uk. 10585 IN NS ns1.nottingham.ac.uk.
|
||
cs.nott.ac.uk. 10585 IN NS ns2.nottingham.ac.uk.
|
||
cs.nott.ac.uk. 10585 IN NS marian.cs.nott.ac.uk.
|
||
cs.nott.ac.uk. 10585 IN NS extdns1.warwick.ac.uk.
|
||
cs.nott.ac.uk. 10585 IN NS extdns2.warwick.ac.uk.
|
||
```
|
||
|
||
It is good practice to have an external DNS, UoN uses Warwick as an external DNS.
|
||
|
||
- `MX`
|
||
|
||
```
|
||
nott.ac.uk. 3600 IN MX 1 mx191.emailfiltering.com.
|
||
nott.ac.uk. 3600 IN MX 2 mx192.emailfiltering.com.
|
||
nott.ac.uk 3600 IN MX 3 mx193.emailfiltering.com.
|
||
```
|
||
|
||
What happens when the resolver queries a server that doesn't know the answer? There are two solutions:
|
||
|
||
1. **Iterative** (required)
|
||
- Server responds indicating who to ask next
|
||
- This method is slower and more difficult to retrieve an answer
|
||
1. **Recursive** (optional)
|
||
- Server generates a new query to the next server
|
||
|
||
|
||
|
||
#### Load Balancing
|
||
|
||
DNS may have multiple servers. When a query arrives, various algorithms can be used to choose the best one, for example, based on geographical location.
|
||
|
||
#### Operational & Security Issues
|
||
|
||
- Usually need primary and secondary servers
|
||
- Separate IP netblocks, physical networks - more robust
|
||
- DNS is a *very* common single point of failure
|
||
- Cache poisoning
|
||
- Caching and soft-state means bad data propagates and can persist for some time
|
||
- Even if through simple mistakes (or of course malicious attacks)
|
||
- Man-in-the-middle attacks
|
||
- Can happen with both iterative & recursive queries
|