[dns-operations] extra records in resolver answer, any benefit?
marek.vavrusa at nic.cz
Tue Jan 27 16:19:54 UTC 2015
On 27 January 2015 at 15:27, Edward Lewis <edward.lewis at icann.org> wrote:
> On 1/27/15, 5:46, "bert hubert" <bert.hubert at netherlabs.nl> wrote:
>>Can you name me one client side application that benefits from anything
>>other than the answer section?
> This may have been meant as a rhetorical question, but it’s pretty
> I’ve thought much over the years about a way to mathematically reduce the
> DNS protocol into a state machine. Yeah, I know you’ve heard that joke
> before. The protocol definition stated out life with a few too many
> exceptional cases and over the next decades suffered a few fractures,
> etc., preventing the derivation of a useable state machine. By usable, I
> mean one that can easily be documented, worked with, and explained. The
> DNS today can be described as a state machine, but describing it would be
> no simpler than reading all of the lines of code in all of the
> implementations in play. (Like saying my collection of sea shells is so
> large, I’ve scattered them along all of the beaches of the world.)
I fell in love with state machines, and I'm trying to leverage them as
much as possible in both recursive and
authoritative, but it's sometimes counter-intuitive. So I respect any
effort in making it
simpler and understandable.
> But for this, first, I would like to believe that applications need not
> see anything that is not in the Answer Section. (If so, DNS protocol
> engineers could muck all day with the header and other sections.) Besides
> the protocol-archeological evidence that port 25 (SMTP) and port 53 are
> cousins (referring to the inclusion of address records, when available, in
> the Additional Section if a a mail exchanger record is in the Answer
> Section) there is very little to suggest than any other application “got
> it’s hooks into” the DNS protocol. I say this having been through
> discussions to break that statement.
> There’s one other hook where applications use information outside the
> Answer Section and that is negative answers. The reason is that in a
> negative answer, there may be an empty Answer Section (think CNAME as
> counter example) with either a name error in the rcode field and maybe a
> start of authority record in the Authority section. Applications may not
> necessarily care about the timing parameters (TTL) - but in the sense of
> the question above, I would say that applications might use more detailed
> failure information.
For example the NODATA response can be formatted in multiple ways,
resolvers can't count on authoritative setting AA=1 and so on.
Client application would have to deal with these ambiguities and
couldn't count on it anyway.
While I don't think it's fixable without losing backwards compatibility,
this encourages me in returning "only what I have to", nothing more.
> Ideally, though, all an application would need should be confined to the
> Answer Section. The rest is for the benefit of the DNS system itself.
> (DNSSEC was designed to be consumed within the DNS system, I won’t debate
> whether applications should try to be aware of it. I know there is stated
> interest that applications be aware of DNSSEC, I’m avoiding that here.)
>>It will still be digging through caches and creating larger packets
> My initial reaction - extraneous data has proven to be weaponry in traffic
> flooding attack mechanisms. (Including the upward referrals that became
> to signal lame delegations.)
> Don Quixote
Thanks, I honestly appreciate the insights.
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> dns-jobs mailing list
More information about the dns-operations