Re: [DNSOP] How does NSEC record(s) prove the Name Error?

[Viktor Dukhovni]

On Tue, Oct 26, 2021 at 10:21:29PM -0700, Joey Deng wrote:

> If the question name appears in-between the current owner name and the
> next owner name of the NSEC record, which means that there is no exact
> name matching: We should prove that no possible wildcard RRset exists
> that could have been used to generate a positive response.

This is accomplished via a 'closest encloser' proof, in the case of NSEC
this takes up to two records:

1. An NSEC record that excludes the shortest non-existent ancestor
   of the qname.  The closest encloser is then the longest domain
   equal to or containing both endpoints of the NSEC pair.

2. An NSEC record showing non-existence of a wildcard below that
   closest encloser (which may be the same as (1) in some cases.

> What are possible wildcard RRsets for a given name?

The label count of the wildcard response must then match the number of
labels in the closest encloser.  That is, the "*" domain would have to
have been an immediate child of the closest encloser (1).

> My understanding about possible wildcard RRsets for a given name are
> all the possible sources of synthesis.  For example, the possible
> wildcard RRsets that can be used to answer question .ietf.org
>  are:
>
> *.ietf.org

That would be the only one, because 'ietf.org' is known to exist.
[ There's presently no "*.ietf.org" wildcard domain. ]

> *.org

No, this lies above the closest encloser.

> * (but I think root can never be a wildcard, so this is impossible)

No, this lies above the closest encloser.  A "*" node in the root zone
is technically possible, but none is likely to ever be published.  If it
were to exist it would become the source of truth for all invalid and
typoed TLDs, which would be rather suboptimal.

> Is my understanding correct?

No.

> For example, if I send a DNS query for .ietf.org with DO/CD bit
> set, there will be two NSEC records returned:
> 
> ```
> $ dig ".ietf.org"  +dnssec +cdflag +tcp @1.1.1.1
> 
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34013
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

This is an NXDOMAIN answer, not a NODATA or wildcard sythesised answer.

> wwwtest.ietf.org. 1800IN  NSECxml2rfc.ietf.org. CNAME RRSIG 
> NSEC

This record proves the non-existence of the qname, and also "ietf.org"
as the closest encloser.

> ietf.org. 1800IN  NSEC_dmarc.ietf.org. A NS SOA MX 
> TXT  RRSIG NSEC DNSKEY SPF

This record proves that "*.ietf.org" does not exist, and we're done.

> wwwtest.ietf.org. -> xml2rfc.ietf.org. tells us that the exact name
> match for .ietf.org does not exist, since it appears in-between
> the two names.

Correct.

> Therefore, the remaining ietf.org. -> _dmarc.ietf.org. NSEC should be
> used to prove that “no possible wildcard RRset exists that could have
> been used to generate a positive response” for the name .ietf.org.

Which it does, since the only potential wildcard is '*.ietf.org', given
"ietf.org" as the closest encloser. "*.ietf.org" would be between these
if it existed.

> How can ietf.org. -> _dmarc.ietf.org NSEC be used to prove that there
> is no wildcard record for the name .ietf.org?

By virtue of the fact that wildcards never apply at or below sibling
names that exist.  If foo.example.com exists, then wildcards at
"*.example.com", "*.com", or "*" can never apply to any query at or
below "foo.bar.example.com".  The "*.example.com" wildcard can only
apply to names ending in a non-existent sibling of the wildcard
label (.example.com).

> Do we need to prove that all the possible sources of synthesis for
> .ietf.org appear in-between ietf.org. and _dmarc.ietf.org?

There is only ever one such possible source.  The "*" label under
the closest encloser.

> Or do we only need to prove that *.ietf.org appears in-between
> ietf.org. and _dmarc.ietf.org?

Since there's only one possible source, this is the one to
disprove.

> If so why do we choose *.ietf.org instead of *.org or *?

See above.

-- 
VIktor.

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

Re: [DNSOP] How does NSEC record(s) prove the Name Error?

[Matthijs Mekking]

Hi,

The short answer is "find the closest encloser and determine the source
of synthesis.

I can recommend reading RFC 4592 "The Role of Wildcards in the Domain
Name System" to understand better how wildcards work.

I can recommend reading RFC 7129 "Authenticated Denial of Existence in
the DNS" to understand how NSEC proofs work.


On 10/27/21 7:21 AM, Joey Deng wrote:
> Hi Folks,
> 
> I have a very basic question about NSEC record in DNSSEC validation:
> 
> How does NSEC record(s) prove the Name Error?
> 
> In [RFC 4035 5.4. Authenticated Denial of
> Existence](https://datatracker.ietf.org/doc/html/rfc4035#section-5.4
> ), it says:
> 
>>o  If the requested RR name matches the owner name of an
>>   authenticated NSEC RR, then the NSEC RR's type bit map field lists
>>   all RR types present at that owner name, and a resolver can prove
>>   that the requested RR type does not exist by checking for the RR
>>   type in the bit map.  If the number of labels in an authenticated
>>   NSEC RR's owner name equals the Labels field of the covering RRSIG
>>   RR, then the existence of the NSEC RR proves that wildcard
>>   expansion could not have been used to match the request.
>>
>>o  If the requested RR name would appear after an authenticated NSEC
>>   RR's owner name and before the name listed in that NSEC RR's Next
>>   Domain Name field according to the canonical DNS name order
>>   defined in [RFC4034 ], 
>> then no RRsets with the requested name exist
>>   in the zone.  However, it is possible that a wildcard could be
>>   used to match the requested RR owner name and type, so proving
>>   that the requested RRset does not exist also requires proving that
>>   no possible wildcard RRset exists that could have been used to
>>   generate a positive response.
>>
> 
> I can understand the first point, because it is an exact name matching.
> However, what makes me feel confused is the second one:
> 
> If the question name appears in-between the current owner name and the
> next owner name of the NSEC record, which means that there is no exact
> name matching:
> We should prove that
>> no possible wildcard RRset exists that could have been used to generate a 
>> positive response.
> 
> But it does not describe how to prove it,
> 
> What are possible wildcard RRsets for a given name?

For a given name, find the closest encloser and calculate the source of
synthesis: *.. The resource records for the source of
synthesis in the zone give you the possible wildcard RRsets.


> My understanding about possible wildcard RRsets for a given name are all
> the possible sources of synthesis.
> For example, the possible wildcard RRsets that can be used to answer
> question .ietf.org   are:
> *.ietf.org 
> *.org
> * (but I think root can never be a wildcard, so this is impossible)
> 
> Is my understanding correct?

No, in this example it can only answer for *.ietf.org, as "ietf.org" is
the closest encloser for "www.ietf.org".

> 
> 
> For example, if I send a DNS query for .ietf.org
>  with DO/CD bit set, there will be two NSEC
> records returned:
...
> 
> The two returned NSEC records are:
> wwwtest.ietf.org . -> xml2rfc.ietf.org
> .
> ietf.org . -> _dmarc.ietf.org .
> 
> If we follow the steps described by [RFC 4035 5.4. Authenticated Denial
> of Existence](https://datatracker.ietf.org/doc/html/rfc4035#section-5.4
> ), we will
> find that:
> 
> wwwtest.ietf.org . -> xml2rfc.ietf.org
> . tells us that the exact name match for
> .ietf.org  does not exist, since it appears
> in-between the two names. Therefore, the remaining ietf.org
> . -> _dmarc.ietf.org . NSEC
> should be used to prove that “no possible wildcard RRset exists that
> could have been used to generate a positive response” for the name
> .ietf.org .
> 
> Therefore, my question is:
> *How can ietf.org . -> _dmarc.ietf.org
>  NSEC be used to prove that there is no wildcard
> record for the name .ietf.org ?* Do we need to
> prove that all the possible sources of synthesis for .ietf.org
>  appear in-between ietf.org . and
> _dmarc.ietf.org ?

The NSEC record ietf.org -> _dmarc.ietf.org proves that there is no
source of synthesis for ".ietf.org" so we could not have generated a
wildcard response (note there is only ever one source of s

Re: [DNSOP] How does NSEC record(s) prove the Name Error?

[Mark Andrews]

> On 27 Oct 2021, at 17:25, Mark Andrews  wrote:
> 
> For a given QNAME there is exactly one possible wild card name it can match 
> depending
> on all the other names that exist.  See the rules for when a QNAME matches a 
> wildcard.
> 
> NXDOMAIN proves that a QNAME does not exist.  The NSEC record that proves 
> that a QNAME
> does not exist also proves the closest encloser name.  It is this name to 
> which you
> prepend the * label and it is that name that you prove does not exist.  
> Similarly for
> NSEC3 except that the closest provable encloser may or may not be the NSEC3 
> record
> that proves the QNAME does not exist.
> 
> An NSEC NXDOMAIN proof has 1 or 2 NSEC records.  A given record can prove 
> multiple things.
> 
> An NSEC3 NXDOMAIN proof has 1, 2, or 3 NSEC3 records. A given record can 
> prove multiple things.
> 
> Mark
> 
>> On 27 Oct 2021, at 16:21, Joey Deng  
>> wrote:
>> 
>> Hi Folks,
>> 
>> I have a very basic question about NSEC record in DNSSEC validation:
>> 
>> How does NSEC record(s) prove the Name Error?
>> 
>> In [RFC 4035 5.4. Authenticated Denial of 
>> Existence](https://datatracker.ietf.org/doc/html/rfc4035#section-5.4), it 
>> says:
>> 
>>>   o  If the requested RR name matches the owner name of an
>>>  authenticated NSEC RR, then the NSEC RR's type bit map field lists
>>>  all RR types present at that owner name, and a resolver can prove
>>>  that the requested RR type does not exist by checking for the RR
>>>  type in the bit map.  If the number of labels in an authenticated
>>>  NSEC RR's owner name equals the Labels field of the covering RRSIG
>>>  RR, then the existence of the NSEC RR proves that wildcard
>>>  expansion could not have been used to match the request.
>>> 
>>>   o  If the requested RR name would appear after an authenticated NSEC
>>>  RR's owner name and before the name listed in that NSEC RR's Next
>>>  Domain Name field according to the canonical DNS name order
>>>  defined in [
>>> RFC4034
>>> ], then no RRsets with the requested name exist
>>>  in the zone.  However, it is possible that a wildcard could be
>>>  used to match the requested RR owner name and type, so proving
>>>  that the requested RRset does not exist also requires proving that
>>>  no possible wildcard RRset exists that could have been used to
>>>  generate a positive response.
>>> 
>>> 
>> 
>> I can understand the first point, because it is an exact name matching. 
>> However, what makes me feel confused is the second one:
>> 
>> If the question name appears in-between the current owner name and the next 
>> owner name of the NSEC record, which means that there is no exact name 
>> matching:
>> We should prove that
>>> no possible wildcard RRset exists that could have been used to generate a 
>>> positive response.
>> 
>> But it does not describe how to prove it,
>> 
>> What are possible wildcard RRsets for a given name?
>> 
>> My understanding about possible wildcard RRsets for a given name are all the 
>> possible sources of synthesis.
>> For example, the possible wildcard RRsets that can be used to answer 
>> question .ietf.org  are:
>> *.ietf.org
>> *.org
>> * (but I think root can never be a wildcard, so this is impossible)
>> 
>> Is my understanding correct?
>> 
>> 
>> 
>> For example, if I send a DNS query for .ietf.org with DO/CD bit set, 
>> there will be two NSEC records returned:
>> 
>> ```
>> $ dig ".ietf.org"  +dnssec +cdflag +tcp @1.1.1.1
>> 
>> ; <<>> DiG 9.10.6 <<>> .ietf.org  +dnssec +cdflag +tcp @1.1.1.1
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34013
>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags: do; udp: 1232
>> ;; QUESTION SECTION:
>> ;.ietf.org.  IN  
>> 
>> ;; AUTHORITY SECTION:
>> ietf.org.1800IN  SOA ns0.amsl.com. glen.amsl.com. 
>> 120537 1800 1800 604800 1800
>> ietf.org.1800IN  RRSIG   SOA 5 2 1800 20221019014909 
>> 20211019005139 40452 ietf.org. 
>> GUaWdfXoPWOjb+/1w5Dtn8VoeemBYXdDIQui365JuuIBkEC4YKFLb+m+ 
>> u8YJ+cbnTzDb768HkTX8AbWaupZVR2FLn2r06hf6YruVi5jRjzExYLQ6 
>> 22Rn8TCvNpNRBZ7fyEcBd9m3aacGr+2iBXgYL9QRXag0tSAAW5oxjI8H 
>> CcQLLylwGKDvQv2sNIQLxZlkYFXa+swBOuFQdT8MmymOKjV1d+p3s+S0 
>> 1HdUb7JAR2vTK/UVib5zfyXGiQcpD6F3XOQNVTY2dgc2ywAqoudANVmz 
>> Rm9rql12MALn2hu5HwrfC0djzXxo6Ry8I0KLmRtAsDoz4ie95Oh1Bnt4 qUhJLA==
>> wwwtest.ietf.org.1800IN  NSECxml2rfc.ietf.org. CNAME RRSIG 
>> NSEC
>> wwwtest.ietf.org.1800IN  RRSIG   NSEC 5 3 1800 20221019015021 
>> 20211019005139 40452 ietf.org. 
>> regwKawm6O9BAaHVyBICHjPlGiwDWoXO8OaqH4zJOOgAglrAMXajbEmx 
>> XHJsbq3DVEVGkU8NSQJxmGYjklyKzmMbIBpt7+RaXKT7WIGd/zRjSlnI 
>> gWSztB6gWTMQq98vQKeFgrt5X8a10p6C36gtJ

Re: [DNSOP] How does NSEC record(s) prove the Name Error?

[Mark Andrews]

For a given QNAME there is exactly one possible wild card name it can match 
depending
on all the other names that exist.  See the rules for when a QNAME matches a 
wildcard.

NXDOMAIN proves that a QNAME does not exist.  The NSEC record that proves that 
a QNAME
does not exist also proves the closest encloser name.  It is this name to which 
you
prepend the * label and it is that name that you prove does not exist.  
Similarly for
NSEC3 except that the closest provable encloser may or may not be the NSEC3 
record
that proves the QNAME does not exist.

An NSEC NXDOMAIN proof has 1 or 2 NSEC records.  A given record can prove 
multiple things.

An NSEC3 NXDOMAIN proof has 1, 2, or 3 NSEC3 records. A given record can prove 
multiple things.

Mark

> On 27 Oct 2021, at 16:21, Joey Deng  
> wrote:
> 
> Hi Folks,
> 
> I have a very basic question about NSEC record in DNSSEC validation:
> 
> How does NSEC record(s) prove the Name Error?
> 
> In [RFC 4035 5.4. Authenticated Denial of 
> Existence](https://datatracker.ietf.org/doc/html/rfc4035#section-5.4), it 
> says:
> 
>>o  If the requested RR name matches the owner name of an
>>   authenticated NSEC RR, then the NSEC RR's type bit map field lists
>>   all RR types present at that owner name, and a resolver can prove
>>   that the requested RR type does not exist by checking for the RR
>>   type in the bit map.  If the number of labels in an authenticated
>>   NSEC RR's owner name equals the Labels field of the covering RRSIG
>>   RR, then the existence of the NSEC RR proves that wildcard
>>   expansion could not have been used to match the request.
>> 
>>o  If the requested RR name would appear after an authenticated NSEC
>>   RR's owner name and before the name listed in that NSEC RR's Next
>>   Domain Name field according to the canonical DNS name order
>>   defined in [
>> RFC4034
>> ], then no RRsets with the requested name exist
>>   in the zone.  However, it is possible that a wildcard could be
>>   used to match the requested RR owner name and type, so proving
>>   that the requested RRset does not exist also requires proving that
>>   no possible wildcard RRset exists that could have been used to
>>   generate a positive response.
>> 
>> 
> 
> I can understand the first point, because it is an exact name matching. 
> However, what makes me feel confused is the second one:
> 
> If the question name appears in-between the current owner name and the next 
> owner name of the NSEC record, which means that there is no exact name 
> matching:
> We should prove that
>> no possible wildcard RRset exists that could have been used to generate a 
>> positive response.
> 
> But it does not describe how to prove it,
> 
> What are possible wildcard RRsets for a given name?
> 
> My understanding about possible wildcard RRsets for a given name are all the 
> possible sources of synthesis.
> For example, the possible wildcard RRsets that can be used to answer question 
> .ietf.org  are:
> *.ietf.org
> *.org
> * (but I think root can never be a wildcard, so this is impossible)
> 
> Is my understanding correct?
> 
> 
> 
> For example, if I send a DNS query for .ietf.org with DO/CD bit set, 
> there will be two NSEC records returned:
> 
> ```
> $ dig ".ietf.org"  +dnssec +cdflag +tcp @1.1.1.1
> 
> ; <<>> DiG 9.10.6 <<>> .ietf.org  +dnssec +cdflag +tcp @1.1.1.1
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34013
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 1232
> ;; QUESTION SECTION:
> ;.ietf.org.   IN  
> 
> ;; AUTHORITY SECTION:
> ietf.org. 1800IN  SOA ns0.amsl.com. glen.amsl.com. 
> 120537 1800 1800 604800 1800
> ietf.org. 1800IN  RRSIG   SOA 5 2 1800 20221019014909 
> 20211019005139 40452 ietf.org. 
> GUaWdfXoPWOjb+/1w5Dtn8VoeemBYXdDIQui365JuuIBkEC4YKFLb+m+ 
> u8YJ+cbnTzDb768HkTX8AbWaupZVR2FLn2r06hf6YruVi5jRjzExYLQ6 
> 22Rn8TCvNpNRBZ7fyEcBd9m3aacGr+2iBXgYL9QRXag0tSAAW5oxjI8H 
> CcQLLylwGKDvQv2sNIQLxZlkYFXa+swBOuFQdT8MmymOKjV1d+p3s+S0 
> 1HdUb7JAR2vTK/UVib5zfyXGiQcpD6F3XOQNVTY2dgc2ywAqoudANVmz 
> Rm9rql12MALn2hu5HwrfC0djzXxo6Ry8I0KLmRtAsDoz4ie95Oh1Bnt4 qUhJLA==
> wwwtest.ietf.org. 1800IN  NSECxml2rfc.ietf.org. CNAME RRSIG 
> NSEC
> wwwtest.ietf.org. 1800IN  RRSIG   NSEC 5 3 1800 20221019015021 
> 20211019005139 40452 ietf.org. 
> regwKawm6O9BAaHVyBICHjPlGiwDWoXO8OaqH4zJOOgAglrAMXajbEmx 
> XHJsbq3DVEVGkU8NSQJxmGYjklyKzmMbIBpt7+RaXKT7WIGd/zRjSlnI 
> gWSztB6gWTMQq98vQKeFgrt5X8a10p6C36gtJh5sGFq8FpiAvKoKuGO8 
> tyWKxux7pEQhlhTySr7ipRe8qmGDpy4H+8bkGqvJ7UJ0f3A366bZyD2Q 
> XLdTG4DUrNWt8wKK0FiL2851PegU8FdQb0IXOlBHNF6qXiKCIhBLbK4W 
> 3O3UYKsNLhYPBYuWNGZQ2mlEsfgUC9dd

[DNSOP] How does NSEC record(s) prove the Name Error?

[Joey Deng]

Hi Folks,

I have a very basic question about NSEC record in DNSSEC validation:

How does NSEC record(s) prove the Name Error?

In [RFC 4035 5.4. Authenticated Denial of 
Existence](https://datatracker.ietf.org/doc/html/rfc4035#section-5.4), it says:

>o  If the requested RR name matches the owner name of an
>   authenticated NSEC RR, then the NSEC RR's type bit map field lists
>   all RR types present at that owner name, and a resolver can prove
>   that the requested RR type does not exist by checking for the RR
>   type in the bit map.  If the number of labels in an authenticated
>   NSEC RR's owner name equals the Labels field of the covering RRSIG
>   RR, then the existence of the NSEC RR proves that wildcard
>   expansion could not have been used to match the request.
> 
>o  If the requested RR name would appear after an authenticated NSEC
>   RR's owner name and before the name listed in that NSEC RR's Next
>   Domain Name field according to the canonical DNS name order
>   defined in [RFC4034 ], 
> then no RRsets with the requested name exist
>   in the zone.  However, it is possible that a wildcard could be
>   used to match the requested RR owner name and type, so proving
>   that the requested RRset does not exist also requires proving that
>   no possible wildcard RRset exists that could have been used to
>   generate a positive response.
> 

I can understand the first point, because it is an exact name matching. 
However, what makes me feel confused is the second one:

If the question name appears in-between the current owner name and the next 
owner name of the NSEC record, which means that there is no exact name matching:
We should prove that
> no possible wildcard RRset exists that could have been used to generate a 
> positive response.

But it does not describe how to prove it,

What are possible wildcard RRsets for a given name?

My understanding about possible wildcard RRsets for a given name are all the 
possible sources of synthesis.
For example, the possible wildcard RRsets that can be used to answer question 
.ietf.org   are:
*.ietf.org 
*.org
* (but I think root can never be a wildcard, so this is impossible)

Is my understanding correct?



For example, if I send a DNS query for .ietf.org  
with DO/CD bit set, there will be two NSEC records returned:

```
$ dig ".ietf.org"  +dnssec +cdflag +tcp @1.1.1.1

; <<>> DiG 9.10.6 <<>> .ietf.org  +dnssec +cdflag +tcp @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34013
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;.ietf.org. IN  

;; AUTHORITY SECTION:
ietf.org.   1800IN  SOA ns0.amsl.com. glen.amsl.com. 
120537 1800 1800 604800 1800
ietf.org.   1800IN  RRSIG   SOA 5 2 1800 20221019014909 
20211019005139 40452 ietf.org. 
GUaWdfXoPWOjb+/1w5Dtn8VoeemBYXdDIQui365JuuIBkEC4YKFLb+m+ 
u8YJ+cbnTzDb768HkTX8AbWaupZVR2FLn2r06hf6YruVi5jRjzExYLQ6 
22Rn8TCvNpNRBZ7fyEcBd9m3aacGr+2iBXgYL9QRXag0tSAAW5oxjI8H 
CcQLLylwGKDvQv2sNIQLxZlkYFXa+swBOuFQdT8MmymOKjV1d+p3s+S0 
1HdUb7JAR2vTK/UVib5zfyXGiQcpD6F3XOQNVTY2dgc2ywAqoudANVmz 
Rm9rql12MALn2hu5HwrfC0djzXxo6Ry8I0KLmRtAsDoz4ie95Oh1Bnt4 qUhJLA==
wwwtest.ietf.org.   1800IN  NSECxml2rfc.ietf.org. CNAME RRSIG 
NSEC
wwwtest.ietf.org.   1800IN  RRSIG   NSEC 5 3 1800 20221019015021 
20211019005139 40452 ietf.org. 
regwKawm6O9BAaHVyBICHjPlGiwDWoXO8OaqH4zJOOgAglrAMXajbEmx 
XHJsbq3DVEVGkU8NSQJxmGYjklyKzmMbIBpt7+RaXKT7WIGd/zRjSlnI 
gWSztB6gWTMQq98vQKeFgrt5X8a10p6C36gtJh5sGFq8FpiAvKoKuGO8 
tyWKxux7pEQhlhTySr7ipRe8qmGDpy4H+8bkGqvJ7UJ0f3A366bZyD2Q 
XLdTG4DUrNWt8wKK0FiL2851PegU8FdQb0IXOlBHNF6qXiKCIhBLbK4W 
3O3UYKsNLhYPBYuWNGZQ2mlEsfgUC9ddBU1trmMEObm3E+1tR/jemSYA uF+S7Q==
ietf.org.   1800IN  NSEC_dmarc.ietf.org. A NS SOA MX 
TXT  RRSIG NSEC DNSKEY SPF
ietf.org.   1800IN  RRSIG   NSEC 5 2 1800 20221019015032 
20211019005139 40452 ietf.org. 
PiCNEGBSBbC/ALNR5ebDwk1wQGMH/l6MtV5ZAGYl9M1wf43NrqHapDlU 
AP2E07FsPIyo9PcWui67PidLgVA4e0rRJbyHK2B92tEeprZbxSOCeIFi 
NWiLl1oCZt+IQCCnFlzJkbwk2MWOVRYxUdQfmWk0QZZZtRr1c/i4VwPU 
MAVqCORkGpc6W6LLiTITLphe7X0NHb7e41n8J06tPh1a6GmRYRJCy41c 
F26Bf6GcEJBpNTvlNuirimbhvjL4Ax+FHBe5MA/Tjp4K1AeUIA0ibBVI 
20o14zUqSsph67/Snz9fdpJ/dsvP9QwTNLTKR6Jxofi/ArWEBEheXsm+ pkZTRA== 
```

The two returned NSEC records are:
wwwtest.ietf.org. -> xml2rfc.ietf.org.
ietf.org. -> _dmarc.ietf.org.

If we follow the steps described by [RFC 4035 5.4. Authenticated Denial of 
Existence](https://datatracker.ietf.org/doc/html/rfc4035#section-5.4)

Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

[Benjamin Kaduk]

On Tue, Oct 26, 2021 at 01:09:00PM -0700, Erik Kline via Datatracker wrote:
> Erik Kline has entered the following ballot position for
> draft-ietf-dnsop-dns-tcp-requirements-13: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/
> 
> 
> 
> --
> COMMENT:
> --
> 
> [abstract vs. S1/S3, question]
> 
> * The abstract says:
> 
>"...strongly
>encourages the operational practice of permitting DNS messages to be
>carried over TCP"
> 
>   while section 1 says:
> 
>"...all DNS resolvers and recursive
>servers MUST support and service both TCP and UDP queries"
> 
>   and section 3 also some MUST text.
> 
>   Should the abstract be updated to say MUST rather than just
>   "strongly encourages", or is there a subtly in here I'm missing?

"require" might be better than "MUST", on the principle that if a given
requirement is stated in more than one place, there is risk of inadvertent
skew between what is actually stated; such skew can cause interoperability
failure or security vulnerabilities if different implementations use the
differing behaviors.

-Ben

> [S4.1, comment]
> 
> * "Resolvers and other DNS clients should be aware that some servers
>might not be reachable over TCP.  For this reason, clients MAY want
>to track and limit the number of TCP connections and connection
>attempts to a single server."
> 
>   I think the same comment could be made about paths to a server from
>   a given network, e.g., in the case of one network filtering TCP/53 for
>   some reason.
> 
>   I'm not sure how to best reword this to add a per-network notion to
>   TCP connection success tracking, but I did want to note that a mobile
>   client's measure of TCP connection success to a single server might
>   vary from network to network.  (for your consideration)
> 
> 
> 

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

[DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

[Erik Kline via Datatracker]

Erik Kline has entered the following ballot position for
draft-ietf-dnsop-dns-tcp-requirements-13: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/



--
COMMENT:
--

[abstract vs. S1/S3, question]

* The abstract says:

   "...strongly
   encourages the operational practice of permitting DNS messages to be
   carried over TCP"

  while section 1 says:

   "...all DNS resolvers and recursive
   servers MUST support and service both TCP and UDP queries"

  and section 3 also some MUST text.

  Should the abstract be updated to say MUST rather than just
  "strongly encourages", or is there a subtly in here I'm missing?

[S4.1, comment]

* "Resolvers and other DNS clients should be aware that some servers
   might not be reachable over TCP.  For this reason, clients MAY want
   to track and limit the number of TCP connections and connection
   attempts to a single server."

  I think the same comment could be made about paths to a server from
  a given network, e.g., in the case of one network filtering TCP/53 for
  some reason.

  I'm not sure how to best reword this to add a per-network notion to
  TCP connection success tracking, but I did want to note that a mobile
  client's measure of TCP connection success to a single server might
  vary from network to network.  (for your consideration)



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

[DNSOP] CFP for DINR 2021 workshop-Nov. 16 for early DNS research

[Wes Hardaker]

We failed to send out a reminder, unfortunately, so we're extending the
submission date to this Friday (29 Oct 2021 11:59:59pm PDT).  As a
reminder: they're expected to be short abstracts about things you wish
to discuss or research you're working on -- IE, it shouldn't be a huge
effort to submit something.

FYI, I'm CCing the new DANCE WG since I think DANCE is a great example
how we're using the DNS in potentially new ways and DANCE participants
may be interested in participating as well.

 Start of forwarded message 
From: Wes Hardaker 
To: dnsop@ietf.org
Cc: John Heidemann 
Subject: CFP for DINR 2021 workshop-Nov. 16 for early DNS research
Date: Mon, 04 Oct 2021 08:41:38 -0700


Greetings, dnsop.  Last year we held a virtual research conference
called "DINR" which we invited dnsop working group participants to and
we'd like to extend that again this year.  Here's the CFP:

-

We would like to invite you to our upcoming virtual workshop on "DNS and 
Internet Naming Research Directions" (DINR). We will be holding this workshop 
virtually over Zoom on 2021-11-16 from 14:00 to 20:00 UTC (that's 07:00-13:00 
PDT on the US west coast).

If you're intereseted in DNS-related topics, infrastructure, have early early 
DNS or naming work to share, or you want to hear about other people's work in 
those areas, we'd love to have you join us. The principle focus of the workshop 
will be on DNS and Internet naming, particularly on open problems, preliminary 
work, and tools that help both.

We're planning for a very interactive day of discussion and short talks. We are 
soliciting short (1 page text + 1 page references) abstracts from people who 
are interested presenting. Abstracts are due soon (October 26), but they're 
short. Co-chairs are John Heidemann and Wes Hardaker (both at USC/ISI).

For details about DINR2021, see https://ant.isi.edu/events/dinr2021/ . It 
builds on last year's DINR2020, see https://ant.isi.edu/events/dinr2020/ what 
we learned.

In addition, we will have a short tutorial about the DIINER experimental DNS 
testbed and datasets on Nov. 18. For details about the tutorial, see 
https://ant.isi.edu/events/dinr2021#tutorial

Please let us know if you're interested, or register your abstract at 
https://ant.isi.edu/dinr2021sub .

-John and Wes

-- 
Wes Hardaker
USC/ISI
 End of forwarded message 

-- 
Wes Hardaker 
My Pictures:   http://photos.capturedonearth.com/

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

[DNSOP] Intdir telechat review of draft-ietf-dnsop-dns-tcp-requirements-13

[Ron Bonica via Datatracker]

Reviewer: Ron Bonica
Review result: Ready

Looks well thought out. No glaring problems.


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

[DNSOP] Fwd: Domain Name System Operations (dnsop) WG Virtual Meeting: 2021-10-26

[Benno Overeinder]

Late reminder for the DNSOP interim meeting this afternoon (in 2 minutes).

-- Benno


 Forwarded Message 
Subject: [DNSOP] Domain Name System Operations (dnsop) WG Virtual 
Meeting: 2021-10-26

Date: Fri, 15 Oct 2021 15:39:40 -0700
From: IESG Secretary 
To: IETF-Announce 
CC: dnsop@ietf.org

The Domain Name System Operations (dnsop) WG will hold
a virtual interim meeting on 2021-10-26 from 14:00 to 15:00 UTC.

Agenda:
# DNS Operations (DNSOP) Working Group
## interim-2021-dnsop-02


### Chairs
* Benno Overeinder [be...@nlnetlabs.nl](be...@nlnetlabs.nl)
* Suzanne Woolf [suzworldw...@gmail.com](suzworldw...@gmail.com)
* Tim Wicinski [tjw.i...@gmail.com](tjw.i...@gmail.com)

### IESG Overlord
* Warren Kumari [war...@kumari.net](war...@kumari.net)

### Document Status
* 
[Github](https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-document-status.md)

* [Datatracker](https://datatracker.ietf.org/wg/dnsop/documents/)

* [Propose 
Slides](https://datatracker.ietf.org/meeting/interim-2021-dnsop-02/session/dnsop)


## Session interim-2021-dnsop-02

* Date: 26 October 2021
* Time: 14:00-15:00 UTC
* MeetEcho: 
[https://meetings.conf.meetecho.com/interim/?short=87d21aa3-6ff9-401f-b176-c3d3bde92ec4](https://meetings.conf.meetecho.com/interim/?short=87d21aa3-6ff9-401f-b176-c3d3bde92ec4)


* Jabber:  [dn...@jabber.ietf.org](dn...@jabber.ietf.org)
* Minutes: 
[https://codimd.ietf.org/notes-ietf-interim-2021-dnsop-02-dnsop](https://codimd.ietf.org/notes-ietf-interim-2021-dnsop-02-dnsop)



## Agenda

### Administrivia

* Agenda Bashing, Blue Sheets, etc,  5 min

### Current Working Group Business

*   DNS Error Reporting
- 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/

- Roy Arends , 50 min
- Chairs Action:

Topics
1. Introduction: state of the I-D
2. Dependency on RFC8914 (Extended DNS Errors): State of 
implementation of EDE in various implementation

3. Issues and potential solutions
- encapsulation of the erroneous domain
- signalling EDE support


Information about remote participation:
https://meetings.conf.meetecho.com/interim/?short=87d21aa3-6ff9-401f-b176-c3d3bde92ec4

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

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

Re: [DNSOP] [Gen-art] Genart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

[Lars Eggert]

Dan, thank you for your review and thank you all for the following discussion. 
I have entered a Discuss ballot for this document based on my own review.

Lars


> On 2021-9-1, at 13:12, Dan Romascanu via Datatracker  wrote:
> 
> Reviewer: Dan Romascanu
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-dnsop-dns-tcp-requirements-12
> Reviewer: Dan Romascanu
> Review Date: 2021-09-01
> IETF LC End Date: 2021-09-03
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> Ready with minor issues and editorial comments.
> 
> This document with intended status BCP updates RFC 1123 encouraging the
> operational practice of permitting DNS messages to be carried over TCP on the
> Internet. It is aligned with the implementation requirements in RFC 7766. It 
> is
> highly significant for the operators community as is the formal requirements
> equivalent for the operational community, encouraging system administrators,
> network engineers, and security staff to ensure DNS over TCP communications
> support is on par with DNS over UDP communications and as it also considers 
> the
> consequences with this form of DNS communication and the potential operational
> issues that can arise when this best current practice is not upheld.
> 
> This document is welcome and clear for anybody who is familiar with the field.
> However, because of the long history it would be useful to think ahead for
> readers that will read and use 5, 10 or 20 years from now. Hence, a few
> editorial comments. I put them in the Nits/editorial category, but they are
> really more than nits, so I recommend that the authors consider them, before
> the document gets to the RFC Editor.
> 
> Major issues:
> 
> Minor issues:
> 
> 1. In Section 4.1:
> 
>> DNS clients MAY also enable TFO when possible.
> 
> Maybe I do not fully understand the intent here, but 'MAY ... when possible'
> sounds like a SHOULD to me.
> 
> 2.In Section 4.2
> 
>>  DNS server software SHOULD provide a configurable limit on the total
>   number of established TCP connections.  If the limit is reached, the
>   application is expected to either close existing (idle) connections
>   or refuse new connections.  Operators SHOULD ensure the limit is
>   configured appropriately for their particular situation.
> 
>   DNS server software MAY provide a configurable limit on the number of
>   established connections per source IP address or subnet.  This can be
>   used to ensure that a single or small set of users cannot consume all
>   TCP resources and deny service to other users.  Operators SHOULD
>   ensure this limit is configured appropriately, based on their number
>   of diversity of users.
> 
> The lack of recommendations about how these limits should be set would leave
> less experienced operators in the dark. There is not even a sentence like 
> 'This
> document does not offer advice on particular values for such a limit' as for
> other parameters in the same section. From an operators point of view I would
> prefer a recommendation or one or more examples of how these limits can be set
> in real life cases.
> 
> Nits/editorial comments:
> 
> 1. Sections in the document that are obviously for informational pursposes
> should be clearly marked so (like 'This section is included for informational
> purposes only'). For example Section 2.
> 
> 2. In Section 3:
> 
> Regarding the choice of limiting the resources a server devotes to
>   queries, Section 6.1.3.2 in [RFC1123] also says:
> 
>  "A name server MAY limit the resources it devotes to TCP queries,
>  but it SHOULD NOT refuse to service a TCP query just because it
>  would have succeeded with UDP."
> 
>   This requirement is hereby updated: A name server MAY limit the
>   resources it devotes to queries, but it MUST NOT refuse to service a
>   query just because it would have succeeded with another transport
>   protocol.
> 
> Similar alignment of the old and new text is desirable. Even using the OLD /
> NEW format.
> 
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

[DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-dnsop-dns-tcp-requirements-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/



--
DISCUSS:
--

Section 4.2. , paragraph 3, discuss:
>Since host memory for TCP state is a finite resource, DNS clients and
>servers MUST actively manage their connections.  Applications that do
>not actively manage their connections can encounter resource
>exhaustion leading to denial of service.  For DNS, as in other
>protocols, there is a tradeoff between keeping connections open for
>potential future use and the need to free up resources for new
>connections that will arrive.

For it to contain a MUST-level requirement, this section needs to give a lot
more concrete guidance on what it means to "actively" manage connections. Most
operating systems by default impose some application limits that usually
effectively prevent DOS or other resource exhaustion issues. Is the intent here
that DNS implementations need to do more? If so, what?


--
COMMENT:
--

Section 2.4. , paragraph 1, comment:
> 2.4.  Fragmentation and Truncation

Fragmentation and IP fragments getting dropped is one reason for needing more
retries with EDNS(0). But IIRC, a larger contributing factor is that EDNS(0)
doesn't detect or recover from loss of any UDP packets making up the overall
message. That means that a normal packet loss (due to congestion or other
reasons) amplifies into loss of the entire DNS message.

Section 3. , paragraph 1, comment:
> 3.  DNS over TCP Requirements

While the history preceding this section is interesting for context, I think
moving this section up would increase readability significantly.

Section 4.2. , paragraph 3, comment:
>DNS server software SHOULD provide a configurable limit on the total
>number of established TCP connections.  If the limit is reached, the
>application is expected to either close existing (idle) connections
>or refuse new connections.  Operators SHOULD ensure the limit is
>configured appropriately for their particular situation.

Again, the OS generally already imposes limits. Why recommend that DNS
implementations self-impose other (lower?) limits?

Section 4.2. , paragraph 3, comment:
>DNS server software MAY provide a configurable limit on the number of
>established connections per source IP address or subnet.  This can be
>used to ensure that a single or small set of users cannot consume all
>TCP resources and deny service to other users.  Operators SHOULD
>ensure this limit is configured appropriately, based on their number
>and diversity of users.

This limit only begins to establish fairness once the overall number of
permitted connections is reached. Until that point, it possibly limits client
performance without any benefit.

Section 4.2. , paragraph 3, comment:
>DNS server software SHOULD provide a configurable timeout for idle
>TCP connections.  For very busy name servers this might be set to a
>low value, such as a few seconds.  For less busy servers it might be
>set to a higher value, such as tens of seconds.

Ditto.

Section 4.2. , paragraph 3, comment:
>DNS server software MAY provide a configurable limit on the number of
>transactions per TCP connection.

What does that limit protect against?

Section 4.2. , paragraph 2, comment:
>Similarly, DNS server software MAY provide a configurable limit on
>the total duration of a TCP connection.

What does that limit protect against?

Section 4.5. , paragraph 3, comment:
>Most open source DNS server implementations provide a configurable
>limit on the total number of established connections.  Default values
>range from 20 to 150.  In most cases, where the majority of queries
>take place over UDP, 150 is a reasonable limit.  For services or
>environments where most queries take place over TCP or TLS, 5000 is a
>more appropriate limit.

20-150 is orders of magnitude less than I expected. Even 5000 seems very low,
given the capabilities of even low-end servers.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "master"; alternatives might be "active", "central

[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

[Peter Thomassen]

Dear DNSOP and DNSSEC bootstrapping aficionados,

This draft introduces automatic bootstrapping of DNSSEC delegations. It uses an 
in-band method for DNS operators to publish information about the zones they 
host, per-zone and with authentication. With this protocol, DS provisioning can 
happen securely and without delay.

We requested a slot at IETF 112 to present the draft, and it would be great to 
have some discussions about it then. We'd also like to work towards adoption in 
the WG if there is interest.

There are no technical changes from the previous version -01. Updates are 
exclusively on clarity, framing (as an RFC 8078 authentication method instead 
of a separate protocol), and otherwise editorial.

Thanks,
Peter


 Forwarded Message 
Subject: New Version Notification for 
draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
Date: Mon, 25 Oct 2021 16:56:41 -0700
From: internet-dra...@ietf.org
To: Nils Wisiol , Peter Thomassen 


A new version of I-D, draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
has been successfully submitted by Peter Thomassen and posted to the
IETF repository.

Name:   draft-thomassen-dnsop-dnssec-bootstrapping
Revision:   02
Title:  Automatic DNSSEC Bootstrapping using Authenticated Signals from 
the Zone's Operator
Document date:  2021-10-25
Group:  Individual Submission
Pages:  15
URL:
https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/
Html:   
https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-02.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-dnssec-bootstrapping
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-thomassen-dnsop-dnssec-bootstrapping-02

Abstract:
   This document introduces an in-band method for DNS operators to
   publish arbitrary information about the zones they are authoritative
   for, in an authenticated fashion and on a per-zone basis.  The
   mechanism allows managed DNS operators to securely announce DNSSEC
   key parameters for zones under their management, including for zones
   that are not currently securely delegated.

   Whenever DS records are absent for a zone's delegation, this signal
   enables the parent's registry or registrar to cryptographically
   validate the CDS/CDNSKEY records found at the child's apex.  The
   parent can then provision DS records for the delegation without
   resorting to out-of-band validation or weaker types of cross-checks
   such as "Accept after Delay" ([RFC8078]).

   [ Ed note: Text inside square brackets ([]) is additional background
   information, answers to frequently asked questions, general musings,
   etc.  They will be removed before publication.  This document is
   being collaborated on at https://github.com/desec-io/draft-thomassen-
   dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft-
   thomassen-dnsop-dnssec-bootstrapping/).  The most recent version of
   the document, open issues, etc. should all be available there.  The
   authors gratefully accept pull requests. ]

  



The IETF Secretariat


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

[DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

[Robert Wilton via Datatracker]

Robert Wilton has entered the following ballot position for
draft-ietf-dnsop-dns-tcp-requirements-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/



--
COMMENT:
--

Thank you for a well written and informative document.

Rob



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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

[Vladimír Čunát]

On 26/10/2021 12.10, Roy Arends wrote:
I have a slide ready to discuss the issue that DNS Query Name 
Minimization brings… A minimised query can’t be distinguished from a 
full query, so it may not be clear what name caused an issue. The 
current thinking (but will be discussed later today) is to start with 
_er as well. That way, the erroneous qname is “encapsulated” by _er 
labels.


I assumed you can distinguish those quite reliably thanks to QTYPE=NULL 
which I haven't heard of for minimization so far.



If, at any point, auth servers offer encrypted transport, a faulty 
query should not be replicated in clear text.


I certainly agree with that, but then the text should be clarified that 
the encryption refers to auth side and not client side.  As it is now, 
it refers to RFC numbers that explicitly consider client side only, so I 
assumed that's what was meant.



To make the error-reporting work, you need noticeable commitment to 
deploy on both sides, because otherwise the perceived benefit from 
deploying might be quite low.  On resolver side, I believe that it 
will be quite rare for operators to tweak such highly technical 
options[*].  So if this MUST be off by default, you at least need 
commitment from some significant operators - say, I'm not even sure 
if Quad9 by themselves would suffice to bootstrap this.


I'm inclined to remove that text alltogether. Resolver implementations 
either do this by default, or not. No need to pedantically require 
config first and default off. Additionally, there is an issue where 
resolvers need to retry without the option when auth servers can’t 
handle the option… I’m inclined, just like Extended DNS errors itself, 
to have authoritative servers just set the option, unsolicited. It 
hasn’t caused any issue for extended DNS errors yet… but lets have 
that discussion this afternoon.


I'm not sure about this reasoning, but anyway - I'd be also inclined to 
remove that paragraph, and we'll see what opinions appear during the 
call and afterwards.


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

[Roy Arends]

Hi Petr,

> On 26 Oct 2021, at 11:02, Petr Špaček  wrote:
> 
> On 26. 10. 21 11:14, Vladimír Čunát wrote:
>> Hello.
>>> DNS Error reporting SHOULD be done using DNS Query Name Minimization
>>> [RFC7816  ] to improve 
>>> privacy.
>> It's just a detail and "SHOULD" isn't strong, but I expect it might be worth 
>> elaborating here.  The name used in the reporting query adds a few labels to 
>> the failing QNAME and the whole reporting agent domain, so together that's 
>> lots of labels, and expending a packet for *each* of those labels would seem 
>> quite wasteful.  Perhaps we could agree on some boundary (e.g. around the 
>> "_er" label) under which minimization isn't recommended anymore, and put 
>> that as a suggestion into the text?
> 
> We need to consider & document interaction between Query Name Minimization 
> and NXDOMAIN processing as per RFC 8020. If minimization & RFC 8020 are on 
> default then it might very easily happen that most of _er subtrees (which are 
> presumably empty) will be cut out by cache and nothing will be sent out when 
> an error is detected.

Ack, lets discuss this afternoon.

> All in all, I think the text should warn about this interaction instead of 
> mandating query name minimization on/off.

Yes, one way of dealing with it is to have the reporting agent server (where 
the reports go), deploy a wildcard under their reporting agent zone.

Additionally, I think we should never require additional complexity to query 
name minimisation. The issue caused by query name minimisation can be solved by 
prepending an _er label, so the erroneous qname is encapsulated by _er’s.

> 
> 
>>> The reporting resolver MUST NOT report about queries and responses
>>> from an encrypted channel (such as DNS over TLS [RFC7858  
>>> ] and DNS
>>> over HTTPS [RFC8484  ]).
>> I believe this needs some explanation at least (in the text, ideally).  The 
>> failing query triggering the report is towards an authoritative server (i.e. 
>> unencrypted), and the reporting queries do not really carry more 
>> information.  They may travel by a different path, but on the whole I can't 
>> see significant motivation for the paragraph, especially in "MUST NOT" form.
> 
> I will use stronger language: This is under-specified to the point where it 
> starts causing confusion.

I agree.

> * Is the paragraph considering channel from stub to resolver?

No.

> * From resolver to auth?

Yes. 

> * Both?

No.

> * What to do with queries executed by resolver on its own (prefetch)?

They’re not special.

> * What if multiple clients are waiting for the same query, using different 
> channels? (query deduplication in the resolver)
> etc.

Assuming you’re referring to stubs (not sure if you do, apologies): The 
reporting is independent of the client. i.e. the report will not go to clients, 
but to authoritative servers.

> 
> I think this should go to Security Considerations section and be left for 
> implementations to decide. MUST mandate is way too strong and does not 
> accommodate implementation- and deployment- specific circumstances.

Ack.

> 
> 
>>> This method MUST NOT
>>> be deployed by default on reporting resolvers and authoritative
>>> servers without requiring an explicit configuration element.
>> I'm not so sure about forbidding this on resolvers so strongly, but 
>> certainly OK if the WG prefers it that way.  (On auths it wouldn't make 
>> sense to enable by default; what agent?)  If the error-reporting is meant 
>> really seriously, I'd rather improve the mechanism to never induce 
>> significant overhead and encourage enabling it by default on resolvers (at 
>> some point).
>> To make the error-reporting work, you need noticeable commitment to deploy 
>> on both sides, because otherwise the perceived benefit from deploying might 
>> be quite low.  On resolver side, I believe that it will be quite rare for 
>> operators to tweak such highly technical options[*].  So if this MUST be off 
>> by default, you at least need commitment from some significant operators - 
>> say, I'm not even sure if Quad9 by themselves would suffice to bootstrap 
>> this.
> 
> I agree. Mandating "disabled by default" configuration on _resolvers_ sounds 
> like a way to get to a working-but-never-deployed protocol.

I agree.

Roy

> 
> -- 
> Petr Špaček  @  ISC
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

[Vladimír Čunát]

On 26/10/2021 12.02, Petr Špaček wrote:
We need to consider & document interaction between Query Name 
Minimization and NXDOMAIN processing as per RFC 8020. If minimization 
& RFC 8020 are on default then it might very easily happen that most 
of _er subtrees (which are presumably empty) will be cut out by cache 
and nothing will be sent out when an error is detected. 


I believe that's already sufficiently addressed in section 4.1. Managing 
Caching Optimizations



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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

[Roy Arends]

> On 26 Oct 2021, at 10:14, Vladimír Čunát  wrote:
> 
> Hello.
> 
> 
>> DNS Error reporting SHOULD be done using DNS Query Name Minimization
>> [RFC7816 ] to improve privacy.
> 
> It's just a detail and "SHOULD" isn't strong, but I expect it might be worth 
> elaborating here.  The name used in the reporting query adds a few labels to 
> the failing QNAME and the whole reporting agent domain, so together that's 
> lots of labels, and expending a packet for *each* of those labels would seem 
> quite wasteful.  Perhaps we could agree on some boundary (e.g. around the 
> "_er" label) under which minimization isn't recommended anymore, and put that 
> as a suggestion into the text?
> 
> 

I have a slide ready to discuss the issue that DNS Query Name Minimization 
brings… A minimised query can’t be distinguished from a full query, so it may 
not be clear what name caused an issue. The current thinking (but will be 
discussed later today) is to start with _er as well. That way, the erroneous 
qname is “encapsulated” by _er labels.
>> The reporting resolver MUST NOT report about queries and responses
>> from an encrypted channel (such as DNS over TLS [RFC7858 
>> ] and DNS
>> over HTTPS [RFC8484 ]).
> I believe this needs some explanation at least (in the text, ideally).  The 
> failing query triggering the report is towards an authoritative server (i.e. 
> unencrypted), and the reporting queries do not really carry more information. 
>  They may travel by a different path, but on the whole I can't see 
> significant motivation for the paragraph, especially in "MUST NOT" form.
> 
If, at any point, auth servers offer encrypted transport, a faulty query should 
not be replicated in clear text.
>> This method MUST NOT
>> be deployed by default on reporting resolvers and authoritative
>> servers without requiring an explicit configuration element.
> I'm not so sure about forbidding this on resolvers so strongly, but certainly 
> OK if the WG prefers it that way.  (On auths it wouldn't make sense to enable 
> by default; what agent?)  If the error-reporting is meant really seriously, 
> I'd rather improve the mechanism to never induce significant overhead and 
> encourage enabling it by default on resolvers (at some point).

Ack. 
> To make the error-reporting work, you need noticeable commitment to deploy on 
> both sides, because otherwise the perceived benefit from deploying might be 
> quite low.  On resolver side, I believe that it will be quite rare for 
> operators to tweak such highly technical options[*].  So if this MUST be off 
> by default, you at least need commitment from some significant operators - 
> say, I'm not even sure if Quad9 by themselves would suffice to bootstrap this.
> 
I'm inclined to remove that text alltogether. Resolver implementations either 
do this by default, or not. No need to pedantically require config first and 
default off. Additionally, there is an issue where resolvers need to retry 
without the option when auth servers can’t handle the option… I’m inclined, 
just like Extended DNS errors itself, to have authoritative servers just set 
the option, unsolicited. It hasn’t caused any issue for extended DNS errors 
yet… but lets have that discussion this afternoon.

Roy
> 
> --Vladimir | knot-resolver.cz
> 
> - - -
> [*] and I support that.  I'm a big proponent of defaults.  They should work 
> as good as possible, and deployments should operate as close to defaults as 
> possible.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

[Petr Špaček]

On 26. 10. 21 11:14, Vladimír Čunát wrote:

Hello.


DNS Error reporting SHOULD be done using DNS Query Name Minimization
[RFC7816  ] to improve privacy.


It's just a detail and "SHOULD" isn't strong, but I expect it might be 
worth elaborating here.  The name used in the reporting query adds a few 
labels to the failing QNAME and the whole reporting agent domain, so 
together that's lots of labels, and expending a packet for *each* of 
those labels would seem quite wasteful.  Perhaps we could agree on some 
boundary (e.g. around the "_er" label) under which minimization isn't 
recommended anymore, and put that as a suggestion into the text?


We need to consider & document interaction between Query Name 
Minimization and NXDOMAIN processing as per RFC 8020. If minimization & 
RFC 8020 are on default then it might very easily happen that most of 
_er subtrees (which are presumably empty) will be cut out by cache and 
nothing will be sent out when an error is detected.


All in all, I think the text should warn about this interaction instead 
of mandating query name minimization on/off.




The reporting resolver MUST NOT report about queries and responses
from an encrypted channel (such as DNS over TLS [RFC7858  
] and DNS
over HTTPS [RFC8484  ]).


I believe this needs some explanation at least (in the text, ideally).  
The failing query triggering the report is towards an authoritative 
server (i.e. unencrypted), and the reporting queries do not really carry 
more information.  They may travel by a different path, but on the whole 
I can't see significant motivation for the paragraph, especially in 
"MUST NOT" form.


I will use stronger language: This is under-specified to the point where 
it starts causing confusion.

* Is the paragraph considering channel from stub to resolver?
* From resolver to auth?
* Both?
* What to do with queries executed by resolver on its own (prefetch)?
* What if multiple clients are waiting for the same query, using 
different channels? (query deduplication in the resolver)

etc.

I think this should go to Security Considerations section and be left 
for implementations to decide. MUST mandate is way too strong and does 
not accommodate implementation- and deployment- specific circumstances.




This method MUST NOT
be deployed by default on reporting resolvers and authoritative
servers without requiring an explicit configuration element.


I'm not so sure about forbidding this on resolvers so strongly, but 
certainly OK if the WG prefers it that way.  (On auths it wouldn't make 
sense to enable by default; what agent?)  If the error-reporting is 
meant really seriously, I'd rather improve the mechanism to never induce 
significant overhead and encourage enabling it by default on resolvers 
(at some point).


To make the error-reporting work, you need noticeable commitment to 
deploy on both sides, because otherwise the perceived benefit from 
deploying might be quite low.  On resolver side, I believe that it will 
be quite rare for operators to tweak such highly technical options[*].  
So if this MUST be off by default, you at least need commitment from 
some significant operators - say, I'm not even sure if Quad9 by 
themselves would suffice to bootstrap this.


I agree. Mandating "disabled by default" configuration on _resolvers_ 
sounds like a way to get to a working-but-never-deployed protocol.


--
Petr Špaček  @  ISC

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

[Vladimír Čunát]

Hello.


DNS Error reporting SHOULD be done using DNS Query Name Minimization
[RFC7816  ] to improve privacy.


It's just a detail and "SHOULD" isn't strong, but I expect it might be 
worth elaborating here.  The name used in the reporting query adds a few 
labels to the failing QNAME and the whole reporting agent domain, so 
together that's lots of labels, and expending a packet for *each* of 
those labels would seem quite wasteful.  Perhaps we could agree on some 
boundary (e.g. around the "_er" label) under which minimization isn't 
recommended anymore, and put that as a suggestion into the text?



The reporting resolver MUST NOT report about queries and responses
from an encrypted channel (such as DNS over TLS [RFC7858  
] and DNS
over HTTPS [RFC8484  ]).


I believe this needs some explanation at least (in the text, ideally).  
The failing query triggering the report is towards an authoritative 
server (i.e. unencrypted), and the reporting queries do not really carry 
more information.  They may travel by a different path, but on the whole 
I can't see significant motivation for the paragraph, especially in 
"MUST NOT" form.



This method MUST NOT
be deployed by default on reporting resolvers and authoritative
servers without requiring an explicit configuration element.


I'm not so sure about forbidding this on resolvers so strongly, but 
certainly OK if the WG prefers it that way.  (On auths it wouldn't make 
sense to enable by default; what agent?)  If the error-reporting is 
meant really seriously, I'd rather improve the mechanism to never induce 
significant overhead and encourage enabling it by default on resolvers 
(at some point).


To make the error-reporting work, you need noticeable commitment to 
deploy on both sides, because otherwise the perceived benefit from 
deploying might be quite low.  On resolver side, I believe that it will 
be quite rare for operators to tweak such highly technical options[*].  
So if this MUST be off by default, you at least need commitment from 
some significant operators - say, I'm not even sure if Quad9 by 
themselves would suffice to bootstrap this.



--Vladimir | knot-resolver.cz

- - -
[*] and I support that.  I'm a big proponent of defaults.  They should 
work as good as possible, and deployments should operate as close to 
defaults as possible.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-04.txt

[Willem Toorop]

Dear dnsop,

This draft describes a mechanism for automatic provisioning of zones
among authoritative name servers by way of distributing a catalog of
those zones encoded in a regular DNS zone.

This version of the draft is the result of thorough review and
discussion with the goal of getting it in shape for publication as RFC.

Besides rephrasing and reordering, predictability of owner names
("member labels") in the catalog zone is now left out of consideration.
As a result, the `epoch` property (a property specific for predictable
member labels) was removed.

This version of the draft has catalog zones specified to the best of our
ability and we request you to review it thoroughly with the documents
readiness for WGLC in mind.

Op 25-10-2021 om 21:37 schreef internet-dra...@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
> Title   : DNS Catalog Zones
> Authors : Peter van Dijk
>   Libor Peltan
>   Ondrej Sury
>   Willem Toorop
>   Leo Vandewoestijne
>   Peter Thomassen
>   Filename: draft-ietf-dnsop-dns-catalog-zones-04.txt
>   Pages   : 19
>   Date: 2021-10-25
> 
> Abstract:
>This document describes a method for automatic DNS zone provisioning
>among DNS primary and secondary nameservers by storing and
>transferring the catalog of zones to be provisioned as one or more
>regular DNS zones.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-04.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-catalog-zones-04
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

[Matthijs Mekking]

Hi,

On 26-10-2021 01:56, Roy Arends wrote:



On 20 Oct 2021, at 14:14, libor.peltan 
wrote:

Hi all,

although for me, as an implementer of an auth server, it's not too
important, I'd like to ask for clarification regarding the foreseen
reporting domain(s) setup in the (usual) case of many secondary
auth servers.

The draft says: "Each authoritative server SHOULD be configured
with a unique reporting agent domain."

I see two possible error situations:

1) the zone itself is wrongly signed, so all secondaries share the
same error 2) some of the secondaries respond wrongly from
correctly signed zone, so the error is slave-specific

IMHO the case (2) is far less common. And the case (1) doesn't
require per-secondary reporting domain, just per-zone.

Is it really recommended (in capitals) that the zone operator
prepares extra reporting domain for each secondary around the world
(it can be hundreds)?


If you have outsourced your secondaries to a company that has hundreds 
of secondaries I guess you can also set up a reporting agent domain like 
"company1.reporting-agent.example". and 
"company2.reporting-agent.example". It won't tell you exactly which 
server caused the problem, but at least it gives you some idea without 
having to set up hundreds of domains.


But I am also not convinced that the recommendation needs to be in capitals.



The domain owner may have contracts with more than one operator. The
operator may operate many authoritative servers, which not all serve
the same set of zones.

If the reporting agent domain is unique, the erroneous server can be
pinpointed faster. If all auth servers for a domain have the same
reporting agent domain, the reporting agent knows there is an error,
just doesn’t know where.


If so, it can cause a disclosure about which secondary the answer
is comming from, dunno if some zone operators are not willing to
conceal this.


In that case, the zone operator doesn’t have to deploy EDE reporting,
right?


The zone operator may still be interested in knowing about resolving 
issues. And DNS error reporting would still work if you have just a 
single reporting agent domain.



Matthijs




Roy



Thanks!

Libor

Dne 27. 04. 21 v 16:47 internet-dra...@ietf.org napsal(a):

A New Internet-Draft is available from the on-line
Internet-Drafts directories. This draft is a work item of the
Domain Name System Operations WG of the IETF.

Title   : DNS Error Reporting Authors : Roy
Arends Matt Larson Filename:
draft-ietf-dnsop-dns-error-reporting-00.txt Pages   : 12 
Date: 2021-04-27


Abstract: DNS Error Reporting is a lightweight error reporting
mechanism that provides the operator of an authoritative server
with reports on DNS resource records that fail to resolve or
validate, that a Domain Owner or DNS Hosting organization can use
to improve domain hosting. The reports are based on Extended DNS
Errors [RFC8914].

When a domain name fails to resolve or validate due to a 
misconfiguration or an attack, the operator of the authoritative 
server may be unaware of this.  To mitigate this lack of

feedback, this document describes a method for a validating
recursive resolver to automatically signal an error to an agent
specified by the authoritative server.  DNS Error Reporting uses
the DNS to report errors.


The IETF datatracker status page for this draft is: 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/





There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-dnsop-dns-error-reporting-00



https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-00



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.

Internet-Drafts are also available by anonymous FTP at: 
ftp://ftp.ietf.org/internet-drafts/



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


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


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




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