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

[Kumar Ashutosh]

Pretty much a "horses for courses" scenario

Can be helpful for LDNS cache if data sanctity is maintained in the extra answers.
The important question for what should be  the relation between actual answer and extra answer 

Also, just a fleeting thought, considering the limitations of mobile networks, it would be better to allow some kind of reverse-probing before sending bigger data to the end clients.

Thanks
Ashu
Microsoft


-----Original Message-----
From: dns-operations [mailto:dns-operations-bounces at dns-oarc.net] On Behalf Of Marek Vavruša
Sent: Tuesday, January 27, 2015 21:50
To: Edward Lewis
Cc: dns-operations at dns-oarc.net
Subject: Re: [dns-operations] extra records in resolver answer, any benefit?

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

_______________________________________________
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