Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

[Stephane Bortzmeyer]

On Sat, Mar 16, 2024 at 01:27:00PM -0700,
 Shumon Huque  wrote 
 a message of 236 lines which said:

> > * is there an EDE which is recommended when replying to an
> > explicit request for a meta-type (like QTYPE=NXNAME)? 
> 
> It doesn't, but could. I don't see an obviously applicable EDE code that
> covers this (apart from the catch-all "Other Error"), so perhaps we could
> define a new one, "Invalid Query Type"?

Currently, I use 18, Prohibited, which is not perfect.

> One current implementation does not differentiate DO=0 vs 1 and gives the
> same NODATA answer for both cases.

Yes. I see no practical problem with that but, from a philosophical
point of view, it disturbs me. Naive clients may make wrong
conclusions from the NODATA answer. 

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

[Stephane Bortzmeyer]

On Mon, Mar 04, 2024 at 02:15:55PM -0800,
 internet-dra...@ietf.org  wrote 
 a message of 48 lines which said:

> Internet-Draft draft-ietf-dnsop-compact-denial-of-existence-03.txt is now
> available. It is a work item of the Domain Name System Operations (DNSOP) WG
> of the IETF.

I just implemented it at the IETF 119 hackathon in Brisbane
(programming details at the end), on an authoritative-only server. I
think I have done everything that's in the draft, including the EDNS
signaling (new flag CO).

This was quite simple and the draft is enough to guide the
implementor. I find the draft clear and useful.

Among the questions raised:

* is there an EDE which is recommended when replying to an
explicit request for a meta-type (like QTYPE=NXNAME)? The draft says
to set the rcode to FormErr but does not discuss EDE.

* the draft does not discuss the consequences of compact denial for
synthesis of negative answers by a resolver (RFC 8020 and 8198).

* [this one is outside the scope of the draft] Is it
reasonable/legitimate to reply NODATA for a non-existing name when
the client did not set the DO flag, or even when it did not use EDNS?

Programming details: the change was made on the Drink authoritative
dynamic server . Since Drink
only has dynamic signing, it implemented the white lies of RFC
4470. Adding compact denial was mostly removing code since, for the
authoritative name server, compact denial is simpler than white
lies. But it challenged some assumptions in the code (for instance
that the rcode, once set, is not changed during processing of the
request) and, in the case of Drink, required changes in several
places. The code is in the branch compact-denial 
. 



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

Re: [DNSOP] QNAME minimization is bad

[Stephane Bortzmeyer]

On Fri, Nov 10, 2023 at 02:45:08PM +,
 Denny Watson  wrote 
 a message of 50 lines which said:

> One thing that is of interest to me; There appears to be no way for
> the owner of the dataset being queried (they should understand what
> exists in their zones better than anyone else) to signal that
> beneath this domain cut you should just request the full QNAME.

It does not seem a good idea, politically. It would enable any
registry to shutdown QNAME minimisation for the zones it is
authoritative for.

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

Re: [DNSOP] QNAME minimization is bad

[Stephane Bortzmeyer]

On Fri, Nov 10, 2023 at 01:26:36PM +0100,
 John R Levine  wrote 
 a message of 39 lines which said:

> asking if anyone has 
> thought about this problem:

The dnsop working group, may be :-) This issue is mentioned in RFC
9156, section 2.3, which documents ways to address it.

> I'd like to write a draft that updates RFC 9156 by describing
> situations like this that caches could recognize and avoid useless
> churn, added to section 2.3 which already suggests special casing
> underscored labels.

I must confess that I do not see what is suggested in this thread
which is not already in section 2.3. Unbound implements some of the
RFC ways, see its iterator/iterator.h (all parameters named
*MINIMISE*).

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

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Stephane Bortzmeyer]

On Mon, Aug 01, 2022 at 02:31:48PM +0200,
 Independent Submissions Editor (Eliot Lear)  wrote 
 a message of 89 lines which said:

> Whether that means using TLD labels that begin with _ or whether
> that means suffixing them with ".ALT", I leave to you experts to
> sort.  I do agree with Martin that it would be helpful to have some
> registration of names so that conflicts between name spaces can be
> avoided.  This would also encourage formal documentation of those
> projects.

I agree and I think publication of these drafts would be a good idea
(may be with status Experimental since, as Joe Abley said, there is
clearly no IETF consensus). Note that I am skeptical about their use:
most people who "preempt" .eth, .bitcoin, .web3 or .myownprotocol will
not read the RFC and, if they do, won't follow it. But at least we
will be able to say that we tried and we have a solution (and not a
ridiculous one such as "pay ICANN 185 000 US $").

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

Re: [DNSOP] Testing SVCB/HTTPS records

[Stephane Bortzmeyer]

On Wed, Jan 19, 2022 at 10:08:48AM +,
 Stephen Farrell  wrote 
 a message of 231 lines which said:

> I made a test setup for my TLS/ECH work. [1] Happy to
> take PRs or tweak if it's useful to others.

It seems it does not address the same thing. I was thinking of testing
*actual* published SVCB/HTTPS records, for instance to detect a case
where the HTTPS record says alpn="h3" but the HTTP server does not
actually speaks HTTP/3.





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

[DNSOP] Testing SVCB/HTTPS records

[Stephane Bortzmeyer]

Does anyone know a service/software to check the consistency between
SVCB/HTTPS DNS records and the Web site? Such as testing the various
alpn, the various IP addresses hints, the aliases, etc. (It seems
ssllabs.com don't do it yet.)

I suspect that many people will put wrong SVCB/HTTPS records...

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

Re: [DNSOP] Deprecating infrastructure .INT domains

[Stephane Bortzmeyer]

On Fri, Nov 12, 2021 at 08:46:35AM -0500,
 Joe Abley  wrote 
 a message of 25 lines which said:

> The operational decisions relating to these things have already been
> made, as I understand it -- the delegations no longer exist.

nsap.int and tpc.int still exist.

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

Re: [DNSOP] updated to draft-wing-dnsop-structured-dns-error-page-01

[Stephane Bortzmeyer]

On Fri, Nov 12, 2021 at 03:26:04PM +0100,
 Stephane Bortzmeyer  wrote 
 a message of 27 lines which said:

> Moreover, I have serious doubts that DNS configuration errors could be
> meaningfully reported to end users. It would be very difficult to make
> them understandable and, since we deal with errors in authoritative
> servers, the client could not do anything, anyway.
> 
> I have nothing against informing users (some will find that useful)
> but we should focus on reporting to the zone manager, not to the
> client.
> 
> So, I don't think interaction with Web browser's authors is required.

Sorry, please ignore this message, I've mixed up
draft-wing-dnsop-structured-dns-error-page and
draft-ietf-dnsop-dns-error-reporting.

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

Re: [DNSOP] updated to draft-wing-dnsop-structured-dns-error-page-01

[Stephane Bortzmeyer]

On Thu, Nov 11, 2021 at 12:59:42PM +0100,
 Vittorio Bertola  wrote 
 a message of 24 lines which said:

> I don't want to speak for them (I don't know if they are on this
> list, but they definitely are on ADD) but in past discussions around
> this concept they recognized its potential usefulness (apart maybe
> from a specific browser which seems to have a principle stance
> against DNS filters) but were concerned about the security of the
> mechanism, i.e. the risk that it could be used to present to the
> user a phishing or misleading page,

Moreover, I have serious doubts that DNS configuration errors could be
meaningfully reported to end users. It would be very difficult to make
them understandable and, since we deal with errors in authoritative
servers, the client could not do anything, anyway.

I have nothing against informing users (some will find that useful)
but we should focus on reporting to the zone manager, not to the
client.

So, I don't think interaction with Web browser's authors is required.

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

Re: [DNSOP] draft-moura-dnsop-negative-cache-loop

[Stephane Bortzmeyer]

On Mon, Nov 08, 2021 at 08:49:03AM +0100,
 Giovane C. M. Moura  wrote 
 a message of 58 lines which said:

> We wrote a new draft that adds a new requirement to existing solutions:
> recursive resolvers must detect and negative cache problematic (loop)
> records.

I basically agree with Petr Špaček and Ralf Weber. Resource limiting is:

* more general (it also addresses infinite recursion - CVE-2014-8500,
CVE-2014-8602, CVE-2014-8601, not just loops),

* already implemented.

So, I'm not sure we need a new RFC.

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

Re: [DNSOP] Fwd: I-D Action: draft-ietf-dnsop-rfc5933-bis-06.txt

[Stephane Bortzmeyer]

On Fri, Nov 12, 2021 at 01:59:52PM +0100,
 Dmitry Belyavsky  wrote 
 a message of 153 lines which said:

> New version of the draft is uploaded.

I would like to have to additions, if you have time:

* a section summarizing the changes since RFC 5933. It seems it is
just GOST R 34.10-2001 replaced by GOST R 34.10-2012?

* an implementation status section (see RFC 7942) listing the
resolvers that can validate with GOST R 34.10 (Unbound, and BIND, it
seems) but also a few domain names signed with it (I knew caint.su but
it apparently disappeared).

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

Re: [DNSOP] IPR Disclosure VeriSign, Inc.'s Statement about IPR related to draft-ietf-dnsop-qname-minimisation and RFC 7816

[Stephane Bortzmeyer]

On Thu, Oct 14, 2021 at 09:17:43AM -0700,
 IETF Secretariat  wrote 
 a message of 11 lines which said:

> An IPR disclosure that pertains to your RFC entitled "DNS Query Name
> Minimisation to Improve Privacy" (RFC7816) was submitted to the IETF
> Secretariat on 2021-10-14 and has been posted on the "IETF Page of
> Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.org/ipr/5197/). The title of the IPR disclosure is
> "VeriSign, Inc.'s Statement about IPR related to
> draft-ietf-dnsop-qname-minimisation and RFC 7816"

Speaking of patents, I recommend the Netflix mini-series
"Billion-dollar code", about a dispute between a small startup and a
big company in the 1990s. Enjoyable and a good representation of the
field.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-00.txt

[Stephane Bortzmeyer]

On Mon, Jun 14, 2021 at 10:03:22AM -0400,
 Hugo Salgado  wrote 
 a message of 55 lines which said:

> In the case of NXDOMAIN, the reason for not adding RRSERIAL is
> because the response already has the SOA in the AUTHORITY, which
> would make it redundant.

OK, I see. Here are two implementations of the client part, in Python
and in Go, using this algorithm (RRSERIAL if NOERROR or SERVFAIL, and
the SOA record if NXDOMAIN).

Python :

% ./test-rrserial.py 200.1.122.30 dateserial.example.com TXT
dateserial.example.com. 43200 IN TXT "Test zone for RRSERIAL record"  
Serial of the answer is 2018081401

% ./test-rrserial.py 200.1.122.30 dateserial.example.com LOC
No value for dateserial.example.com/LOC
Serial found from SOA record: 2018081401

Go :

%   ./test-rrserial 200.1.122.30 incserial.example.com  MX
incserial.example.com.  43200   IN  MX  10 mail.incserial.example.com.
EDNS rrserial found, "1"

%   ./test-rrserial 200.1.122.30 incserial.example.com  SSHFP
Empty answer received
EDNS rrserial found, "1"

Note that you can do it with dig alone but the display of unknown data
is less pretty:

% dig +ednsopt=65024 @200.1.122.30 dateserial.example.com
...
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; OPT=65024: 78 49 7a 79 ("xIzy")

Note also there is a bug in your server: when the name does not exist,
it sends incorrect messages. dig says "Message parser reports
malformed message packet" and the Python library "DNS message is
malformed". And the Go library:

%   ./test-rrserial 200.1.122.30 doesnotexist.incserial.example.com
Error in query: dns: overflowing header size
#!/usr/bin/env python3

"""Simple Python program to implement IETF draft
draft-ietf-dnsop-rrserial (hereafter "the draft")

If you don't know Python:
pip install dnspython
./test-rrserial.py 200.1.122.30 dateserial.example.com

"""

import struct
import sys

# DNSpython https://www.dnspython.org/ We probably require 2.0 or higher.
import dns.message
import dns.query
import dns.edns
import dns.rdatatype

# Temporary value in the draft
dns.edns.RRSERIAL = 65024

def print_soa(response):
  found = False
  for rr in response.authority:
if rr.rdtype == dns.rdatatype.SOA:
  found = True
  print("Serial found from SOA record: %s" % rr[0].serial)
  if not found:
print("Negative answer without a SOA record :-(")

def print_rrserial(response):
  found = False
  for opt in response.options:
if opt.otype == dns.edns.RRSERIAL:
  found = True
  print("Serial of the answer is %s" % struct.unpack(">I", opt.data)[0])
  if not found:
print("No EDNS serial option in answer")

# TODO: it would probably be better (more pythonic) to inherit from
# dns.edns.GenericOption and provide a parser.
opts = [dns.edns.GenericOption(dns.edns.RRSERIAL, b'')]

if len(sys.argv) != 3 and len(sys.argv) != 4:
  raise Exception("Usage: %s server qname qtype [for instance '200.1.122.30 dateserial.example.com ')" % sys.argv[0])
server = sys.argv[1]
qname = sys.argv[2]
if len(sys.argv) == 4:
  qtype = dns.rdatatype.from_text(sys.argv[3])
else:
  qtype = dns.rdatatype.
message = dns.message.make_query(qname, qtype, options=opts)
response = dns.query.udp(message, server)
if response.rcode() == dns.rcode.NOERROR:
  data = False
  for rr in response.answer:
if rr.rdtype == qtype:
  data = True
  print(rr)
  if not data:
print("No value for %s/%s" % (qname, dns.rdatatype.to_text(qtype)))
print_soa(response)
  else:
print_rrserial(response)
elif response.rcode() == dns.rcode.NXDOMAIN:
  print("%s not found" % qname)
  print_soa(response)
elif response.rcode() == dns.rcode.SERVFAIL:
  print("%s failed" % qname) 
  print_rrserial(response)
else:
  print("Unknown return code %s" % response.rcode())


// Test program to experiment the IETF draft draft-ietf-dnsop-rrserial 
(hereafter "the draft").
// Depends on godns  
.

// If you don't know Go:
//   go get github.com/miekg/dns
//   go build test-rrserial.go

package main

import (
"encoding/binary"
"fmt"
"github.com/miekg/dns"
"os"
"strings"
)

const otype = 65024

func print_rrserial(msg *dns.Msg) {
opt := msg.IsEdns0()
for _, v := range opt.Option {
switch v := v.(type) {
case *dns.EDNS0_LOCAL:
if v.Option() == otype {
serial := binary.BigEndian.Uint32(v.Data)
fmt.Printf("EDNS rrserial found, \"%d\"\n", 
serial)
}
default:
continue
}
}
}

func main() {
if len(os.Args) != 3 && len(os.Args) != 4 {
fmt.Printf("%s SERVER QNAME [QTYPE]\n", os.Args[0])
os.Exit(1)
}
ns := os.Args[1]
qname := dns.Fqdn(os.Args[2])
qtype := dns.Type
ok := 

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Stephane Bortzmeyer]

On Thu, Jun 10, 2021 at 04:26:44PM -0700,
 Shivan Kaul Sahib  wrote 
 a message of 164 lines which said:

> Hi all, Shumon and I have been working on an early draft that
> surveys current DNS domain verification techniques. Depending on how
> it goes, we hope to eventually explore if we can come up with some
> best practices.

Section 4.1: you do not mention a recommended name for the
subdomain. Should we suggest a name starting with an underscore, to
limit the risk of collisions and to emphasize it is not a host name?
(On the other hand, some users may have a limited DNS provisioning
interface, which enforces a LDH restriction.)

Section 5: should we also add that, specially if the zone is not
signed, multi-vantage-point checking is recommended (Let's Encrypt
already does it)?


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-00.txt

[Stephane Bortzmeyer]

On Fri, Jun 11, 2021 at 07:36:00AM -0700,
 internet-dra...@ietf.org  wrote 
 a message of 39 lines which said:

> Title   : The "RRSERIAL" EDNS option for the SOA serial of a 
> RR's zone
> Authors : Hugo Salgado
>   Mauricio Vergara Ereche
>   Filename: draft-ietf-dnsop-rrserial-00.txt

I do not understand why the RRSERIAL EDNS is not added for NXDOMAIN
responses (section 3.2). Specially since it is added for SERVFAIL,
which is surprising.

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

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-rfc7816bis-09

[Stephane Bortzmeyer]

On Sun, Jun 06, 2021 at 11:13:23PM -0700,
 Suhas Nandakumar via Datatracker  wrote 
 a message of 72 lines which said:

> I am the assigned Gen-ART reviewer for this draft

Thanks for the review.

> Section 2.3
> 1. MAX_MINIMISE_COUNT and MINIMISE_ONE_LAB - are the values for these 
> constants
> normatively defined or are they just recommendations ? Can the same be
> clarified in the document ?

The sentence "a good value is 10" seems to me indicating that it is
just a possible value. The important thing is to have a limit. Do we
think it should be rewritten with RFC 2119 words? MUST have a limit
and the RECOMMENDED value is 10?

> Section 4.
> The section starts with query for "foo.bar.baz.example" and walk through 
> refers
> to a.b.example.org  as query input.  Also no reference to ns1.nic.example 
> seems
> to be appear in the detailed flows.
>  Can this be updated it to match overall ?

Actually, there are *two* independant requests. One for
foo.bar.baz.example and one afterwards ("Here are more detailed
examples") for a.b.example.org. In the first one, ns1.nic.example is
indeed used.

Should we use the same QNAME for both?

> Section 5
> "QNAME minimisation may also improve lookup performance for TLD
>operators.  For a TLD that is delegation-only, a two-label QNAME
>query may be optimal for finding the delegation owner name, depending
>on the way domain matching is implemented."
> This para doesn't clarify how the performance will be improved.  Can it
> be extended with some context around the same.

With QNAME minimisation, an authoritative name server MAY use exact
matching ("do I know foobar.example?") while without it, it MUST use
tree matching ("do I know thing.stuff.foobar.example or an ancestor of
it?") and tree matching is typically slower.

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

Re: [DNSOP] A draft about the Name:Wreck problem draft-dashevskyi-dnsrr-antipatterns

[Stephane Bortzmeyer]

On Wed, Apr 14, 2021 at 11:01:42AM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 10 lines which said:

> The Name:Wreck compression pointer issue

Also
<https://www.scmagazine.com/home/security-news/vulnerabilities/namewreck-is-the-latest-collision-between-tcp-ip-and-the-standards-process/>
talks about what IETF should do. (The article contains several errors
about the RFC process.)

> “I mean I don’t want to be the one telling the [Internet Engineering
> Task Force] how to do their work. Things have worked for more than
> 40 years on the internet because of the RFC systems,” he said. “But
> indeed, I do believe that it’s time that we think of an
> alternative.”

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

Re: [DNSOP] A draft about the Name:Wreck problem draft-dashevskyi-dnsrr-antipatterns

[Stephane Bortzmeyer]

On Wed, Apr 14, 2021 at 11:01:42AM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 10 lines which said:

> The Name:Wreck compression pointer issue
> <https://www.forescout.com/company/resources/namewreck-breaking-and-fixing-dns-implementations>

Regarding dnsop work, the same report suggests to modify RFC 5625 "DNS
Proxy Implementation Guidelines" to replace the MAY in section 6.3 by
a MUST. I think that the reason there is currently a MAY is not
because RFC 5625 finds invalid compression pointers acceptable but
simply because some proxies may not perform a full parsing of the RR
in the sections.

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

[DNSOP] A draft about the Name:Wreck problem draft-dashevskyi-dnsrr-antipatterns

[Stephane Bortzmeyer]

The Name:Wreck compression pointer issue

illustrates the implementation problems of DNS. I just find that there
is an Internet-Draft, draft-dashevskyi-dnsrr-antipatterns, discussing
these problems. Seems interesting.

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

Re: [DNSOP] NSA says don't use public DNS or DoH servers

[Stephane Bortzmeyer]

On Mon, Jan 18, 2021 at 04:27:20PM -0500,
 John Levine  wrote 
 a message of 18 lines which said:

> They think DoH is swell, but not when it bypasses security controls
> and leaks info to random outside people 

I will certainly do as the NSA says, since they are experts in
privacy-related issues (and in random numbers since they call "random"
the resolver that is configured in my browser) but, to add fuel to the
fire, the people at JSOF who discovered the DNSpooq vulnerability just
said the opposite:

https://www.zdnet.com/article/dnspooq-lets-attackers-poison-dns-cache-records/

"A good workaround would be to use DNS-over-HTTPS (DoH) or
DNS-over-TLS (DoT)," Oberman said.

"Another option would be to statically configure a trusted DNS server,
like Cloudflare or Google DNS servers, so that DNS requests are not
handled by the home router and go directly to the [remote] DNS server.


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

Re: [DNSOP] Tell me about tree walks

[Stephane Bortzmeyer]

On Sun, Nov 22, 2020 at 10:56:58AM -0500,
 John R Levine  wrote 
 a message of 17 lines which said:

> I don't see why, since it only acts as a default.  Any registrant
> that cares which CA they use can publish their own CAA.

Yes but many registrants don't know about CAA or did not pay attention
to this subtle detail, so I still believe it is bad practice to climb
the tree looking for such data.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-06.txt

[Stephane Bortzmeyer]

On Wed, May 06, 2020 at 03:19:36PM +,
 Wessels, Duane  wrote 
 a message of 153 lines which said:

> The changes from -05 to -06 of this document include:

The draft just expired. Any news?

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

Re: [DNSOP] private-use in-meeting chat comments

[Stephane Bortzmeyer]

On Tue, Nov 17, 2020 at 10:51:45PM +,
 Tony Finch  wrote 
 a message of 32 lines which said:

> if the domain points at AS112 then almost anyone might receive the
> QNAME leakage; if the domain is unregistered and the resolver does
> qmin then there's less leakage.
> 
> This is really a general issue with split horizon DNS: whoever is
> assigning or giving advice about local/internal DNS needs to make
> it clear that the names aren't private and will leak.

Note that this is one of the reasons why draft-bortzmeyer-dname-root
was not a success: some people objected that AS 112 is not to be
trusted with "private" names.

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

Re: [DNSOP] Tell me about tree walks

[Stephane Bortzmeyer]

On Wed, Nov 11, 2020 at 09:39:38PM +,
 Tony Finch  wrote 
 a message of 34 lines which said:

> Well, the other Very Prominent example is CAA records, which also
> involve walking up the tree to discover policy. It would be nice if
> things like CAA and DMARC could agree with each other about how they
> discover domain-wide policies.

IMHO, the CAA algorithm is bad because it crosses administrative
boundaries. RFC 8659 at least excludes the root but it still allows,
for instance, AFNIC to put a CAA record in .fr which will apply to all
.fr domains which do not have an explicit CAA. It seems bad.

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

Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call

[Stephane Bortzmeyer]

On Wed, Oct 14, 2020 at 07:15:10PM +0100,
 Tony Finch  wrote 
 a message of 53 lines which said:

> Section 3, algorithm step 5: what is a "hidden QTYPE"?

The original QTYPE, which may be "hidden" by a substitution to another
QTYPE (see section 2 "a QTYPE selected by the resolver to hide the
original QTYPE"). This was not in RFC 7816. Would you prefer we settle
on "original QTYPE"?

> Step 6, what is the "minimised QTYPE"?

The opposite of "hidden QTYPE", it is the QTYPE choosen by the
resolver (NS was recommended in RFC 7816, but it is A in 7816-bis).

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.txt

[Stephane Bortzmeyer]

On Fri, Aug 23, 2019 at 05:08:59PM -0700,
 Erik Kline  wrote 
 a message of 237 lines which said:

> +1 from me, fwiw.

No discussion since, and the draft is expired. Any news?

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

Re: [DNSOP] Last Call: (Message Digest for DNS Zones) to Proposed Standard

[Stephane Bortzmeyer]

On Thu, Sep 10, 2020 at 03:03:45PM -0400,
 Warren Kumari  wrote 
 a message of 62 lines which said:

> Do you have any suggested text? If so, could you send it to the IETF
> LC so it gets captured?

Done


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

Re: [DNSOP] Last Call: (Message Digest for DNS Zones) to Proposed Standard

[Stephane Bortzmeyer]

On Mon, Aug 31, 2020 at 09:05:41AM -0700,
 The IESG  wrote 
 a message of 51 lines which said:

> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document: - 'Message Digest for DNS Zones'
>as Proposed Standard

This is not really part of the Last Call (I have no problem with the
document in its current form), it's more about two "philosophical"
questions I have about zone digests.

One is small: the draft claims "a name server loading saved zone data
upon restart cannot guarantee that the on-disk data has not been
modified". This argument seems weak. Can we really imagine attacks
where the attacker can modify the zone file on the disk, but cannot
modify the verifier, for instance its code, or its trust anchors? 

The other is more complicated. The draft says "Unfortunately, the
protections [TLS, SSH, etc] provided by these channel security
techniques are (in practice) ephemeral and are not retained after the
data transfer is complete. [they] not provide any methods to verify
data that is read after transmission is complete." In the DNSSEC cas,
zone digest provide such a method but only for a time. Once the keys
are rolled over, the verification is no longer possible. Since most
(all?) DNSSEC tools assume they can delete a key once the RRSIG which
use it have been removed from all caches, you can have a zone file
whose signatures are still valid (not expired) but the DS and/or keys
are no longer available online. Unless I'm wrong, this limit is not
mentioned. (Not sure it is important in practice, as I said, it is
more a philosophical question.)

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-information-01.txt

[Stephane Bortzmeyer]

On Tue, Feb 11, 2020 at 06:23:56PM -0800,
 internet-dra...@ietf.org  wrote 
 a message of 50 lines which said:

> Title   : DNS Resolver Information Self-publication
>   Filename: draft-ietf-dnsop-resolver-information-01.txt

> The IANA registry (Section 5.2) will never register names that begin
> with "temp-".

It seems that the point explained in

(and raised in other messages) has not been addressed: temp- is x-
under another name and it seems to me that RFC 6648 strongly
discourages it. Since the registration rules for a name are quite
liberal, why temp-?


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

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-ns-revalidation

[Stephane Bortzmeyer]

On Sun, May 24, 2020 at 05:51:24AM -0400,
 Tim Wicinski  wrote 
 a message of 61 lines which said:

> This starts a Call for Adoption for draft-huque-dnsop-ns-revalidation
> 
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-huque-dnsop-ns-revalidation/

I think it addresses a real problem, I think it is a good start for a
draft, and I'm willing to review it. (In other words: I support
adoption.)

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

Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements

[Stephane Bortzmeyer]

On Mon, May 04, 2020 at 03:08:20PM -0400,
 Tim Wicinski  wrote 
 a message of 64 lines which said:

> This starts a Call for Adoption for
> draft-mglt-dnsop-dnssec-validator-requirements

I think it is important to have such a document, because DNSSEC
failures may seriously endanger the deployment of DNSSEC (which is
already too low). The current draft seems a good starting point and I
support its adoption.

I'm willing to review. Let's start immediately with -09:

draft-ietf-dnsop-extended-error (recently approved by the IESG) should
be mentioned, since one of the biggest operational problem with DNSSEC
is the difficulty to understand why a resolver returns a SERVFAIL to
you.

> More often, to date, failed validation is due to operator error and
> not an attempt to forge data.

It can be a bug in software, too. Specially with complicated things
like NSEC3+optout+ENT+dynupdate :-{

The draft apparently do not mention advices on expiration slack (such
as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a
consensus on (I quote Unbound documentation) "The signature inception
and expiration dates are allowed to be off by 10% of the signature
lifetime"?

> However, a DNSSEC validator is not able to determine other than by
> trying whether a signature scheme is supported by the authoritative
> server.

This one is unclear. First, the signer is not always an authoritative
server, signature can be done offline. Second, querying the DNSKEY is
enough, no? (Or querying the signatures, but I assume a zone won't
publish a DNSKEY without being able to sign with this algorithm.)

Section 12 "Invalid Reporting Recommendations" is questionable. Since
most DNSSEC validation errors are not attacks, reporting these errors
may overload the DRO with problems she can do nothing
about. Monitoring is a good idea but monitoring what? "Important" (for
the DRO) domains?

Also, the draft has many, it seems, grammar / language
problems. ("This introduces a potentially huge vector for
configuration errors, but due to human intervention as well as
potential misunderstanding of ongoing operations.")


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

Re: [DNSOP] On Powerbind

[Stephane Bortzmeyer]

On Tue, Apr 14, 2020 at 08:24:20PM -0400,
 Paul Wouters  wrote 
 a message of 108 lines which said:

> > I'm still not able to understand this.  Suppose nic.footld puts a
> > statement for humans on their website that says ".footld promises
> > to be delegation-only".
> 
> First, this approach does not work. Not all TLD's have the ICANN mandated
> nic..

Not even ICANN TLDs :-)

https://nic.com/
https://nic.org/

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

Re: [DNSOP] New draft on delegation revalidation

[Stephane Bortzmeyer]

On Sat, Apr 11, 2020 at 09:22:42AM -0400,
 Shumon Huque  wrote 
 a message of 138 lines which said:

> I've heard proposals in the past that TLDs should routinely scan all
> their delegations to identify such problems, but I gather this is a
> challenging requirement to impose on them for various reasons.

Also, delegation is not only done by TLDs. The problem, already huge
with only the TLDs, would be even worse with all the delegating
domains.


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

Re: [DNSOP] New draft on delegation revalidation

[Stephane Bortzmeyer]

On Sat, Apr 11, 2020 at 09:22:42AM -0400,
 Shumon Huque  wrote 
 a message of 138 lines which said:

> > The delegation (re)validation might be a reasonable place to
> > implement something to detect this and adjust the choice of NS on
> > the resolver's cache.
> 
> I think most resolvers do a bit of this today already. If they detect a
> broken delegation, they will mark that server as lame, and remove it from
> the candidate nameservers for the zone (for a certain period of time), and
> try another one.

I don't think that you answer Brian's idea. The way I've read his
idea, he suggested, when a resolver detects a lame server (or when all
servers are lame?), to go back to the parent and to ask again the NS
set, to see if there is a new and better list.


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

[DNSOP] DNS stamps

[Stephane Bortzmeyer]

Could be useful specially for secure and public resolvers, may be
worth of some IETF work?

https://github.com/DNSCrypt/dnscrypt-proxy/wiki/stamps

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

Re: [DNSOP] Last Call: (A Common Operational Problem in DNS Servers - Failure To Communicate.) to Best Current Practice

[Stephane Bortzmeyer]

On Thu, Dec 05, 2019 at 06:00:39PM -0800,
 The IESG  wrote 
 a message of 53 lines which said:

> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document: - 'A Common Operational Problem
> in DNS Servers - Failure To Communicate.'
>as Best Current Practice

I just tested the dig commands against NSD and Knot. No problem for
NSD but Knot has a discrepancy:

8.1.4 "Testing Unknown Opcodes"

expect: status: NOTIMP

But:

% dig +noedns +noad +opcode=15 +norec +header-only @2001:678:f::1  

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> +noedns +noad +opcode=15 +norec 
+header-only @2001:678:f::1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: RESERVED15, status: FORMERR, id: 58770
;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; Query time: 24 msec
;; SERVER: 2001:678:f::1#53(2001:678:f::1)
;; WHEN: Mon Dec 16 10:28:49 CET 2019
;; MSG SIZE  rcvd: 12

Do we agree that Knot is wrong and the draft is right? Or is FORMERR
acceptable?

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

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Stephane Bortzmeyer]

On Thu, Sep 12, 2019 at 09:51:25AM -0400,
 Tim Wicinski  wrote 
 a message of 90 lines which said:

> We had such great comments the first time we did a Working Group
> Last Call for draft-ietf-dnsop-extended-error, that the chairs
> decided a second one would be even better.

IMHO, the document is good. I like the fact there is no longer a
limitation of a given EDE to some RCODEs (it makes things simpler).

Some details, all editorial:

* it could be a good idea to add more specific references for the
EDE. For instance, 3 "Stale Answer" could have a reference to
draft-ietf-dnsop-serve-stale.

* I think that many people will be confused with 15, 16, 17 and 18.
Suggestions:
  * remove 18, which is redundant with 15 (if the user chooses the
  resolver, and he should have the right to do so, 15 and 18 are the
  same). 18 is meaningful only if the user does have a simple way to
  change this behaviour.
  * Add to the definition of 15 "The policy was decided by the server 
administrators"
  * Add to the definition of 16 "This means that the policy was
  not decided by the server administrators, and it is probably useless
  to complain to them".


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

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[Stephane Bortzmeyer]

On Mon, Feb 19, 2018 at 10:00:39AM -0500,
 Suzanne Woolf  wrote 
 a message of 17 lines which said:

> We’ve let the discussion continue because it’s been so active, but
> we also haven’t forgotten we need to review and determine next steps
> on this draft.

I don't find anything about the decision for the draft
draft-ietf-dnsop-let-localhost-be-localhost (it's now expired for more
than a year), after the working group last call. Can we safely
conclude it's dead?

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

Re: [DNSOP] AD review of draft-ietf-dnsop-serve-stale-07

[Stephane Bortzmeyer]

On Wed, Sep 11, 2019 at 12:06:23PM -0400,
 Barry Leiba  wrote 
 a message of 75 lines which said:

> I wonder if it makes sense to be more explicit here that one isn’t
> meant to keep using expired data forever, but is expected to keep
> trying to refresh it.  So, maybe?:
> 
> NEW
>   If the data is unable to be
>   authoritatively refreshed when the TTL expires, the record MAY be
>   used as though it is unexpired until an authoritative refresh is
>   successful.
> END

I think your proposed text is worse since it contradicts the current
draft, which limits the time during which you can serve stale answers
"The maximum stale timer should be configurable, and defines the
length of time after a record expires that it should be retained in
the cache.  The suggested value is between 1 and 3 days. [Even if you
cannot contact the authoritative servers, my note.]"

> Is another possible new security consideration that bad actors could
> DDoS authoritative servers with the explicit intent of having stale
> cached information used for longer, perhaps to extend the life of a
> cache-poisoning attack or some such?

Yes, seems right. Also reported by Viktor Dukhovni during the last
call. May be add at the end of section 10 "Attackers could be incited
to dDoS authoritative servers with the explicit intent of having stale
cached information used for longer. But if they have this capacity,
they probably could do much worse things than prolongating old data."

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

Re: [DNSOP] Last Call: (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard

[Stephane Bortzmeyer]

On Wed, Sep 11, 2019 at 02:32:35PM -0400,
 Viktor Dukhovni  wrote 
 a message of 37 lines which said:

> Finally, in security considerations, there's no mention of
> the potential security impact of stale negative responses.

It's not true, the last two paragraphs of section 10 do it. May be, as
reported by an AD, add that an attacker may dDoS authoritative name
servers just to exploit this possibility? 

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

Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Stephane Bortzmeyer]

On Mon, Apr 29, 2019 at 05:00:38PM -0700,
 internet-dra...@ietf.org  wrote 
 a message of 41 lines which said:

> Title   : Terminology for DNS Transports and Location
> Author  : Paul Hoffman
>   Filename: draft-hoffman-dns-terminology-ter-01.txt

Seen on a slide at IETF 105 :

DoTH (to talk about DoH and DoT together, as in "DoTH use TLS to
protect DNS queries against snoopers").

A nice addition? :-)

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

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

[Stephane Bortzmeyer]

On Mon, Jul 08, 2019 at 05:27:21PM +,
 Michael J. Sheldon  wrote 
 a message of 23 lines which said:

> And it still leaves the issue that recursives should not just keep
> hammering the lame delegations when they've gotten a REFUSED
> response.

Sorry for being late in the discussion but
draft-ietf-dnsop-extended-error-06 has a code to make REFUSED crystal-clear:

4.4.1.  REFUSED Extended DNS Error Code 1 - Lame

   An authoritative server that receives a query (with the RD bit clear)
   for a domain for which it is not authoritative SHOULD include this
   EDE code in the SERVFAIL response.  A resolver that receives a query
   (with the RD bit clear) SHOULD include this EDE code in the REFUSED
   response.  Implementations should set the R flag in this case
   (another nameserver or resolver might not be lame).

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

Re: [DNSOP] I-D Action: draft-livingood-dnsop-dont-switch-resolvers-04.txt

[Stephane Bortzmeyer]

On Mon, Feb 18, 2019 at 02:06:59PM -0800,
 internet-dra...@ietf.org  wrote 
 a message of 48 lines which said:

> Title   : In Case of DNSSEC Validation Failures, Do Not 
> Change Resolvers
> Author  : Jason Livingood
>   Filename: draft-livingood-dnsop-dont-switch-resolvers-04.txt
>   Pages   : 8
>   Date: 2019-02-18

Good for me. Useful document. One suggestion:

> independent third party sites or tools that can confirm whether or
> not a DNSSEC-related error is present, of which several exist today
> (e.g.  DNSViz [1], Verisign DNSSEC Debugger [2]).

I suggest to add Zonemaster  to this list.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-05.txt

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 03:08:10PM -0700,
 internet-dra...@ietf.org  wrote 
 a message of 46 lines which said:

> Title   : Extended DNS Errors
> Authors : Warren Kumari
>   Evan Hunt
>   Roy Arends
>   Wes Hardaker
>   David C Lawrence
>   Filename: draft-ietf-dnsop-extended-error-05.txt

At the IETF 104 hackathon in Prague, Vladimír Čunát and myself
implemented it in the Knot resolver
. You can see the result in the git
merge request

(branch extended_error
).

> 4.1.5.  SERVFAIL Extended DNS Error Code 5 - DNSSEC Indeterminate
>   The resolver attempted to perform DNSSEC validation, but validation
>   ended in the Indeterminate state.  The R flag should not be set.

Isn't there an error here? 4.1 is the section for NOERROR. What
should be returned for DNSSEC Indeterminate? NOERROR or SERVFAIL? (In
the first case, change the text, in the second, move this paragraph to
4.2.)

Now, implementation experience. We tested with Wireshark and dig (did
not try to develop a client using the extended error code, just the server).

As expected, producing extended error codes is quite simple and the
draft is clear. The camel will be happy.

The biggest issue is of course to find out what to put in the extended
error code. On some resolvers (at least on Knot), the place where the
error is noticed can be quite far from the place where the answer is
built, with its EDNS options. In practice, we had to add data to the
request object, for the extended error information to be carried to
the module that emits the extended error code EDNS option. So, the
real difficulty is not in the draft, but in knowing and understanding
your resolver.

Some details:

* no resolver will use all the response-code/info-codes because some
are never reached for this resolver, or are mixed with other
issues. Generic errors (such as "SERVFAIL Extended DNS Error Code 1 -
DNSSEC Bogus") are useful for when you cannot reliably find the problem.

* the draft is silent about the laying out of bits in info-code. Not
many IETF protocols have an integer field which is larger than a byte
but not byte-aligned.

* the draft has a passing mention that multiple extended error options
are allowed but I don't see how it could be used by the poor client
trying to figure out what happened. I suggest to disallow it.

* the draft has (rightly so) two info-codes for NXDOMAIN/Blocked and
NXDOMAIN/Censored but Knot cannot use it currently since the policy
module (written in Lua) has no way today to be configured to express
the difference. Not a problem in the draft but it will be probably a
common case that the resolver cannot make use of *all* codes.

Let's end with a few examples:

4.2.2.  SERVFAIL Extended DNS Error Code 2 - Signature Expired

% dig  @::1 -p 9053 A servfail.nl 
...
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12100
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; OPT=65500: 00 00 20 02 44 4e 53 53 45 43 20 65 78 70 69 72 65 64 20 73 69 67 
6e 61 74 75 72 65 73 (".. .DNSSEC expired signatures")
...


4.2.7.  SERVFAIL Extended DNS Error Code 7 - No Reachable Authority

% dig  @::1 -p 9053 A brk.internautique.fr
...
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38620
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; OPT=65500: 80 00 20 07 6e 6f 20 4e 53 20 77 69 74 68 20 61 6e 20 61 64 64 72 
65 73 73 (".. .no NS with an address")
...

(Not an ideal message but this is quite generic code in Knot.)


4.5.1.  NXDOMAIN Extended DNS Error Code 1 - Blocked

% dig  @::1 -p 9053 A googleanalytics.com 
...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1189
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; OPT=65500: 80 00 30 01 4e 6f 20 74 72 61 63 6b 69 6e 67 ("..0.No tracking")
;; QUESTION SECTION:
;googleanalytics.com.   IN A

;; AUTHORITY SECTION:
googleanalytics.com.10800 IN SOA googleanalytics.com. nobody.invalid. (
1  ; serial
3600   ; refresh (1 hour)
1200   ; retry (20 minutes)
604800 ; expire (1 week)
10800  ; minimum (3 hours)
)

;; ADDITIONAL SECTION:
explanation.invalid.10800 IN TXT "No tracking"



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

Re: [DNSOP] [hrpc] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 05:58:13PM +0100,
 Stephane Bortzmeyer  wrote 
 a message of 19 lines which said:

> [Sorry for the long list of working groups but the discussion already
> started in different places.]

> It was suggested to have a side meeting in Prague at IETF 104. I
> propose monday, 1400-1600 in Tyrolka. The proposal is at
> <https://trac.ietf.org/trac/ietf/meeting/wiki/104sidemeetings>. You
> are welcome to agree/disagree/meet in a bar instead.

I modified the title of the meeting
<https://trac.ietf.org/trac/ietf/meeting/wiki/104sidemeetings> because
there is obviously no consensus on the problem or on the
agenda. Anyway, a room is reserved if people want to meet on
wednesday.

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

Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients

[Stephane Bortzmeyer]

On Tue, Mar 12, 2019 at 04:55:11PM +0100,
 Neil Cook  wrote 
 a message of 22 lines which said:

> Actually many enterprises (particularly banks etc.) do not allow DNS 
> resolution directly from employee endpoints.

They block UDP/53, which is not the same thing. Malware or
non-cooperating applications can do name resolution by other means. I
still do not understand why people have a problem with DoH whch did
not already exist before with
my-own-name-resolution-protocol-over-HTTPS.

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

Re: [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients

[Stephane Bortzmeyer]

On Sun, Mar 10, 2019 at 11:17:43PM -0700,
 Paul Vixie  wrote 
 a message of 36 lines which said:

> > You claim the right to impose your rules, because it is "your network".
> > Yet you have to define ownership.

> my network, my rules. your provider's network, their rules.

I clearly disagree. If the case of my home network (mine, my rules) is
clear, the case of a corporate network is less clear (an employee is
not a slave, and he/she has rights) and the case of a commercial
Internet access provider is clear in the other direction: a client is
not an employee, and is entitled to a free, open and neutral Internet
access.

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

Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 09:59:11AM +0530,
 nalini elkins  wrote 
 a message of 231 lines which said:

> Companies also (validly, in my opinion) wish to know if their
> employees are going to fantasyfootballgame.com while they are
> supposedly doing work and of course, other sites which people should
> not be going to during work time.  If I am paying someone, I expect
> them to do work that I wish them to do.

Not all companies work that way. Some evaluate the work done by the
results, not by the time spent at the desk. Please let's not discuss
IETF protocols while assuming that all companies are the same, and
that we have to endorse all their policies.

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

Re: [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients

[Stephane Bortzmeyer]

On Sun, Mar 10, 2019 at 10:24:56PM -0700,
 Paul Vixie  wrote 
 a message of 82 lines which said:

> set up a war between end users and network operators,

Well, the tussle already exists. It does not depend on whether you
like it or not, on whether the IETF approves it or not. When people
have different interests, there is a tussle. What we can hope is to
discuss it in civilized ways. But we cannot make it disappear.

 

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

Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 08:55:18AM +0530,
 nalini elkins  wrote 
 a message of 202 lines which said:

> The questions that the Fortune 50 company architect asked were something
> like this:
> 
> 1. You mean that DNS could be resolved outside my enterprise?

I suggest to explain to this person that it was possible before, as
any malware author discovered.

> 2. So whoever that is that resolves my DNS sees the pattern and frequency
> of what sites my company goes to?

RFC 7626 :-)

> It would be good to also discuss how to warn enterprises that this
> is about to happen.  I wonder if an announcement via CERT or another
> group may be appropriate.

If people responsible for networks of Fortune 50 company don't know
that it is difficult to stop unwanted communication (except when you
control all the endpoints, or when you airgap your network), then it
is indeed a problem :-)

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

Re: [DNSOP] [Doh] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Stephane Bortzmeyer]

On Tue, Mar 12, 2019 at 08:14:49PM +1100,
 Mark Nottingham  wrote 
 a message of 32 lines which said:

> I'm also very conscious that we had a side meeting about similar
> issues in Singapore (IIRC), and didn't make much progress at all in
> that time.

This time, we have drafts (poor ones, IMHO, but it's better than a
discussion without written proposals).

> Are we going to be able to productively use two hours for this?
> Could we come up with a more focused agenda and just use an hour?

You are the first to suggest to focus, until now, all remarks (both on
and off-list) have been people asking to *enlarge* the agenda :-)

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

Re: [DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 06:57:03PM +0100,
 Vittorio Bertola  wrote 
 a message of 18 lines which said:

> Moreover, centralization is not the only Do*-related problem
> category that has been raised (my draft alone lists eight others).

IMHO, this is precisely the biggest problem with these three drafts:
they accumulate a lot of unrelated rants, and it is important to split
between issues that are really DoH-specific from more general issues.

Warren Kumari did a good job of sorting that out in
. I
quote him:

1: the protocol,
2: the deployment concerns,
3: "resolverless DNS",
4: the loss of visibility from encrypting the DNS

IMHO, this makes several side meetings. People are welcome to organize
more.

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

Re: [DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 01:59:25PM -0400,
 Allison Mankin  wrote 
 a message of 94 lines which said:

> Perfect idea, very good use of the Wednesday slot.

New date and place registered at
,
wednesday, Karlin 1/2, 1500 to 1700. (Note there is registry lock side
meeting just before, for domain name industry people.)

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

Re: [DNSOP] [Doh] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 10:06:21AM -0700,
 Ted Hardie  wrote 
 a message of 76 lines which said:

> This conflicts with SECDISPATCH, which will have a pretty serious impact on
> who might attend.  Scheduling these things is very hard, obviously. Given
> this topic, you may have to move outside the normal agenda time to get a
> reasonable shot at avoiding conflict.

I avoided conflicts with doh, dprive, dnsop and hrpc but avoiding all
conflicts is close-to-impossible. In the evening, people have
meetings, too.

I admit I'm not sure that Secdispatch is so important here. The
subject of the side meeting is not security-specific.

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

[DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Stephane Bortzmeyer]

[Resent with the correct list of working groups.]

[Sorry for the long list of working groups but the discussion already
started in different places.]

There are been some discussion about DoH (DNS-over-HTTPS, RFC 8484)
deployment and the risk of centralization of Internet services. (See
for instance drafts [this is not an endorsement]
draft-bertola-bcp-doh-clients, draft-reid-doh-operator and
draft-livingood-doh-implementation-risks-issues.)

It was suggested Reference necessary to have a
side meeting in Prague at IETF 104. I propose monday, 1400-1600 in
Tyrolka. The proposal is at
. You
are welcome to agree/disagree/meet in a bar instead.

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

[DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Stephane Bortzmeyer]

[Sorry for the long list of working groups but the discussion already
started in different places.]

There are been some discussion about DoH (DNS-over-HTTPS, RFC 8484)
deployment and the risk of centralization of Internet services. (See
for instance drafts [this is not an endorsement]
draft-bertola-bcp-doh-clients, draft-reid-doh-operator and
draft-livingood-doh-implementation-risks-issues.)

It was suggested Reference necessary to have a
side meeting in Prague at IETF 104. I propose monday, 1400-1600 in
Tyrolka. The proposal is at
. You
are welcome to agree/disagree/meet in a bar instead.

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

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Stephane Bortzmeyer]

On Sat, Mar 09, 2019 at 11:01:33PM -0800,
 Paul Vixie  wrote 
 a message of 32 lines which said:

> i have been away as long as possible, which means i was surprised
> that the IESG was willing to allow a document to standardize

I'm not surprised, since, in the last years, there have been a strong
increase in network neutrality violations, censorship through DNS,
privacy invasions, etc. I'm glad the IETF (not just the IESG) decided
to act and to develop techniques that can help to restore some sort of
access.

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

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Stephane Bortzmeyer]

On Sun, Mar 10, 2019 at 03:48:52PM +0900,
 Warren Kumari  wrote 
 a message of 281 lines which said:

> I think it would be very valuable to not conflate DNS-over-HTTPS
> (the protocol) with the "applications might choose to use their own
> resolvers" concerns.

I fully agree.

Applications using their own resolver is Bad, IMHO, but 1) it is
unclear what the IETF can do since it is outside of the protocol field
(may be documenting our concerns?) 2) it has little to do with DoH.

> Someone (it may have been Vittorio Bertola) coined the term DNS-over-Cloud
> (DoC)

Bert Hubert 


> 3: "resolverless DNS",

I personnaly don't agree with "resolverless DNS". There *is* a
resolver, just not the "usual" one.

> Also, I think that this topic would be better discussed in the DNSOP
> WG -

Again, I fully agree, since it is not DoH-specific.

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

[DNSOP] Making domains work even when connectivity fails (Was: the root is not special, everybody please stop obsessing over it

[Stephane Bortzmeyer]

On Fri, Feb 15, 2019 at 09:29:29AM -0500,
 Bob Harold  wrote 
 a message of 73 lines which said:

> I think in most solutions, if the name servers for "
> malware-c-and-c-as-a-service.com" and "com" are both unreachable,
> the domain should continue to resolve.  But if "com" is reachable,
> and says " malware-c-and-c-as-a-service.com" no longer exists, it
> should go away.

Any volunteer to write a problem statement for the "VIX.SU issue"?
Short version: "when I'm on the same network that at least one
authoritative name server of VIX.SU, I want this domain to work, even if there
is zero Internet connectivity to the outside world" Longer version:
"TODO (think of: is it automatic or not, does it require prior access
or not, phantom domains, etc)"

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

Re: [DNSOP] the root is not special, everybody please stop obsessing over it

[Stephane Bortzmeyer]

On Thu, Feb 14, 2019 at 01:57:14PM -0800,
 Paul Vixie  wrote 
 a message of 42 lines which said:

> the fact that i have to hotwire my RDNS cache with local zone glue
> in order to reach my own servers when my comcast circuit is down or
> i can't currently reach the .SU authorities to learn where VIX.SU
> is, should not only concern, but also embarrass, all of us.

I agree that this is an issue (as you said, the simple case of "my own
zone" is easily solved by stub and/or forward zones in BIND) but any
solution must take care of phantom domains. If I register
malware-c-and-c-as-a-service.com and it's taken down, the solution
should not make this domain to work after. (Except of course for
resolvers who decided to configure a stub zone for this domain.)

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt

[Stephane Bortzmeyer]

On Fri, Feb 15, 2019 at 09:34:16AM +,
 Jim Reid  wrote 
 a message of 19 lines which said:

> Why? From the client's perspective, there's no effective difference
> between these.

In the first case, you can talk with someone which you have some
relationship with (the ISP, typically).

> Their request was rejected for some policy reason and it doesn't
> really matter whose policy has been applied.

Well, it certainly matters to me. Think responsability,
accountability, consumer choice...

> Besides in situations where blocking is being done because of
> someone else's say so, it's highly likely that the DNS operator will
> be subject to some sort of injunction which prevents them from
> disclosing that such blocking is taking place.

Not "highly likely". It depends. Some censors are open in their
censorship (otherwise, RFC 7725 would be useless.)

Case study: in France, the list of "terrorist" domain names whose
blocking is mandatory is not public, but the fact that a domain is
blocked because of this list is not: the ISP returns a forged (sorry,
"substituted") specific IP address.

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

Re: [DNSOP] Fwd: New Version Notification for draft-mayrhofer-did-dns-01.txt

[Stephane Bortzmeyer]

On Fri, Feb 08, 2019 at 02:58:38PM +0100,
 Alexander Mayrhofer  wrote 
 a message of 59 lines which said:

> Feedback highly appreciated,

I think that it is an important work because it brings the power of
the DNS to many other identifier systems. So, I support it.

May be more examples could help people figure out the use cases? "My
Bitcoin address is at foobar.example" and then the Bitcoin software
would query _did.foobar.example and get
.

I note that there exists already non-standard (and probably not really
deployed) solutions in that space, some specific to a TLD



Regarding draft -01: it seems OK to me. The only problem I find:

> particularly the concerns around downgrade attacks when the record
> is not signed

Why downgrade attacks specifically? Without DNSSEC, a lot of attacks
are possible.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt

[Stephane Bortzmeyer]

On Thu, Feb 14, 2019 at 08:51:25PM +0100,
 Stephane Bortzmeyer  wrote 
 a message of 101 lines which said:

> Otherwise, I suggest to add an error code:

Ooops, I forgot one:

SERVFAIL Extended DNS Error Code 8 - No reachable authority 

   The resolver could not reach any of the authoritative name servers
   (or they refused to reply).  The R flag should be set.

Rationale: in draft -04, all SERVFAIL extended error codes are for
DNSSEC issues. In my experience, SERVFAIL happens also (and quite
often) for routing issues (most zones have all their authoritative
name servers in only one AS, sometimes even one prefix or, worse, one
rack).

We set the R flag because another resolver may not have the same
routing issues, BGP not being consistent between all sites.

True, an extended error code could be added after the RFC is
published, through "Specification required" but 1) it is easier to do
it now 2) it gives to the people who will implement the RFC a wider
view of the possible uses.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt

[Stephane Bortzmeyer]

On Thu, Feb 14, 2019 at 03:33:23PM -0500,
 Warren Kumari  wrote 
 a message of 388 lines which said:

> but how about:
> "The majority of these extended error codes are primarily useful for
> resolvers, to return to stub resolvers or to downstream
> resolvers. Authoritative servers may also use this technique to
> annotate errors (for example, REFUSED), but as of publication there
> are not as many of these defined"

OK

> > > 4.4.1.  NXDOMAIN Extended DNS Error Code 1 - Blocked
> > >
> > >   The resolver attempted to perfom a DNS query but the domain is
> > >   blacklisted due to a security policy.
> >
> > I tend to think it would be a good idea to separate the case where
> > the policy was decided by the resolver and the case where the
> > policy came from outside, typically from the local law (see RFC
> > 7725 for a similar case with HTTP).
> >
> > Rationale: in the first case (local policy of the resolver), the
> > user may be interested in talking with the resolver admin if he or
> > she disagrees with the blocking. In the second case, this would be
> > useless.

You did not reply to this one. It is inspired by a message from Petr
Špaček

explaining how extended DNS errors would be great to tell the user
whose fault it is (signature expired == no need to tell the resolver's
operator). I really think it is important to make the difference between:

* I blocked your request because that's _my_ policy
* I blocked your request because I'm compelled to do so, don't
  complain, it would be useless.

> > NOERROR Extended DNS Error Code 3 - Forged answer

> I'd really like to avoid the word "Forged"

I did not know it was pejorative (in french, "forgée", which has the
same origin, is not). So, what about "substituted answer"? Neutral
enough?

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt

[Stephane Bortzmeyer]

On Mon, Jan 07, 2019 at 12:30:10PM -0800,
 internet-dra...@ietf.org  wrote 
 a message of 44 lines which said:

> Title   : Extended DNS Errors
> Authors : Warren Kumari
>   Evan Hunt
>   Roy Arends
>   Wes Hardaker
>   David C Lawrence
>   Filename: draft-ietf-dnsop-extended-error-04.txt

Some remarks but before, note I think that it is very important that
we have a way to report more detailed error causes. One of the biggest
problems of DNSSEC is that there is no easy way for the resolver to
report to the application about a DNSSEC problem. So, the work on this
draft is essential.

Now, the problems:

It seems to me that this draft is mostly for resolvers, most planned
extended codes are useless for authoritative servers (except may be
REFUSED/Lame?).

I suggest to make that clear in the introduction:

These extended error codes are specially useful for resolvers, to
return to stub resolvers or to downstream resolvers. Authoritative
servers MAY use them but most error codes would make no sense for
them.

> Unless a protective transport mechanism (like TSIG [RFC2845] or TLS
> [RFC8094])

Why 8094, which does not have even one implementation, instead of
7858?

> 4.2.3.  SERVFAIL Extended DNS Error Code 3 - Signature Expired
>
>   The resolver attempted to perform DNSSEC validation, but the
>   signature was expired.

I suggest to replace "the signature was expired" by "a signature in
the validation chain was expired".

Rationale: which signature? What if a DS at the parent is sign with an
expired signature?

> 4.2.5.  SERVFAIL Extended DNS Error Code 5 - DNSKEY missing
>
>   A DS record existed at a parent, but no DNSKEY record could be found
>   for the child.

I suggest to replace "no DNSKEY record could be found for the child"
by "no DNSKEY record for this specific key could be found for the
child".

Rationale : the current text seems to imply this code is only when
there is no DNSKEY at all.

> 4.4.1.  NXDOMAIN Extended DNS Error Code 1 - Blocked
>
>   The resolver attempted to perfom a DNS query but the domain is
>   blacklisted due to a security policy.  The R flag should not be set.

The last sentence is touchy. If a stub is configured with two
resolvers, and one is fast but known for lying in some cases that you
disagree with, you may ask a cookie from the other parent (no, resolver).

> 4.4.1.  NXDOMAIN Extended DNS Error Code 1 - Blocked
>
>   The resolver attempted to perfom a DNS query but the domain is
>   blacklisted due to a security policy.

I tend to think it would be a good idea to separate the case where the
policy was decided by the resolver and the case where the policy came
from outside, typically from the local law (see RFC 7725 for a similar
case with HTTP).

Rationale: in the first case (local policy of the resolver), the user
may be interested in talking with the resolver admin if he or she
disagrees with the blocking. In the second case, this would be useless.

Otherwise, I suggest to add an error code:

NOERROR Extended DNS Error Code 3 - Forged answer

   For policy reasons (legal obligation, or malware filtering, for
   instance), an answer was forged.  The R flag should not be set.

Rationale: there is "NXDOMAIN Extended DNS Error Code 1 - Blocked" but
policy-aware resolvers (lying resolvers, in plain english) do not
always forge NXDOMAIN, they can also forge A or  answers.

See also the issue just before, about the need to differentiate
resolver policy from "upper" policy, law, for instance.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt

[Stephane Bortzmeyer]

On Thu, Feb 07, 2019 at 04:47:01PM +0100,
 Petr Špaček  wrote 
 a message of 129 lines which said:

> > 4.1.1.  NOERROR Extended DNS Error Code 1 - Unsupported DNSKEY Algorithm
> > 
> >The resolver attempted to perform DNSSEC validation, but a DNSKEY
> >RRSET contained only unknown algorithms.  The R flag should be set.
> > 
> > 4.1.2.  NOERROR Extended DNS Error Code 2 - Unsupported DS Algorithm
> > 
> >The resolver attempted to perform DNSSEC validation, but a DS RRSET
> >contained only unknown algorithms.  The R flag should be set.
> 
> Why R flag? This is not an error, resolution suceeded,

But without the AD flag.

> and there is nothing to retry. I propose change both cases to "The R
> flag should not be set."

In both cases, because another resolver may know other, different
algorithms and therefore succeed to validate.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Thu, Feb 14, 2019 at 04:58:38PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 126 lines which said:

> if an DNSSEC_enabled authotative server(no matter it is Alice or
> Bob) is evil and modifies DNS records, it will succeed because it
> has private key 

It is completely false. (You seem to think that online signing is the
only possibility but this is far from true.)

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Thu, Feb 14, 2019 at 04:31:35PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 74 lines which said:

> > for instance a DoH or DoT server that intentionally or
> > accidentally returns false data. DNSSEC can counter that.
>  
>  I dont understand why.
>  If a server intentionally returns false data , it can fake anything
>  because it owns the private key, DNSSEC does not help either.

So, you seem to not understand DNSSEC very well. I suggest you read
RFC 4033 and following. Summary: DNSSEC is designed so that the server
does not need the private key.

Also, "server" means two VERY different things in the DNS, resolvers
and authoritative. DNSSEC protects also against a lying intermediary
resolver.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Thu, Feb 14, 2019 at 04:11:20PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 102 lines which said:

> No. i might did not explain it clearly.

It was clear but you repeat the same stuff, without taking into
account the remarks (or the existing documents, such as
draft-bortzmeyer-dprive-resolver-to-auth). Both Paul Wouters and David
Conrad explained that the DNS is more complicated than that (think of
forwarders, for instance) and you did not address their remarks.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Thu, Feb 14, 2019 at 02:36:14PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 86 lines which said:

> i think both DNSSEC and DoH(or DoT) can protect DNS data,

"Protect" is like "security", a word so vague,  which includes so many
different (and sometimes contradictory) services that it is not very
useful. Writing "both DNSSEC and DoH(or DoT) can protect DNS data"
seems to imply that you did not think enough about the difference
between channel security and object security. This is really the
weakest point in your argumentation. (Yes, djb always make the same
mistake but he is a famous cryptographer so people forget and forgive
about his mistakes.)

> the fundmental point it to establish the trust chain and transit
> trust.

No. The entire point of DNSSEC is that you do not need to trust the
many servers that are between the validator and the origin.

> Regarding the case"secondary name servers mnaged by a different
> organisation", the servers can publish several TLSAs to distingush
> them.

I'm afraid you did not understand. Let me explain with concrete
examples. Suppose organisation Alice subcontracts a secondary name
server to organisation Bob (a very common use case).

1) What is Bob is evil and modify DNS records?
2) What is Bob is sloppy in security and its servers are cracked and
the attacker modify DNS records?

DNSSEC protects against both. DoT and DoH does not protect against
these issues.

> This idea is just a sketch model

The problem is that there are many sketch models floating around and
few serious proposals (and even less implemented and analyzed
proposals).

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Wed, Feb 13, 2019 at 10:51:00PM +0100,
 Vladimír Čunát  wrote 
 a message of 118 lines which said:

> Technically you can run DoT on whatever port you like.

> Example: with knot-resolver it's easy - you just add @443, either on
> side of server and/or on the side of forwarding over TLS.

The problem is that you cannot then share this port with HTTPS
services (the dkg draft on demultiplexing was abandoned, apparently
because it doesn't work). In a world of scarce IPv4 public addresses,
this is a serious problem.

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

Re: [DNSOP] I-D Action: draft-schaller-dnsop-lnp-00.txt

[Stephane Bortzmeyer]

On Wed, Feb 13, 2019 at 02:26:40AM -0800,
 internet-dra...@ietf.org  wrote 
 a message of 47 lines which said:

> Title   : Local Naming Protocol -- LNP (v.1.0)
> Author  : Christian Schaller
>   Filename: draft-schaller-dnsop-lnp-00.txt

You do not explain why you created this protocol when mDNS (RFC 6762)
and LLMNR (RFC 4795) exist. Without this explanation, we cannot see
the point of your protocol.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 03:32:37PM -0800,
 Paul Vixie  wrote 
 a message of 75 lines which said:

> by putting that text in and leaving it in, this becomes a political
> project not a technical one.

Everything we do is political, the Internet itself is a political
project. Thinking that communication is a good thing is political.

> as it happens, nothing stops a web browser or other such client from
> using DoT, and it's possible that the right answer was to say, DoT
> will answer every technical need that this RFC describes, but none
> of its political needs, and we don't want to be in the politics
> business.

DoT will be blocked in many networks, not DoH. That's why we need
both. DoT is technically better, DoH is more realistic in many
environments.

This choice is hardly limited to DNS. It is partly for the same reason
that we have whois and RDAP.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 02:45:54PM -0800,
 Paul Vixie  wrote 
 a message of 21 lines which said:

> i remember a time when the IAB would have said "no" to an internet
> standard which mandated deliberate loss of control by network
> operators.

Giving the many attacks against network neutrality, it seems
reasonable to me to develop techniques that make these attacks less
easy.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 02:18:39PM -0800,
 Paul Vixie  wrote 
 a message of 20 lines which said:

> > Right.   So what’s to stop other malicious traffic from doing the
> > same thing?
> 
> lack of an IETF-approved standard with planned implementation by a
> half dozen tech giants, means that other malicious traffic will not
> be able to hide in the crowd, and can be made subject to policy, and
> complaints.

An IETF standard make things easier for the implementer and increases
the chances of success (that's why we develop standards, after all)
but it is not the only way to "massive deployment including half dozen
tech giants". So, not having DoH would not stop evil name resolution.

> i want DoT to be used instead,

Then petition the many hotspots, hotels, cafes, corporations, etc,
that block everything but 443. It is because of them that we need DoH,
not just DoT.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 01:48:36PM -0800,
 Paul Vixie  wrote 
 a message of 46 lines which said:

> increased for political reasons.

There is nothing wrong with political reasons. Mass surveillance is a
political problem (privacy). DNS lies by ISPs is a political problem
(network neutrality). It is perfectly normal that IETF develops stuff
for political reasons. (Everybody have read RFC 8280?)

> google, ibm, cloudflare, cisco, and other so-called "public dns"
> providers will at some point choose whether to offer DoH from shared
> addresses, making those shared addresses into risks that the rest of
> us have to manage differently; or whether to dedicate DoH to well
> known addresses that can be outright blocked.

It seems to be an issue with DoC
,
not really DoH itself.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 10:34:19AM -0800,
 Paul Vixie  wrote 
 a message of 15 lines which said:

> > How can you be sure folks on your network aren’t already tunneling
> > their evil deeds through HTTPS?
> 
> netflow. such traffic _looks_ abnormal.
> 
> the deliberate design premise of DoH is that it look normal.

If TLS does its job, how can you make the difference between DoH and
EvilNonStandardNameResolutionProtocolRunningOverTLS?

There are some metadata that can help (such as sizes and timing) but
IETF continue to develop tricks like padding to make them as
inefficient as possible.

I would really like to know how you could detect
EvilNonStandardNameResolutionProtocolRunningOverTLS but not DoH?



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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 10:14:19AM -0800,
 David Conrad  wrote 
 a message of 100 lines which said:

> Why don’t you force folks on your network to install a certificate
> that would allow you to inspect TCP/443 outbound traffic?

There are probably many connected things where this is not
possible. But I don't think blocking DNS resolution (through DoT
blocking or DoH bashing) would help: malware learned a long time ago
how to work even in the most hostile (for them) environment, so
connected things will learn to do the same, in the same way that they
use STUN, TURN and other tricks to work around NAT.

So, I don't think Paul Vixie's plan will work: either you connect only
trusted devices to your network, or you block all outbound traffic for
nodes that must stay local (a thermometer or a camera MUST NOT talk to
the outside world at all).

(And, yes, I know, that today's connected devices talk a lot to remote
nodes. But it is evil.)




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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Wed, Feb 13, 2019 at 02:03:26PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 103 lines which said:

> that's ture. but in my view, if the trust chain is built, we can
> ensure a resolver(or a cache) is always talking to a identified
> server and the channel is always secure, then the content could not
> be tampered.

Several emails already mentioned cases where it is not true (relaying
through a forwarder - transitive trust is hard - or secondary name
servers mnaged by a different organisation - a common use case).

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Wed, Feb 13, 2019 at 02:08:19PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 58 lines which said:

> i prefer DoH because it can identify a server we are talking to and the 
> content is encrypted.

To learn about DoT, I suggest you read RFC 7858.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 08:32:28AM -0800,
 Paul Vixie  wrote 
 a message of 39 lines which said:

> i require all visitors, family members, employees, and apps to use
> the control plane i have constructed, which includes DNS
> surveillance and control.

Reminds me of a sentence which is awfully true: "applications on the
Internet now have to use the techniques of the botnets, just to work".

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 09:07:43AM -0500,
 Paul Wouters  wrote 
 a message of 23 lines which said:

> This idea is similar to DNScurve. The problem is that channel
> security does not help when you have an infrastructure of DNS
> caches,

Or when secondary name servers are not under the same organisation.


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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 03:56:04PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 546 lines which said:

> the child zone publishes a TLSA record instead of a DS record in the
> parent zone [RFC 6698 may need update]. The TLSA record contains the
> certificate that identifies the child zone.

The problem is that it would require all authoritative name servers of
a zone to have the same key. This is inconvenient in some setups, for
instance when part of the name servers is subcontracted. I suggest
that it is better to have a TLSA record per name server and not per
zone (draft-bortzmeyer-dprive-resolver-to-auth, section 2)

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 03:56:04PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 546 lines which said:

> I am considering extending the DoH protocal to authoritative
> servers.

Why DoH and not DoT? DoH is useful because 1) port 853 may be blocked
at the edge of the network 2) applications running in a Web browser
may need DNS data. But these two reasons do not apply to your use case
1) the resolver is often closer to the core and there is less risk
that 853 is blocked 2) there is no Web browser on the resolver.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 03:56:04PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 546 lines which said:

> DNSSEC is not necessary anymore

This is clearly false. DoH provides _channel security_ DNSSEC provides
_content security_ (or object security). This is a very important
difference in security (we have JWS even if we have HTTPS, for
instance).

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

[DNSOP] "The Forgotten Object Lesson Of The Dyn DDoS Attack"

[Stephane Bortzmeyer]

https://www.forbes.com/sites/forbestechcouncil/2018/12/19/the-forgotten-object-lesson-of-the-dyn-ddos-attack/

This article talks about "There have been discussions within the
Internet Engineering Task Force, the organization responsible for
developing and enhancing internet protocols, to come up with some
standard means of specifying and synchronizing these value-added
services" and I believe Cricket Liu refers to draft-woodworth-bulk-rr
(now expired, never adopted here).


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

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

[Stephane Bortzmeyer]

On Wed, Sep 19, 2018 at 07:24:25AM +1000,
 Mark Andrews  wrote 
 a message of 38 lines which said:

> As for scripts, you upgrade the tools those scripts use:
> curl(libcurl), wget, fetch for SH. File::Fetch for perl.  Similar
> for the other scripting languages. Very few applications actually
> make socket calls directly for http.

I hope it is true but I'm not so sure. Any hard data somewhere? My
purely anecdotal evidence is that I've seen "applications actually
make socket calls directly for http", one reason probably being it is
widely teached in schools.

HTTP/2 is a good thing here since it is much harder to do it yourself,
so people will rely on libraries :-)

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

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

[Stephane Bortzmeyer]

On Sun, Sep 16, 2018 at 03:26:56PM +0530,
 Mukund Sivaraman  wrote 
 a message of 66 lines which said:

> Adding resolver support (to resolvers that don't have it, i.e.,
> vs. RFC 1035) does not appear to break current DNS, i.e., it can be
> proposed now.

[Algorithm deleted]

The difficult thing is not to specify what the new resolvers will have
to do, but to describe what will happen with the current
resolvers. What will happen when "CNAME at apex" will be deployed,
assuming X % of the resolvers will not be upgraded?

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

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

[Stephane Bortzmeyer]

On Mon, Sep 17, 2018 at 03:51:34AM +,
 Evan Hunt  wrote 
 a message of 124 lines which said:

> I don't see how we can responsibly declare a new standard which, if
> followed, will break every prior implementation. Apex CNAME is the
> sort of solution that's clear, simple, and wrong.

+1

> We're going to need another type code.

Since the main use case is "people with a domain name such as
example.com, who wants https://example.com/ to actually work, and who
hosts the stuff at a CDN where the IP address is wildly variable so
they cannot use A or  records", I suggest that this use case is
better solved by using SRV records for HTTP. True, it seems
unrealistic that it will be specified and deployed but it is also the
case for the DNS "CNAME at apex" change.

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

Re: [DNSOP] Call for Adoption: draft-bortzmeyer-rfc7816bis

[Stephane Bortzmeyer]

On Thu, Aug 09, 2018 at 04:49:18AM -0400,
 Tim Wicinski  wrote 
 a message of 21 lines which said:

> Authors should upload a new version with the draft-ietf-dnsop-rfc7816bis 
> name.

Done (with a delay, sorry, I'm responsible).

DNS Query Name Minimisation to Improve Privacy
 draft-ietf-dnsop-rfc7816bis-00

Comments and remarks welcome, specially on the places marked TODO.
Current version at 

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

[DNSOP] We are really lazy in this group

[Stephane Bortzmeyer]

We slept for the last 35 years!

"the software originated in the early 1980s at the University of
California at Berkeley [...] Not much about the DNS protocol has
changed since then."

https://www.networkworld.com/article/3293006/internet/ns1s-private-dns-enables-modern-applications-devops-and-more.html

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

[DNSOP] [iesg-secret...@ietf.org: [Doh] Last Call: (DNS Queries over HTTPS (DoH)) to Proposed Standard]

[Stephane Bortzmeyer]

Not a dnsop work but it may interest people here.
--- Begin Message ---

The IESG has received a request from the DNS Over HTTPS WG (doh) to consider
the following document: - 'DNS Queries over HTTPS (DoH)'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2018-08-08. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   This document describes how to make DNS queries over HTTPS.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information: 
rfc7626: DNS Privacy Considerations (Informational - IETF stream)



___
Doh mailing list
d...@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--- End Message ---
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] [lau...@miscnote.net: difference between dns spoofing and dns hijacking?]

[Stephane Bortzmeyer]

Some work for draft-ietf-dnsop-terminology-ter? Define spoofing,
poisoning and hijacking?

--- Begin Message ---

I saw the info from google,

While the DNS hijacking involves a malware, the DNS Cache poisoning 
involves overwriting your local DNS cache with fake values that redirect 
your browser to malicious websites. ... Though DNS Cache Poisoning and 
DNS Hijacking are used interchangeably, there is a small difference 
between them.


Not very sure about the explanation.
Can you kindly expand it?

thanks.
___
dns-operations mailing list
dns-operati...@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-operations mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
--- End Message ---
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dns-capture-format

[Stephane Bortzmeyer]

On Fri, Jul 06, 2018 at 08:32:42PM -0400,
 Tim Wicinski  wrote 
 a message of 22 lines which said:

> This starts a Working Group Last Call for
> draft-ietf-dnsop-dns-capture-format

At IETF 99 in Prague, I implemented the version of this time
. Some problems were
raised and I think they are now addressed. C-DNS is quite different
now (much less mandatory things, for instance) and, in my opinion, the
document -07 is ready and useful. (Unfortunately, I didn't port my
work to the last draft.)


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

[DNSOP] QNAME minimisation on the standards track?

[Stephane Bortzmeyer]

Greetings. With more resolvers implementing QNAME minimisation, and
even turning it on by default, we thought that this is a good time to
update RFC 7816 and make it a standard. In order to get things moving,
we have published a very early draft draft-bortzmeyer-rfc7816bis-00
that is mostly the original RFC but with a few questions and holes
added (see the text near the strings "TODO"). If folks in the WG is
interested, feel free to comment in the non-GitHub repo listed in the
draft, or here on the list.



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

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

[Stephane Bortzmeyer]

On Mon, Jun 25, 2018 at 12:27:17PM +0200,
 Benno Overeinder  wrote 
 a message of 27 lines which said:

> This starts a Working Group Last Call for draft-ietf-dnsop-attrleaf

I've read -10 and it seems OK. It solves a real issue, and does it
properly.

Editorial: I would prefer all occurrences of "right-most" to be
replaced by "most general", to emphasize that it is not the position
which matters, it is the closeness to the root.

Editorial: 'that is they are the "top" of a DNS branch, under a
"parent" domain name.' I assume that "top" is used instead of "apex"
because the sentence does not always refer to the top of a zone?

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

Re: [DNSOP] DNSOP Presentation "The Camel"

[Stephane Bortzmeyer]

On Tue, Mar 20, 2018 at 07:29:50AM +,
 tjw ietf  wrote 
 a message of 94 lines which said:

> At the end of Tuesday's session we're having Bert Hubert from Power DNS
> give a talk on what he views "The Camel".

Unlike the popular saying
, camels
are extraordinary animals, well adapted to their harsh environment

and usable for many things, even war
. If the DNS is a camel,
this is great!

> "In past years, DNS has been enhanced with DNSSEC, QName
> Minimization, [...]

I dispute the idea that QNAME minimization is an addition. It is not a
change in the protocol, and it was even possible from the beginning
(Section 5.3.3 of [RFC1034] or Section 7.2 of [RFC1035] do NOT mandate
QNAME maximimization, it is just an accidental evolution).

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

Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

[Stephane Bortzmeyer]

On Mon, Mar 19, 2018 at 07:49:45PM +,
 Viktor Dukhovni  wrote 
 a message of 30 lines which said:

> The 'delegation-only' flag does not *by itself* prevent parent
> domains from answering authoritatively for their child domains, but
> it could make "certificate-transparency" more tractable for DNSSEC.

I don't think that you replied to Bob's remark. He said that the
proposal is useless because it addresses only the case of "answering
authoritatively for their child domain", not the "directing child
domain to someplace".

> Without the proposed flag, one would also have to log denial of
> existence

There is no denial of existence in the attack explained by Bob.

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

Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

[Stephane Bortzmeyer]

On Mon, Mar 19, 2018 at 08:22:03AM -0400,
 Paul Wouters  wrote 
 a message of 57 lines which said:

> We have just submitted a draft aimed at increasing the security of
> the DNSSEC with respect to the power that parental zones have over
> their children.

I'm opposed to this idea.

> While the root and TLD zones are asumed to be almost exclusively
> delegation-only zones,

This is unrelated. You mix two different things, the administrative
issue and the technical one (every subdomain in its own zone). gouv.fr
is administratively a delegation from .fr but is in the same zone.

> the root zone operator (or any level higher in the hierarchy than
> the target victim) could briefly remove the NS and DS records, and
> create a "legitimate" DNS entry for "www.example.org"

That's the DNS. It is a tree. Protecting childs against the parent is
a non-goal, or otherwise we should move to some alternative to DNS
(Namecoin is cool).

> The aim here is to counter the argument that the root key and TLD
> keys are all powerful and under government control, and can therefor
> never be trusted.

I've read the draft and still can understand nothing in this sentence.

> 2) Allow the creation of DNSSEC transparency logs

May be mentioning draft-zhang-trans-ct-dnssec would be nice?

>  The DELEGATION_ONLY flag has a strong overlap in functionality with
>  the Public Suffix List as both signal a formal split of authority
>  between parent and child.

May be mentioning the defunct DBOUND working group would be a good
idea?

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