|
|
# DNSSEC Details
|
|
|
|
|
|
Suppose the client wants to connect to example.com:
|
|
|
|
|
|
The client must make a **DNSSEC** query for a **TXT** record for **fenrir.example.com**.
|
|
|
|
|
|
If there is no such txt record or domain, it means that example.com does not support Fenrir, so other methods can be tried immediately, without having to wait any timeout.
|
|
|
|
|
|
----
|
|
|
|
|
|
If present, the TXT record will be in the form: **"fenrir=[...]"**, where the content is **base85** encoded binary data.
|
|
|
|
|
|
The data format **may change**, but for now we have:
|
|
|
|
|
|
* **first 2 bytes**: udp port to connect to
|
|
|
* **one byte**: number of ip addresses specified. format of ip addresses follows:
|
|
|
** **first byte**:
|
|
|
*** bit 0-1: ip type (00 = ipv4, 01 = ipv6, other are reserved)
|
|
|
*** bit 2-4: priority of the server (for server fallback).
|
|
|
*** bit 5-7: preference of address (for servsers with same priority).
|
|
|
** **X bytes**: ip address, length depends on ipv4 or ipv6
|
|
|
* **one byte**: public key type (rsa-1024,rsa-2048 etc..) the complete list is to be defined.
|
|
|
* **Y bytes** the public key
|
|
|
|
|
|
Now in a single TXT record we have the ip addresses, with redundancy support, and the public key.
|
|
|
|
|
|
## Why don't you use the A and AAAA records for ips?
|
|
|
|
|
|
For 2 reasons:
|
|
|
|
|
|
* **efficiency**: each server, ip with priority and preference would have its own record, meaning that it also needs to be signed. so you get a signature of overhead per each record. way too much.
|
|
|
* **less delay**: if we use A or AAAA records then all the servers must support Fenrir and other protocols, too (think HTTP). which means that you have to try to connect to the server before you know if it supports Fenrir or not. which means more delay
|
|
|
|
|
|
## Priority? Preference? Aren't those the same?
|
|
|
|
|
|
While you can have servers with the same priority and/or preference, they are not the same.
|
|
|
|
|
|
In general, the higher the number, the more probability the ip address has of being chosen:
|
|
|
|
|
|
* **Priority**: This is used when you want a fallback server. clients will chose an ip from the highest priority, and try one with lower priority only if it doesn't work.
|
|
|
* **Preference**: This is used to randomize connections between servers with the same priority. Clients will generate a random number and chose the preference closer to that number.
|
|
|
|
|
|
Since we only have 3 bits for the preference, the only preference probabilities are 12.5, 25, 37.5, 50, 62.5, 75, 87.5, 100.
|
|
|
|
|
|
----
|
|
|
|
|
|
All this information is now in a single packet, efficient and fairly easy to parse. |