[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-iab-dns-choices-02.txt comments
* Alex Bligh:
> IF one is the opinion TXT records should not be used for this
> AND one is of the opinion "fixing" (breaking? :-) ) wildcards to do this
> is not desirable
> THEN you are left with a new RR type as the only solution anyway.
Seems reasonable, but as I wrote, I don't think the new RR type route
is a real solution, unless assignment is handled more liberally (which
is difficult because there are just 2**16 types).
> So, if those assumptions hold true, why would you want to invent two-stage
> queries, when you can just do
>
> $ORIGIN example.com
> foo IN TXT2 "SPFv71" "Here's my SPF String"
> foo IN TXT2 "killspam3" "Here's my other string"
>
>
> IE encapsulate the type in the record itself, but not as part of
> the freeform text field.
>
> Sure you can't query by it (today) by type, but you can get all the
> information back anyway, and if we wanted at some stage to query
> by 4-tuple rather than 3-tuple, it would be obvious how to do it.
I'm not sure how such a transition would interact with DNSSEC.
Just for clarity, I would propose something like this:
foo IN RTYPE ("SPFv71", 1025) ("killspam3", 1026)
foo IN TYPE1025 "Here's my SPF String"
foo IN TYPE1026 "Here's my other string"
(Everything is crammed into one RTYPE to cut down the protocol
overhead. Another level of indirection (ahem) could be used to
increase caching.)
A client would request the RTYPE record, search for the corresponding
RR type, and request that RR type. As a result, it wouldn't be bogged
down by large RRsets of a kind it's not interested in. There's a
slight synchronization problem (you've to be careful when reusing
dynamic type numbers), but it doesn't look too bad.
IANA could liberally assign the indification strings because they
aren't a scarce resource.
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>