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

[Phillip Hallam-Baker <[e-mail]>]

My point on TXT records and the 500 byte limit is that when you make a
query for an unprefixed TXT record you are going to get ALL the records for
all hacks that are overloading TXT with additional semantics. So the
approach is not scalable which I think you agree with.


Getting a RR assignment isn't the pain point. The only reason for getting
an assignment is to make it more likely we will get decent support in BIND
etc.

I know all about the unknown RR coding. But that is second best support.
What I am proposing is that we cut off a chunk of RR space that allows it
to be used in a useful fashion without waiting for new deployments of BIND
etc.

Having to update BIND is second best in any case. The fewer updates and the
fewer code paths to be verified, the better. Adding a new RR type to BIND
only takes me a few hours. But writing the regression tests and the support
infrastructure would be a lot more work and that is what it would be
necessary to consider the code to be 'production'.





On Fri, May 3, 2013 at 11:46 AM, Joe Abley <[e-mail]> wrote:

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




-- 
Website: http://hallambaker.com/