On Fri, Jan 26, 2018 at 06:02:00PM -0600, Ted Lemon wrote:
> On Jan 26, 2018, at 5:03 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > Multiple participants in this discussion have pointed out that such
> > queries are rare.
>
> Sigh. Yes, such queries are rare. The things that make those queries
> are the things that are vulnerable. That such queries are rare is further
> evidence that responding to them when they come with NXDOMAIN is a safe
> choice to make.
Protecting the residual cases is already covered by the draft's
requirement on the platform's resolution library to short-circuit
"localhost". There is no need to impose a mandate to break these
cases on the recursive resolver.
> > And, we must not forget that, absent local
> > overrides, the iterative resolvers are *already* returning NXDomain,
> > because the authoritative data from the root returns NXDomain.
>
> That's a good point, of course. However, I think we heard in the
> discussion prior to adoption that this is not in fact the default behavior
> for all recursive resolvers.
Once more, *absent local overrides*, all resolvers are already
returning NXDomain. Many resolvers don't have local overrides,
some do.
> > Yes. Keep the MUST for the platform library. Downgrade the MUST for
> > the iterative resolver to a SHOULD (absent local data), and either
> > exempt DNSSEC or explain why "bogus" local NXDomain is better than
> > a cacheable validated NXDomain from the roots.
>
> How about if it says "SHOULD" but explains what the exception is, and
> strongly advocates the position that only when that exception is applicable
> should this be treated as optional behavior.
Sure. The main exception is when the resolver is serving only
loopback clients. And I am not opposed to text that discourages
"shared" recursive resolvers from serving local data for "localhost".
What remains then beyond recommending NXDomain for non-DNSSEC queries,
is a well-reasoned recommendation for what to do with DNSSEC queries
(DO bit). My recommendation, as mentioned a few times upthread, is
to cache and serve the root zone's validated NXDomain.
> I would say that the exception is "when answering queries for the local
> host" or something, but I don't understand the intricacies of your use
> case sufficiently to know what would satisfy it. I thought I understood
> your use case to be the case where the stub resolver is on the same host
> as the recursive resolver, but I may have misunderstood.
"Whitelisting" loopback resolvers is largely sufficient, provided that
the language is changed from MUST to SHOULD.
On Sat, Jan 27, 2018 at 12:56:23PM -0500, Warren Kumari wrote:
> > And, we must not forget that, absent local
> > overrides, the iterative resolvers are *already* returning NXDomain,
> > because the authoritative data from the root returns NXDomain.
>
> ... do they?
Definitely, *absent local overrides"*.
> Google Public DNS:
> $ dig +dnssec localhost @8.8.8.8
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62555
Google has no such overrides. And yet, localhost queries continue,
so NXDomain responses are not proving to be an effective motivation
to short-circuit the issue upstream.
> Verisign Public DNS:
> $ dig +dnssec localhost @64.6.64.6
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8025
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; ANSWER SECTION:
> localhost. 10687 IN A 127.0.0.1
>
> Quad9:
> $ dig +dnssec localhost @9.9.9.9
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22677
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; ANSWER SECTION:
> localhost. 86170 IN A 127.0.0.1
>
> OpenDNS:
> dig +dnssec localhost @208.67.222.222
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14156
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; ANSWER SECTION:
> localhost. 604800 IN A 127.0.0.1
Verisign, Quad9 and OpenDNS do have the traditional "local overrides".
Perhaps when they become aware of this draft, they'll drop the
override zone, or perhaps they'll leave the short-circuit decision
to the platform library maintainers. Time will tell.
In summary I see the following actions to move this forward:
- Encourage (SHOULD) recursive resolvers to not serve local
data for localhost, except perhaps when the resolver is a
loopback only resolver.
- Encourage (SHOULD) recursive resolvers that don't have local
data for localhost to short-circuit insecure (no DO bit) localhost
A/AAAA queries with NXDomain without forwarding these upstream
to the roots.
- Suggest that rather than returning "bogus" NXDomain responses,
secure (DO bit set) queries should get secure NXDomain
responses (thus forwarded to the root servers and cached).
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
