On 23 Jul 2019, at 20:10, Puneet Sood wrote:

>> draft-hoffman-dns-terminology-ter-01.txt says:
>>       Applications Doing DNS (ADD):  Applications that act as stub
>>       resolvers.  This is in contrast to the way that applications
>>       traditionally have gotten DNS information, which is to use system
>>       calls to the operating system on the computer, and have the
>>       operating system act as the stub resolver.  "Applications Doing
>>       DNS" is not limited to particular transports: it applies equally
>>       to DNS-over-TLS, DNS-over-HTTPS, Do53, and future DNS transports.
>>       ( Temporary note, to be removed before publication as an RFC:
>>       there is a mailing list discussing Applications Doing DNS at
>>       https://www.ietf.org/mailman/listinfo/add )
>>
>> While I agree that “add” today covers discussion around the case described 
>> in here, but the reason that it covers it  is because “add” acts as a "catch 
>> all bucket" for “various DNS things not well defined”.
>> If we want to cover the case of an application acts as/embed a stub 
>> resolver, we may want to define a term (and draft) that covers exactly that, 
>> instead of using the much wider term.
>
> I like this clarification of what people are using ADD to mean. As I am 
> listening to the ADD BoF talks, I want to point out that
> applications *have* been doing - just using a system API. The discussion and 
> activity is now around applications embedding stub resolver functionality. So 
> I propose term like Embedded Application Resolver Stub (EARS).

First of all, the calls being used by applications are not system calls. Not 
the definition of system calls I know of at least.

The difference between traditional DNS and what we have here to be is that in 
traditional DNS the configuration and control of where to send the DNS packets 
is made by the operating system, while with ADD it is done by the application.

The rest of the stuff is very similar. Still RD flag set. Still not much clue 
on the client side etc.

Then, as others have said, discussion about other transport protocols have been 
sneaking in here, but that does not really matter for me when talking about 
traditional DNS or ADD. Do53 or DoT or whatever is just another transport.

Good to define the terms though! But if you have different DoT things for when 
RD flag is set or not, why not also for Do53?

   Patrik

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to