Re: [dnsext] loads of TXT records for fun and profit

[Joe Abley <[e-mail]>]

On 2013-05-03, at 09:57, Phillip Hallam-Baker <[e-mail]> wrote:

> DNS has an effective hard limit on the total size of all the records in a RR set of 500 bytes.
> 
> It is theoretically possible to go over that limit but bad things start to happen and TCP fallback does not work any more reliably than new RR types do.

I don't think we necessarily see widespread problems with large responses.

I realise that large responses are a reasonable concern, and there is much scope for actual measurement to better characterise the landscape with facts and science, but I don't think it's sensible to work from the basis that the non-EDNS0-capable UDP-only DNS client sets an effective hard limit.

This is a very general comment with no science behind it, of course, so it doesn't really say anything beyond "here be dragons, or maybe not, who knows".

> Now what could make the whole process a lot easier would be to allocate a band of DNS RR codes for records that would all have TXT syntax. That would allow BIND etc. to make one change to support the new syntax. Alternatively we could extend the handling of unknown RR syntax so that there was a string presentation option.

Recent experience suggests it's possible to apply for a new RRType and have code-points assigned in less than a week.

It also seems possible (with only the effort involved in opening a couple of trouble tickets to make the feature request) to get the code-points implemented in multiple major authoritative servers in less than three weeks.

Most deployed DNS authority servers (I have no numbers, but given the purported market share of BIND9 I'll say "most") follow RFC3597 and hence are able to understand (for example)

  krill.hopcount.ca. 86400 IN TYPE108 \# 6 7c d1 c3 e8 10 2f

even if they can't understand

  krill.hopcount.ca. 86400 IN EUI48 7c-d1-c3-e8-10-2f

The fact that EUI48 has a conveniently-hexadecimal RDATA payload makes this an over-simple example, but it's not that hard to convert RRs with textual data into the same format for provisioning purposes if your nameserver doesn't understand the new RRType's presentation format ("not hard" used here to mean "possible in less than 20 lines of awk").

Given all of this, I don't really understand the benefits of pre-assigning TXT-like RRTypes for future use. The barrier to entry (today!) does not seem high, and having RRTypes defined with meaningful canonical representations and stable references for use seems beneficial.


Joe