Subject: [Add] Fwd: New Version Notification for draft-reddy-add-resolver-info-02.txt

From: tirumal reddy <[email-masked]>
Date: Mon, 5 Apr 2021 14:46:22 +0530

Revised draft
https://datatracker.ietf.org/doc/html/draft-reddy-add-resolver-info-02
addresses comments from Ben. As a reminder, it specifies a method for DNS
resolvers to publish information about themselves.

Further comments and suggestions are welcome.

-Tiru

---------- Forwarded message ---------
From: <[email-masked]>
Date: Mon, 5 Apr 2021 at 14:00
Subject: New Version Notification for draft-reddy-add-resolver-info-02.txt
To: Tirumaleswar Reddy.K <[email-masked]>, Mohamed Boucadair <
[email-masked]>

A new version of I-D, draft-reddy-add-resolver-info-02.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:           draft-reddy-add-resolver-info
Revision:       02
Title:          DNS Resolver Information
Document date:  2021-04-05
Group:          Individual Submission
Pages:          8
URL:
https://www.ietf.org/archive/id/draft-reddy-add-resolver-info-02.txt
Status:
https://datatracker.ietf.org/doc/draft-reddy-add-resolver-info/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-add-resolver-info
Htmlized:       https://tools.ietf.org/html/draft-reddy-add-resolver-info-02
Diff:
https://www.ietf.org/rfcdiff?url2=draft-reddy-add-resolver-info-02

Abstract:
   This document specifies a method for DNS resolvers to publish
   information about themselves.  Clients can use the resolver
   information to identify the capabilities of DNS resolvers.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tony Finch <[email-masked]>
Date: Wed, 7 Apr 2021 20:25:17 +0100

I've had a look at this draft.

I can't see anything that specifies the wire format or presentation format
of the RESINFO RDATA. In wire format, I guess the server is supposed to
write the JSON without any extra framing? (for instance, nothing like TXT
record byte lengths)

What is the presentation format supposed to be? Does an RDATA parser need
to rely on the JSON being self-delimiting? Or does the JSON need to be
embedded in quotes with escaping? (yuck)

[ Aside: a slightly more DNS-flavoured RDATA format, that could reuse
existing code, would have the same format as HINFO records, using the
first string as a key and the second string as its value, and there are
multiple RESINFO records to communicate all the key/value pairs. But that
doesn't provide a syntax for structured values. ]

In the security considerations, I think there ought to be a caveat that
a client won't be able to do DNSSEC validation for resolver.arpa, and I
have some doubt about how much a client needs to worry about it when it
gets the ADN over an insecure channel.

Editorial nit: there are missing citations for [I-D.ietf-add-dnr] and
[I-D.ietf-add-ddr]

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
Rockall, Malin, South Hebrides: Southwesterly 4 to 6 veering westerly
or northwesterly 6 to gale 8. Moderate or rough at first except in
Rockall, otherwise rough or very rough. Showers. Good, occasionally
poor.

---

From: tirumal reddy <[email-masked]>
Date: Thu, 8 Apr 2021 15:09:45 +0530

Hi Tony,

Thanks for the review. Please see inline

> doesn't provide a syntax for structured values. ]

The format used is I-JSON (defined in https://tools.ietf.org/html/rfc7493)
and the returned JSON object will contain name/value pairs (JSON text).
JSON is used to create a new registry to allow new attributes to be defined
in future specifications (see Section 7.2).

> gets the ADN over an insecure channel.

DNSSEC validation is not possible for resolver.arpa but possible for
TargetName retrieved using SVCB lookup. Added the following text for
clarity:

For example, if the special use domain name "resolver.arpa" is used to
discover the Encrypted DNS server, the client can first query the resolver
for SVCB records for "dns://resolver.arpa" to get the fully-qualified
TargetName and then retrieve the resolver information using the RESINFO
RRtype, QNAME of the TargetName. The DNS resolver information can be
retrieved after the encrypted connection is established to the DNS server
or retrieved before the encrypted connection is established to the DNS
server by using DNSSEC validation of the response.

The discovery mechanism of the ADN can be insecure (e.g., DNR or DDR) or
secure (e.g., IKEv2). In case of insecure discovery like DHCP/RA,
DHCP-shield or RA-guard would protect from spoofed DHCP responses & RA
messages but DNS response is still susceptible to spoofing.

> Editorial nit: there are missing citations for [I-D.ietf-add-dnr] and

Thanks, fixed in my local copy.

Cheers,
-Tiru

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 8 Apr 2021 11:25:15 -0400

On Thu, Apr 8, 2021 at 5:40 AM tirumal reddy <[email-masked]> wrote:
..

> RRtype, QNAME of the TargetName.
>

I don't think this is a good design.  It does not add security, and having
multiple places to look for RESINFO records seems likely to add complexity
and reduce interoperability.

The DNS resolver information can be retrieved after the encrypted
> connection is established to the DNS server
>

This seems like a much better approach.

Of course, if the resolver is known by name (resolver.example), then it can
simply publish a RESINFO record on that name.

---

From: tirumal reddy <[email-masked]>
Date: Mon, 12 Apr 2021 15:14:47 +0530

> and reduce interoperability.

The SVCB lookup is mandatory for SUDN ("resolver.arpa") to get the
designated resolver name (see
https://tools.ietf.org/html/draft-ietf-add-ddr-00#section-4). The client
can use the discovered designated resolver name to look for a RESINFO
record after the encrypted connection is established.

Please clarify what change you are proposing to the draft.

> Of course, if the resolver is known by name (resolver.example), then it
> can simply publish a RESINFO record on that name.
>

Yes.

-Tiru

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 12 Apr 2021 10:55:01 -0400

On Mon, Apr 12, 2021 at 5:44 AM tirumal reddy <[email-masked]> wrote:

>> I don't think this is a good design.  It does not add security, and
>> having multiple places to look for RESINFO records seems likely to add
>> complexity and reduce interoperability.
>>
>
draft-02 says:

>    If the special use domain name "resolver.arpa" defined in [I-D.ietf-
>    add-ddr] is used to discover the Encrypted DNS server, the client can
>    first retrieve a CNAME that aliases `_dns.resolver.arpa` to
>    `_dns.$HOSTNAME` and then retrieve the resolver information using the
>    RESINFO RRtype and QNAME of the `$HOSTNAME`.

I think this should say:

>    If the special use domain name "resolver.arpa" defined in [I-D.ietf-
>    add-ddr] is used to discover the Encrypted DNS server, the client can
>    retrieve the resolver information using the
>    RESINFO RRtype and a QNAME of "resolver.arpa".

Using TargetName from SVCB will not work in general.  For example,
TargetName may be shared by many different services (even different
resolvers) with different RESINFO.

---

From: tirumal reddy <[email-masked]>
Date: Tue, 13 Apr 2021 12:32:28 +0530

> resolvers) with different RESINFO.

Thanks, fixed. I did not see any description and examples of the above
explanation in draft-schwartz-svcb-dns. My understanding is the SVCB
response would be customized to provide an encrypted resolver whose service
is equivalent to the unencrypted resolver (e.g., assuming home admin may or
may not subscribe for malware filtering service, the DoH path in the SvcParams
would vary based on the subscription).

-Tiru