[dns-operations] extra records in resolver answer, any benefit?

[Marek Vavruša]

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
> interesting.
>
> 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
>>though.
>
> 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.

Marek

> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs