Skip to content

F
Fenrir_Project

DNSSEC_Details

Last edited by Luker
Page history

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 Z85(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
  • **Y * 2 ** bytes: uint16_t list of supported authentication algorithms.
  • one byte: number of public keys
    • two bytes: public key type (rsa-1024,rsa-2048 etc..) the complete list is to be defined.
    • two bytes: public key id
    • Z bytes the public key (size dependent on key type)

Now in a single TXT record we have the ip addresses, with redundancy support, and the public keys.

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.

  • 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.