Subject: Re: [DNSOP] Question on interpretation of DO and CD

From: Mark Andrews <[email-masked]>
Date: Sat, 9 Oct 2021 07:18:58 +1100

Yes it will be unfiltered but the point of DNSSEC is to filter out bad answers (that is what the ignore bogus responses achieves) and if you are behind a recursive server you need it to do the filtering of the answers it gets as you aren’t in a position to wait for the good answer as they won’t come to you nor are you in the position to ask the authoritatives directly.  It can wait for good answers by just rejecting the spoofed answers and continuing to listen for the real answer. 

-- 
Mark Andrews

> On 9 Oct 2021, at 06:12, Eric Rescorla <[email-masked]> wrote:
> 
> Hi Mark,
> 
> Thanks for your response.
> 
> On Wed, Oct 6, 2021 at 7:41 PM Mark Andrews <[email-masked]> wrote:
>> You should also note that a validating stub resolver (or anything talking
>> through a validating resolver) should be prepared to send *both* DO and
>> DO+CD queries. There are different error conditions / threats that are
>> mitigated by each of these settings and only by trying the other on error
>> can you ensure that you have mitigated both.
>> 
>> If the validating resolver is being sent spoofed/erroneous traffic DO
>> will filter that traffic out of the response stream.  DO+CD works around
>> bad time/trust-anchors in the validating resolver.
> 
> Can you elaborate on this a bit? I.e., if I sent DO + CD, then won't I just
> get an unfiltered view and be able to sort it out locally? What am I missing?
> 
> -Ekr
> 
>> Mark
>> 
>> > On 7 Oct 2021, at 10:47, Eric Rescorla <[email-masked]> wrote:
>> > 
>> > Hi folks,
>> > 
>> > We've been trying to take some measurements of the success of endpoint
>> > DNSSEC validation and run into some confusion about the implications
>> > of the DO and CD bits. Sorry if these are dumb questions.
>> > 
>> > In the section on stub resolvers RFC 4035 says:
>> > 
>> >    A validating security-aware stub resolver MUST set the DO bit,
>> >    because otherwise it will not receive the DNSSEC RRs it needs to
>> >    perform signature validation. (S 4.9.1)
>> > 
>> > and:
>> >    A validating security-aware stub resolver SHOULD set the CD bit,
>> >    because otherwise the security-aware recursive name server will
>> >    answer the query using the name server's local policy, which may
>> >    prevent the stub resolver from receiving data that would be
>> >    acceptable to the stub resolver's local policy. (S 4.9.2)
>> > 
>> > 
>> > And then in S 5, says:
>> >    When a resolver indicates support for DNSSEC (by setting the DO bit),
>> >    a security-aware name server should attempt to provide the necessary
>> >    DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
>> > 
>> > 
>> > Looking at things from the stub resolver's perspective, if the zone is
>> > signed, then the stub resolver must receive the necessary RRsets or
>> > fail the resolution. So, there needs to be an unambiguous way for the
>> > stub to tell the recursive to deliver them. Am I right so far?
>> > 
>> > Reading the above text, I infer that this signal is the DO bit. This
>> > should cause the recursive to deliver the right RRsets (if available)
>> > (I note that this text just says "name server" from which I'm
>> > inferring that it applies to both authoritative and recursive).  Is
>> > this correct? If so, is the fact that this is "should" and not
>> > "SHOULD" telling me something"?
>> > 
>> > Finally, as I understand it, the function of the CD bit is to tell the
>> > recursive resolver to return records even it if cannot validate them
>> > itself. However, it does *not* tell the recursive resolver to send the
>> > RRsets in the first place, as that's the function of CD.
>> > 
>> > 
>> > Summarizing all this, I have the following table of what the stub
>> > should expect to receive if the recursive is a validating resolver and
>> > it asks for an A record (just as an example)
>> > 
>> > 
>> > Bits set         Records valid        Records invalid
>> > -----------------------------------------------------
>> > None             A + ???                        Error
>> > DO               A + DNSSEC                     Error
>> > CD               A + ???                      A + ???
>> > DO + CD          A + DNSSEC                A + DNSSEC
>> > 
>> > Where "A + DNSSEC" means "A + plus the DNSSEC records" and "A + ???"
>> > means "A + maybe some DSNSSEC records depending on what the recursive
>> > wants".
>> > 
>> > Thanks in advance,
>> > -Ekr
>> > _______________________________________________
>> > DNSOP mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 8 Oct 2021 13:47:04 -0700

Thanks for the explanation. That's super helpful.

-Ekr

On Fri, Oct 8, 2021 at 1:19 PM Mark Andrews <[email-masked]> wrote:

> 
> 
> Yes it will be unfiltered but the point of DNSSEC is to filter out bad
> answers (that is what the ignore bogus responses achieves) and if you are
> behind a recursive server you need it to do the filtering of the answers it
> gets as you aren’t in a position to wait for the good answer as they won’t
> come to you nor are you in the position to ask the authoritatives
> directly.  It can wait for good answers by just rejecting the spoofed
> answers and continuing to listen for the real answer.
>
> --
> Mark Andrews
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 12 Oct 2021 14:24:01 -0400

On Sat, Oct 09, 2021 at 07:18:58AM +1100, Mark Andrews wrote:

> answers (that is what the ignore bogus responses achieves) and if you
> are behind a recursive server you need it to do the filtering of the
> answers it gets as you aren’t in a position to wait for the good
> answer as they won’t come to you nor are you in the position to ask
> the authoritatives directly.  It can wait for good answers by just
> rejecting the spoofed answers and continuing to listen for the real
> answer. 

IIRC the forwarder may have a (logically) separate cache with bogus
answers, which it would normally censor by returning SERVFAIL, but will
disgorge when the "CD" bit is set.  Or absent such a cache, it may ask
again, and upon receiving fresh answers that fail validation,
nevertheless forward these on.

Either way, when the stub resolver has trust anchors not known to the
forwarder, that render the response valid, the "CD" bit could help mask
the difference.

For example, though the domain cirroscope.com has no DNSKEYs matching
its DS RRs:

    https://dnsviz.net/d/cirroscope.com/YWXRbg/dnssec/

setting the CD bit will make its DNSKEY RRset visible even via a
validating forwarder, and if the stub happens to have a trust-anchor
set for either the algorithm 8 or algorithm 5 KSK, then the stub
may well be able to validate the zone, the signatures are all valid,
we just don't have a SEP from .com to cirroscope.com:

    cirroscope.com.         20468 IN DNSKEY 257 3 5 (
                                    AwEAAarIbZcs5FXsMySPAeIo51z7EB7CX61KTRFSqCpo
                                    ciNlU7OJsX2BSz1UeBIqJnuIn+GNAsf1yTE3i5cKujzg
                                    SUWOQF8PKjTQ24nYguWXYaSykzGFK8Bp/6Bm+TGVYMmh
                                    8Ab8j3hwRZuaBb3JuPQJvEaWnJgdYgxfYoxaOci8hG5U
                                    lYJH8GiFhnQLZISmemIk/S5qizYyPAG+dbnTpZvmGsB+
                                    0uCrlVMsFcN2YQVCezeOTKmMmjYrW+rzVhv9NFeRHD9+
                                    c6D1a7aZO6qj3H7MkhOQCU44x9c446pCUN8w9Gamlrij
                                    Xlt7PH8OzgBdBB6d+ZaIVCZpAl16GmZHX/M1t50=
                                    ) ; KSK; alg = RSASHA1 ; key id = 44602
    cirroscope.com.         20468 IN DNSKEY 257 3 8 (
                                    AwEAAaLcgz5gnyxbosRvZnyyCFVk5crNSOfOWvbHrVLX
                                    +pMaQYoWhPJzk6Vj2TCOUhZaCZKikQ19lk95o3TMI9xH
                                    CV8AH7KJwC6U2Lg4gcUtbRXN6zc322eJ99xqUElMAO+2
                                    0TQETz0Qngxla9gK/Oxpp+VsUSl83uWgmOcEqU/jLRON
                                    c4HyfoH5lx7b9QKGYxoZvzYu7IFT1ET6/81nIsK48w38
                                    mnnFjRCyJEqy7Wtq27rwx47BHCVr0LDe61dTB9HUY94v
                                    5NSpGgN+W2s9cazTjPCupkNg4U9GUHGxDeT2lM0+O9zH
                                    6oY0WvnXonbZQFp+6mxkVZt3i1TZ2yjVnEDgYus=
                                    ) ; KSK; alg = RSASHA256 ; key id = 37636
    cirroscope.com.         20468 IN DNSKEY 256 3 5 (
                                    AwEAAbNDmSwB7ns19bqqXtttgrgexDCuJngapNpV8Akk
                                    M3+YCR9saIvC4RXEteDLV10RlidNnym8Vg2dZWisutc9
                                    61VNkQXEKdo4eTfJJRP3/ifCyVAyLfZm6/Thh0grLFHj
                                    TjjKQprUk5exWfQtHPLqRCZ/40aE7Ev1Gz8hBgb10oxf
                                    ) ; ZSK; alg = RSASHA1 ; key id = 33267
    cirroscope.com.         20468 IN DNSKEY 256 3 8 (
                                    AwEAAeMfFqRTMJB2qiJj+A2Th570cOOe5nT9K2gd/rmA
                                    vbib9jV4P1V5DmdHEZfrgtgoAFCzqWu8kU4uFUZfVXFQ
                                    tel/IVpYWzzH+3rofiQHMwRHEgjv9vWKEMlEdg/SxyDS
                                    WTH6qZIIvfgKEZ32y+jCD11vpZPpuj6ItuRm+EU++OP9
                                    55ZBUBKbfTJtPtQh67c5aMJOHx6eBuhZYeBhgByQ+RVJ
                                    yJgkhjgghluVYiXqDNv2ZCPNnhVu8KZ8Im+xs1AnLlwb
                                    zHafuuidQJRQrAa53sSNvBb1uliP35qDn6wicHLbtjXY
                                    roMFCsCVXmsx/Gg1qv5oZLPAgyfIse1slLqATNk=
                                    ) ; ZSK; alg = RSASHA256 ; key id = 3093
    cirroscope.com.         20468 IN RRSIG DNSKEY 5 2 86400 (
                                    20211108205913 20211009205913 33267 cirroscope.com.
                                    N4rtGV5iyM0HRxvK34j2FKtb7WiqQvHMRGuo4OjB07/s
                                    06BEMix6OCyDwcVpei7kp8rKXZ4DAHqT1DxDdk8d8K3E
                                    v1b3GehN7blLNDf52uUnoXjgIs3MEWmAE/69xmIwUExa
                                    /CRP7QQVj96Kp7g4iR35xqAbmfjCcQrrk7Vll6U= )
    cirroscope.com.         20468 IN RRSIG DNSKEY 5 2 86400 (
                                    20211108205913 20211009205913 44602 cirroscope.com.
                                    Yps3RHKwb3Q1z/dQTkWB9S5M8+dwXgEad9yyiJiGo8pm
                                    fkcgiMnZJ2N5bSNG2Uffp1p4r4oWXcPfrTCOsydu/c2/
                                    qjtMvQAQ8PeA/cgDuRR6cXUOIvAZlaOg1jTXYrb4OCeS
                                    Z8XqkTLrd6ODBtYkurV4L69YiO78wVnFwpbL9HCOFHTz
                                    L3Td9SdTYs+cNosCQvGQkMdXIS9Fl6CLCwshzFv+soON
                                    mZXimNSAiZ97u8lze4tT5nbS8A4fGLpdvdmUqxnGHIez
                                    0oK6pfof4ktvqVr0Jwa2PahATjfcsX1lFCnnMRQtLN/A
                                    CaF6x3CjQ8umWPvfvrFfIV6t8rXEv5wZkw== )
    cirroscope.com.         20468 IN RRSIG DNSKEY 8 2 86400 (
                                    20211108205913 20211009205913 3093 cirroscope.com.
                                    EMTLRz8Nvn4o1e8P86z/tkCBqz3LECqU5jZyuJrd1Zlq
                                    77KTBmRgmEsbuc3Nerh/BHR3/e+U9zKSQz+HZsh2lGmb
                                    ORn9etG55HTtkTBG7TQ2QPhn85KNc05M6aNevaH5H+4x
                                    QquXE4ofI7kcXcO09mKHhLvvjlB2sbEQDnnp3ALRPqq4
                                    QnagvOpu8JkoXv/q4eGEFvSQm8nzV6P04TPmr36Avpwt
                                    Sz0aaVp9U3sRqwjbg6QoY6VYBWeDwUcYPG6lwCFixgUY
                                    doV3EWOvSStuRno+kZgdJ10T7FTH5Bs1mG//FMg40Z9K
                                    nta8f6xd6qr7H4ec41I85eyc3oRIXl6PGA== )
    cirroscope.com.         20468 IN RRSIG DNSKEY 8 2 86400 (
                                    20211108205913 20211009205913 37636 cirroscope.com.
                                    Zk1+9iWged2qsx1dkCp4goZ0Jt1wmr1vRQCQVmM8H5Fq
                                    cxhVoDcYUcRFk6YWr/KOKInqmKQVC+JcOXX6k46lNDZP
                                    1uu87j9Yhg9Z7w2d25asbOXhG9vELyGUYdFobEb6mpnt
                                    sJF7CoJ84b6ijwRFaNf3BbrpbnPEOLWF2QepjhRieKGi
                                    NggMaoSTLTfmmedHV/kD1BcWNZi5MGFNkiHvkXyrbSV1
                                    d4qZYlFRYCWyBwtV6dLMwe7qg8zGtmFTg+Q9nN23uC90
                                    x6j9ViJHbTsnTQwnq7P0XRPAK95LR6Y9uEADA4jZlGNG
                                    TJ/0GvCPOwpH/iZzc4TP3Xjl9BuH+iWRWA== )

-- 
    Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 13 Oct 2021 09:30:01 +1100

> On 13 Oct 2021, at 05:24, Viktor Dukhovni <[email-masked]> wrote:
> 

As I have said, stub resolvers need to send *both* CD=0 and CD=1 queries
to handle all the corner cases in DNSSEC.  Disgorging bogus answers doesn’t
usually result in getting an answer that successfully validates.

> we just don't have a SEP from .com to cirroscope.com:

But everyone else in the world will be seeing a broken secure delegation.
In practice this is not a sustainable configuration.