Add acn
This commit is contained in:
John Gatward
139
docs/lectures/acn/12_naming.md
Normal file
139
docs/lectures/acn/12_naming.md
Normal file
@@ -0,0 +1,139 @@
|
||||
# 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 or 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 & cache
|
||||
- All of which to help with scalability
|
||||
- **Federated** - sources control trade-off
|
||||
- This just means DNS are worldwide
|
||||
- **Flexible** - many record
|
||||
- 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 sub tree
|
||||
- May cache information about any part of the tree
|
||||
- Resolver
|
||||
- Extract information from 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 much more
|
||||
- Top level Domains, TLDs
|
||||
- Operated by registrars, delegated by ICANN
|
||||
- Delegate zones to other registrars
|
||||
- and so on down the hierarchy
|
||||
- Eventually 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? 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 comes various algorithms can be used to choose the best one, this can be 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
|
||||
Reference in New Issue
Block a user