Re: [DNSOP] Updated: Compact Denial of Existence

[Shumon Huque]

On Tue, Mar 28, 2023 at 10:01 AM Viktor Dukhovni 
wrote:

>
> On Wed, Mar 15, 2023 at 08:48:29AM -0400, Shumon Huque wrote:
>
> > So, if a resolver sends EDNS CompactAnswersOK signal to an authority
> > server, which returns a NODATA+NXNAME proof + RCODE=3 response, then the
> > resolver would have to intelligently manage that answer in its cache.
>
> Adding EDNS0 signals here is much too complex.  The DO bit is
> sufficient.  A validating resolver that supports the proposed
> specification can infer NXDOMAIN from the form of the NSEC RR.
> If it does not support the proposed specification, then the presented
> DoE proof is NODATA, and that must be sent.  So just always send NODATA
> (NOERROR) when the DO bit is set in the query.
>
> The clients that see the restored NXDOMAIN will be the stub resolvers
> that don't do validation, and sit behind a local validating forwarder.
>

The issue is that there are a lot of security, diagnostic, and traffic
characterization tools that examine the RCODE field and want that to be
accurate even for DO=1 queries -- not just a converted RCODE by a NXNAME
recognizing resolver, but in the response from the authorities too. In
theory those could be enhanced to recognize NXNAME, but I think there is a
lot of pessimism that would happen anytime soon, since many of them are
generally not developed by DNS experts, and older deployed code generally
hangs around forever. I recently spoke to the vendor of one such tool, and
suggested that they need to look deeper in the packet to get the info out
of the NSEC bitmap, but they seemed pessimistic that they could do that at
wire speed with high volume DNS traffic. Maybe this problem is too complex
to solve, but let's at least talk through the details first before
disbanding it.

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

Re: [DNSOP] Updated: Compact Denial of Existence

[Shumon Huque]

On Tue, Mar 28, 2023 at 10:01 AM Viktor Dukhovni 
wrote:

> [ Multi-response to four upthread messages. ]
>
> ---
>
> On Fri, Mar 03, 2023 at 06:23:11PM -0500, Shumon Huque wrote:
>
> > Thanks for your comments. We've posted an updated draft (-01):
> >
> >
> https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01
>
> [ Copied from today's dns-operations post on the same general topic. ]
>
> A possibly inconvenient question, just to make sure we're not ignoring
> the obvious sceptical position:
>
> * How compelling is compact DoE?
>
> The reason to ask is that both the original and now modified protocols
> involve non-trivial complexity, and would likely require resolvers to
> respond differently to queries with the DO bit set (pass them the NODATA
> "truth" along with the NXNAME signal) vs. queries that don't request
> validated answers (pass them the inferred NXDOMAIN).
>
> The savings vs. actual by-the-book NSEC responses appear to be a 2x
> reduction in the number of signatures to compute (the SOA RRSIG is
>
>
> presumably easily cached) and a 1.5x reduction in the number of
> signatures to transmit (SOA + 1 NSEC, vs. SOA + 2 NSEC).
>
> Do the CPU and packet size reductions justify the additional protocol
> complexity?
>

I'll also regurgitate my message here from the dns-operations@ list thread:

That's a reasonable question, and perhaps best directed to the originators
of the scheme at Cloudflare. I don't know if there have been any
measurement studies or analyses of the cost benefits vs by-the-book DNSSEC.
There are currently 3 large commercial DNS providers that have had it
deployed for a while now, so I suspect that it is here to stay.

Note that one other provider (UltraDNS) does support traditional NSEC White
"Lies" that give by-the-book DNSSEC proofs for NXDOMAIN, so apparently they
are bearing the additional costs just fine.

One other point -- without the additional rcode substitution schemes under
discussion, Compact Answers can cause additional work for authority
servers, since NODATA responses may lead to follow-on queries by DNS client
applications (e.g. the common  followed by A pattern; note: most DNS
resolution API functions don't do happy eyeballs today). So, the
per-response crypto & size reductions need to also be weighed against the
cost of these additional queries.

> But the main change is to move from the ENT distinguisher RR type
> > to an explicit one for NXDOMAIN (with mnemonic NXNAME).


> The draft fails to explain how queries for the proposed new RRtype are
> to be handled by authoritative servers and resolvers.
>

Since this is a "meta" type for which we don't expect normal applications
to ever issue queries, its behavior could be undefined I suppose. But it's
probably better to explicitly say what the response should be. Maybe NODATA
for an existing name, and NODATA + NXNAME NSEC bitmap sentinel for
non-existent names? Sending FORMERR or SERVFAIL might invoke unwanted
additional follow-on queries by resolvers (or their downstreams), although
I suppose SERVFAIL + a new EDE value might be a possibility.

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

Re: [DNSOP] Meet the Root Zone Algorithm Rollover Design Team @ IETF 116

[Jakob Schlyter]

On 2023-03-28 at 10:14, Mark Andrews wrote:

> Is this JST?

Yes, 13:00 – 14:00 JST.


jakob

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

Re: [DNSOP] Meet the Root Zone Algorithm Rollover Design Team @ IETF 116

[Ralf Weber]

Moin!

On 28 Mar 2023, at 10:14, Mark Andrews wrote:

> Is this JST?

Yes. Currently UTC+9. So it is 04:00 UTC

So long
-Ralf

>
>> On 28 Mar 2023, at 11:15, James Mitchell  wrote:
>>
>> Hello,
>>  The Root Zone Algorithm Rollover Study Design Team is hosting a public 
>> session at IETF 116 and invites you to join.
>>  Date: 29 March, 13:00 – 14:00
>> Room: G301
>> Remote: 
>> https://icann.zoom.us/j/94974160556?pwd=eUdOVUFUWi9yZ3FtVVFrbTFJWDFmUT09 
>> [icann.zoom.us]
>>  The team's goal is to develop a plan for changing the cryptographic 
>> algorithm used for the DNS root key signing and zone signing keys. The team 
>> has been meeting since early 2023 and many members are here at the IETF to 
>> progress this work. We’ll share an update on the progress and challenges 
>> that we face. We look forward to your questions and insight.
>>  Don’t worry if you are unable to make the session; the plan will be put to 
>> public comment. Follow the ksk-rollover mailing list for updates and 
>> announcements.
>>  Thanks,
>> James Mitchell
>> IANA
>>  ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>
> ___
> 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] Meet the Root Zone Algorithm Rollover Design Team @ IETF 116

[Mark Andrews]

Is this JST?

> On 28 Mar 2023, at 11:15, James Mitchell  wrote:
> 
> Hello,
>  The Root Zone Algorithm Rollover Study Design Team is hosting a public 
> session at IETF 116 and invites you to join.
>  Date: 29 March, 13:00 – 14:00
> Room: G301
> Remote: 
> https://icann.zoom.us/j/94974160556?pwd=eUdOVUFUWi9yZ3FtVVFrbTFJWDFmUT09 
> [icann.zoom.us]
>  The team's goal is to develop a plan for changing the cryptographic 
> algorithm used for the DNS root key signing and zone signing keys. The team 
> has been meeting since early 2023 and many members are here at the IETF to 
> progress this work. We’ll share an update on the progress and challenges that 
> we face. We look forward to your questions and insight.
>  Don’t worry if you are unable to make the session; the plan will be put to 
> public comment. Follow the ksk-rollover mailing list for updates and 
> announcements.
>  Thanks,
> James Mitchell
> IANA
>  ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Shumon Huque]

On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni 
wrote:

> On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
> > The cyclic dependency based sibling glue (Section 2.3) is arguably
> > a bit of a corner case, and in past discussions some folks have expressed
> > the view that we shouldn't make accommodations to support it. I
> > think I can agree with that, but there were opposing views that we also
> > shouldn't break configurations that currently work. So it was left in.
>
> Can we at least state that domains with cyclic dependencies are a bad
> idea, and may not be supported by all resolvers.  In other words, that
> the domain owner can't **rely** on the sibling glue recommended to be
> sent in this draft to save the day.
>
> My strong preference is still to delete all reference in the draft to
> cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
> sibling glue primarily as a performance optimisation, and secondarily
> as a last resort when the nameserver IP addresses are wrong or gone
> from the authoritative zone (another bad practice).
>

Viktor - I've so far not seen many other people speak up in support of your
position. I suspect this is because this draft was discussed to death many
months ago during long discussion threads on the list, and there is likely
already rough consensus for the current content. Personally, I would be ok
with adding a statement that configurations involving cyclic dependencies
are not recommended, but others will likely have to also speak up in support
of this too.

What should really happen is that broken sibling glue should be
> regularly purged from public suffix registries (probably requires
> gaining support for this in the RRR community more than IETF), and only
> then does the remaining valid sibling glue become more of a help than a
> hindrance.


Yes, I agree that this is the real area of work that could improve the
situation,
but probably outside of the scope of what the IETF can influence. If you
want
to organize an effort to do something about this in the ICANN/RRR community,
I suspect you might be able to recruit some of us into helping.

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

Re: [DNSOP] Updated: Compact Denial of Existence

[Viktor Dukhovni]

[ Multi-response to four upthread messages. ]

---

On Fri, Mar 03, 2023 at 06:23:11PM -0500, Shumon Huque wrote:

> Thanks for your comments. We've posted an updated draft (-01):
> 
>   https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01

[ Copied from today's dns-operations post on the same general topic. ]

A possibly inconvenient question, just to make sure we're not ignoring
the obvious sceptical position:

* How compelling is compact DoE?

The reason to ask is that both the original and now modified protocols
involve non-trivial complexity, and would likely require resolvers to
respond differently to queries with the DO bit set (pass them the NODATA
"truth" along with the NXNAME signal) vs. queries that don't request
validated answers (pass them the inferred NXDOMAIN).

The savings vs. actual by-the-book NSEC responses appear to be a 2x
reduction in the number of signatures to compute (the SOA RRSIG is  

  
presumably easily cached) and a 1.5x reduction in the number of
signatures to transmit (SOA + 1 NSEC, vs. SOA + 2 NSEC).

Do the CPU and packet size reductions justify the additional protocol
complexity?

* There is perhaps another way to ask the question: what is the
  motivation for compact DoE?  Perhaps CPU and packet sizes are a
  side show and this is all about avoiding zone walking?

In that case, might not NSEC3 "1 0 0 -" be good enough?  Sure a
sufficiently motivated offline dictionary brute-force attacker may be
able to discover some names faster with fewer online queries, but is
this **really** a concern.  How secret do you expect your DNS data to
be?  A big chunk of many zones ends up for free in certificate
transparency logs, or available from various (sometimes paywalled)
sources.  I am personally not impressed by arguments that DNS names
require confidentiality protection stronger than sufficient to deter
"casual" zone walking ala plain NSEC.

> But the main change is to move from the ENT distinguisher RR type
> to an explicit one for NXDOMAIN (with mnemonic NXNAME).

The draft fails to explain how queries for the proposed new RRtype are
to be handled by authoritative servers and resolvers.

---

On Wed, Mar 15, 2023 at 02:29:56PM +, Johan Stenstam wrote:

> Our original idea was to propose a different type of DNSKEY, i.e. a
> new flag bit in the DNSKEY that would signal “this key is only allowed
> to sign negative responses”. We were, however, talked out of that idea
> based on the strong wish to get DNSSEC out the door ASAP and therefore
> under no circumstances open up the Pandoras Box of further tweaks to
> the existing protocol.

This runs into a critical problem.  A security-critical function of
DNSSEC at the public suffix layer (TLDs, ...) is to not be vulnerable to
forged denial of existence of DS records for securely delegated domains.

**This**, and not avoiding opportunistic DANE TLSA downgrade attacks
(also good to have) is the reason that DNSSEC MUST have secure denial
of existence.

Therefore, signing keys for denial of existence are no less sensitive
(at least for zones that sign secure delegations) than signing keys
for positive response, and so the various TLD and ccTLD operators
need to be just as concerned about handing out negative signing keys.

[ And no, I am not about to suggest/endorse NSEC5. ]


> And yet, here we are, seventeen years later, still discussing this.

So I don't believe that idea can pan out.


On Sun, Mar 05, 2023 at 06:20:34PM +0100, Peter Thomassen wrote:


> 1.) Maybe it's worth pointing out that zones using compact denial
> SHOULD (MUST?) use NSEC, not NSEC3.

As others pointed out, "NSEC3 1 0 0 -" could be used, but there's no
point.  So indeed best to not define a needlessly elaborate variant.

> 2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0.

This *could* be worth exploring, and has some appeal, but may be too
difficult to know to be safe against as yet unseen resolvers that would
later come out of the woodwork.  Someone would have to be willing to run
the experiment at scale.

> 3.) Section 2:
> 
>   An alternative way to distinguish NXDOMAIN from ENT is to define the
>   synthetic Resource Record type for ENTs instead, as specified in
>   [ENT-SENTINEL], and this has already been deployed in the field. This
>   typically imposes less work on the server since NXDOMAIN responses
>   are a lot more common than ENTs.

Or both.  In other words, use two sentinel RRtypes, one to unambiguously
signal an ENT, and another to signal NXDOMAIN.  This disambiguates the
protocol from current practice, though perhaps the ambiguity would not
last long if the current operators migrate to the new protocol quickly.

>   A signed zone at an authoritative server implementing Compact Answers
>   will never return a 

[DNSOP] Meet the Root Zone Algorithm Rollover Design Team @ IETF 116

[James Mitchell]

Hello,

The Root Zone Algorithm Rollover Study Design Team is hosting a public session 
at IETF 116 and invites you to join.

Date: 29 March, 13:00 – 14:00
Room: G301
Remote: 
https://icann.zoom.us/j/94974160556?pwd=eUdOVUFUWi9yZ3FtVVFrbTFJWDFmUT09 
[icann.zoom.us]

The team's goal is to develop a plan for changing the cryptographic algorithm 
used for the DNS root key signing and zone signing keys. The team has been 
meeting since early 2023 and many members are here at the IETF to progress this 
work. We’ll share an update on the progress and challenges that we face. We 
look forward to your questions and insight.

Don’t worry if you are unable to make the session; the plan will be put to 
public comment. Follow the ksk-rollover mailing 
list for updates and announcements.

Thanks,
James Mitchell
IANA

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

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Viktor Dukhovni]

On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:

> > These “rare” cases where the domain is not resolvable when a glue is not
> > present are the ones this draft is done for. So did you look how rare
> > they were in your dataset? Being able to resolve instead of not resolving
> > IMHO has value even if the number is not big.
> >
> > We all know that a lot of data in the DNS is garbage, that should not
> > stop us from using the good data.
> 
> The cyclic dependency based sibling glue (Section 2.3) is arguably
> a bit of a corner case, and in past discussions some folks have expressed
> the view that we shouldn't make accommodations to support it. I
> think I can agree with that, but there were opposing views that we also
> shouldn't break configurations that currently work. So it was left in.

Can we at least state that domains with cyclic dependencies are a bad
idea, and may not be supported by all resolvers.  In other words, that
the domain owner can't **rely** on the sibling glue recommended to be
sent in this draft to save the day.

My strong preference is still to delete all reference in the draft to
cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
sibling glue primarily as a performance optimisation, and secondarily
as a last resort when the nameserver IP addresses are wrong or gone
from the authoritative zone (another bad practice).

What should really happen is that broken sibling glue should be
regularly purged from public suffix registries (probably requires
gaining support for this in the RRR community more than IETF), and only
then does the remaining valid sibling glue become more of a help than a
hindrance.

- Please, if at all possible, drop the cyclic dependency anti-pattern from the 
draft.

- The "right" justification for sibling glue (in the minority of cases
  that is is valid, by domain cardinality, though admittedly perhaps not
  a minority by query volume) is then lower latency/cost to reach a
  usable server.

-- 
Viktor.

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

[DNSOP] bind fails to continue recursing on one specific query

[jmurray]

Hi,

Recursive queries to a pair of matching bind 9.16 servers on openbsd 7.0 are 
timing out unexpectedly for only two names: "www.edison.tn.gov" and 
"www.tn.gov". Both bind instances are otherwise working fine, and have been for 
some time.

The query returns a CNAME, and there's a delegation to another set of 
nameservers on tn.gov, but as you can see below in the pcap and the named.run 
excerpt, bind never seems to follow up. 

Queries for either tn.gov subdomain from other hosts on other networks to which 
I have access (all using Unbound for recursion) are working as expected. And 
I'm seeing no other unexplained failures. I keep thinking I should be able to 
find some other domain which will trigger this behavior, but haven't yet.

According to users this has been going on since last Wednesday or late last 
Friday. The domains were resolving week before last based on my own experience, 
but I don't have logs from more than a few days ago, so I can't demonstrate 
that conclusively.

There's some relevant text from named.run below, also a bit of a packet 
capture, and I'm happy to supply whatever else may be helpful. Trimmed 
named.conf just a bit, marked where I've done so.

I'm totally lost, any thoughts or suggestions are very very welcome.

Thanks,

Jason


### named.conf:

acl internals {
127.0.0.0/8;
10.0.0.0/8;
172.16.28.0/24;
128.25.10.0/24;
172.16.20.16/28;
};

acl nameservers {
172.16.20.23/32;
172.16.20.22/32;
172.16.20.30/32;
};

logging {
  channel rpz.log {
file "/var/log/rpz.log" versions 3 size 5m;
severity info;
print-time yes;
print-severity yes;
print-category yes;
  };
  channel updates.log {
file "/var/log/ddns.log" versions 3 size 5m;
severity info;
print-time yes;
print-severity yes;
print-category yes;
  };
  channel query.log {
file "/var/log/query.log" versions 1 size 5m;
severity debug 3;
print-time yes;
print-severity yes;
print-category yes;
  };
  category queries { query.log; };
  category update { updates.log;  };
  category rpz { rpz.log; };
  category lame-servers { null; };
  category edns-disabled { null; };
};

options {
  directory "/tmp";
  listen-on { 172.16.20.22; 172.16.20.30; };
  check-names master warn ;
  allow-transfer { nameservers; };
  also-notify { 172.16.20.30; 172.16.20.23; };
  allow-query { any; };
  allow-recursion { internals; };
  recursion 1;
  dnssec-validation no;
  #dnssec-validation auto;
  #response-policy { zone rpz.local; };
  #response-policy { zone rpz.local; } break-dnssec yes;
};

key "example.org" {
# trimmed
};

key "rndc-key" {
# trimmed
};

key "external" {
# trimmed
};

controls {
  inet 127.0.0.1 port 953
  allow { 127.0.0.1; } keys { "rndc-key"; };
};

view "internal" {
  match-clients { !key external; internals; };
  allow-recursion { internals; };
  allow-query { any; };
  recursion yes;
  zone "." {
  type hint;
  file "/etc/named.ca";
  };
  #zone "rpz.local" {
  #  type master;
  #  file "/master/rpz.local.hosts";
  #  allow-query { localhost; };
  #  allow-transfer { nameservers; };
  #  notify yes;
  #};
  zone "example.org" {
  type master;
file "/master/example.org.internal.hosts";
allow-update { key "example.org"; };
allow-transfer { nameservers; };
notify yes;
  };
  #trimmed spare zones
};

view "external" {
match-clients { key external; any; };
server 172.16.20.23 {
  keys external;
  provide-ixfr yes;
};
allow-transfer { nameservers; };
allow-query { any; };
allow-recursion { none; };
recursion no;
zone "." {
  type hint;
  file "/etc/named.ca";
};
zone "example.org" {
  type master;
  file "/master/example.org.external.hosts";
  allow-transfer { nameservers; };
  notify yes;
};
  #trimmed spare zones
};


### trace:

; <<>> dig 9.10.8-P1 <<>> +trace www.tn.gov
;; global options: +cmd
.   518400  IN  NS  a.root-servers.net.
.   518400  IN  NS  b.root-servers.net.
.   518400  IN  NS  c.root-servers.net.
.   518400  IN  NS  d.root-servers.net.
.   518400  IN  NS  e.root-servers.net.
.   518400  IN  NS  f.root-servers.net.
.   518400  IN  NS  g.root-servers.net.
.   518400  IN  NS  h.root-servers.net.
.   518400  IN  NS  i.root-servers.net.
.   518400  IN  NS  j.root-servers.net.
.   518400  IN  NS  k.root-servers.net.
.   518400  IN  NS  l.root-servers.net.
.   518400  IN  NS  m.root-servers.net.
.   518400  IN  RRSIG   NS 8 0 518400 2023040905 
2023032704 951 . 

Re: [DNSOP] DNSOPRFC 8914 EDE code for filtered rrtype

[Petr Špaček]

On 21. 03. 23 18:05, Wes Hardaker wrote:

Petr Menšík  writes:


I have made a proposal to mark all filtered out  queries with EDE
code Filtered (17). However codes 15-18 all describe themselves as
per-domain rules.


I agree that none of these look appropriate based on re-reading the text.

I actually think your desire to filter by qtypes is not anywhere in the
purpose of the original list.  Thus...  you need to write a draft with a
new EDE code allocated I think.


In fact full-blown draft is not needed. The EDE registry policy is FCFS 
so you can have it with mere link to "something", see e.g. code 25 here.


https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#extended-dns-error-codes

--
Petr Špaček
Internet Systems Consortium

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