Subject: [DNSOP] Wildcard junk vs NXDOMAIN junk

From: "John R. Levine" <[email-masked]>
Date: 7 Apr 2022 12:50:28 -0400

A friend of mine asserts that wildcard DNS records are a problem because 
hostile clients can use them to fill up DNS caches with junk answers to 
random queries that match a wildcard.  But it seems to me that you can do 
it just as well with random queries that match nothing and fill up the 
cache with NXDOMAIN junk answers.  Am I missing something here?

If you add DNSSEC, with or without RFC 8198 response synthesis, the 
details change but I don't think answer does, it's about the same either 
way.

I can see attacks where you might use URLs with wildcard names to fill web 
caches with junk pages (see https://www.web.sp.am/) but that's different.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 07 Apr 2022 22:49:05 +0200

On 7 Apr 2022, at 18:50, John R. Levine wrote:

> A friend of mine asserts that wildcard DNS records are a problem because hostile clients can use them to fill up DNS caches with junk answers to random queries that match a wildcard.  But it seems to me that you can do it just as well with random queries that match nothing and fill up the cache with NXDOMAIN junk answers.  Am I missing something here?

I don't think so, part from of course that the TTL of the cached data might be different depending on whether the query matches something or not.

   Patrik

> If you add DNSSEC, with or without RFC 8198 response synthesis, the details change but I don't think answer does, it's about the same either way.
>
> I can see attacks where you might use URLs with wildcard names to fill web caches with junk pages (see https://www.web.sp.am/) but that's different.
>
> Regards,
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Brian Dickson <[email-masked]>
Date: Thu, 7 Apr 2022 14:26:01 -0700

> details change but I don't think answer does, it's about the same either

Yep, I agree.

However, that does provide motivation for (a) signing zones, and (b)
resolvers doing validation with synthesis.

Together, those reduce (a) load on auth servers, and (b) cache pollution.
Win/win.

Brian

---

From: Paul Vixie <[email-masked]>
Date: Thu, 7 Apr 2022 16:12:20 -0700

Brian Dickson wrote on 2022-04-07 14:26:
> ...
> Together, those reduce (a) load on auth servers, and (b) cache 
> pollution. Win/win.
if those pigs had wings, they could indeed fly. (the motivation is 
assymetric to the benefit, so this is like all other things dnssec 
related, and most things ipv6 related, and so on.)

wildcard synthesis should always have been resolver-side. now we live 
like this. a zero-length EDNS option with a name like REALWILD that 
asked the authority server to include *.example.com as an answer's owner 
name (rather than www.example.com by synthesis) is probably the way out 
of this hell.

-- 
P Vixie

---

From: Mark Andrews <[email-masked]>
Date: Fri, 8 Apr 2022 10:21:48 +1000

> On 8 Apr 2022, at 09:12, Paul Vixie <paul=[email-masked]> wrote:
>> However, that does provide motivation for (a) signing zones, and (b) resolvers doing validation with synthesis.
>> Together, those reduce (a) load on auth servers, and (b) cache pollution. Win/win.
> if those pigs had wings, they could indeed fly. (the motivation is assymetric to the benefit, so this is like all other things dnssec related, and most things ipv6 related, and so on.)
> 
> wildcard synthesis should always have been resolver-side. now we live like this. a zero-length EDNS option with a name like REALWILD that asked the authority server to include *.example.com as an answer's owner name (rather than www.example.com by synthesis) is probably the way out of this hell.

Wildcard synthesis in the resolver only works if you have NSEC/NSEC3 records (or the equivalent) that shows the
non-existence of the QNAME otherwise the resolver would replace explicit data with synthesised data.  Real wildcard
+ covering NSEC/NSEC3 range would work.  Getting rid of OPTOUT would also help as you can’t synthesise using an OPTOUT
NSEC3 record.  Zone operators can turn off OPTOUT today.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Thu, 7 Apr 2022 19:40:36 -0700

Mark Andrews wrote on 2022-04-07 17:21:
> 
> 
>> On 8 Apr 2022, at 09:12, Paul Vixie
>> <paul=[email-masked]> wrote: ...
>> 
>> wildcard synthesis should always have been resolver-side. now we
>> live like this. a zero-length EDNS option with a name like REALWILD
>> that asked the authority server to include *.example.com as an
>> answer's owner name (rather than www.example.com by synthesis) is
>> probably the way out of this hell.
> 
> Wildcard synthesis in the resolver only works if you have NSEC/NSEC3
> records (or the equivalent) that shows the non-existence of the QNAME
> otherwise the resolver would replace explicit data with synthesised
> data.  Real wildcard + covering NSEC/NSEC3 range would work.  Getting
> rid of OPTOUT would also help as you can’t synthesise using an
> OPTOUT NSEC3 record.  Zone operators can turn off OPTOUT today.

a feature that only works with dnssec sounds good to me.

-- 
P Vixie