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

[Edward Lewis]

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

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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150127/93c1308c/attachment.bin>