Re: [DNSOP] NXDOMAIN and RFC 8020

[sthaug]

>>> I think this is another point in favor of doing QNAME minimization.
>>> RFC7816 (technically experimental, but recommended.)
>>>
>>> It kind of makes the query order moot; the resolver looks up the shorter
>>> name first even while resolving the longer name.
>>>
>>
>> Is there any data or even a hint of how widely that experiment has been
>> deployed or implemented?
>>
> 
> It's on by default in (recent versions of) a number of popular open source
> DNS resolver implementations (BIND, Unbound, Knot).

And PowerDNS Recursor, see

https://doc.powerdns.com/recursor/settings.html#qname-minimization

Steinar Haug, AS2116

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

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

[sthaug]

> The DoH operators who have made public statements (google and cloudflare
> are two I am aware of), have specifically indicated that NO OTHER HTTPS
> TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}.

I have seen such a public statement from Google. Where have you seen a
similar statement from Mozilla/Cloudflare?

I asked for such a statement from Mozilla recently (on this mailing
list). No answer yet.

Steinar Haug, AS2116

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

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

[sthaug]

>> I think this is a mischaracterization of the debate, which actually
>> started because of a third position that you don't mention: Mozilla's
>> public statement that in the future they will force (or, at least, make as
>> a default - clarification requests haven't solved the doubt yet) Firefox
>> users to use a remote resolver chosen within a shortlist that they will
>> manage.
>>
> 
> I'm not sure where you have attempted to clarify this point (I think we've
> been clear on this point at
> https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/)

Unfortunately this is not clear at all.

The web page at the link above says: "We'd like to turn this on as the
default for all of our users.". Combined with the remaining text on
the web page, the only conclusions I can draw is that

- Mozilla would like to turn on DoH by default, invisible to the user
(the user gets this configuration without making a choice).
- When DoH is turned on, by default Cloudflare will be used as the DoH
provider.

If these conclusions are correct they are precisely why some of us
find the Mozilla/Firefox stance completely unacceptable.

If these are *not* the conclusions we should draw about Firefox and
Mozilla's plans, you badly need to update the web page on the link
above. You could also at the same time clarify whether Firefox will
use DoH resolvers that are on the same IP addresses as other non-DoH
content.

Steinar Haug, AS2116

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

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[sthaug]

> The DHCP solution is compatible only with trust relationship two.   So if
> the IETF were to recommend this way of configuring DoH and DoT, we would
> essentially be throwing away the privacy benefits of DoH and DoT (assuming
> that such benefits exist).

I don't believe people are saying that the IETF should *recommend*
this way of configuring DoH and DoT - they're saying the DHCP option
should be *available*.

Are you saying that all DHCP options introduced so far have been the
IETF recommended way of configuring things?

Are you saying that no new DHCP option can be made available unless
the IETF recommends this way of configuring things?

Both of these sound equally unreasonable/unlikely to me...

Steinar Haug, AS2116

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

Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

[sthaug]

> > Speaking only for myself - I have done many BIND upgrades without config
> > file changes (and I basically expect this to work).
> 
> i apologize, again, for the config file from last-bind8, not working in 
> all cases with first-bind9. i don't work at ISC any more, but i think i 
> can safely predict that this won't happen again.

Well now - BIND8 and BIND9 are rather different. However, I have
upgraded multiple times on BIND9 without any config change - it's
certainly possible I've been spoiled. I *did* get bitten recently
when, on a specific server with no IPv6 connectivity, I had to add

listen-on-v6{ none; };

to get things running. But that's really my only complaint, and a
rather small one at that!

Steinar Haug, AS2116

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

Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

[sthaug]

> If just to spread rumors, I heard the following as early as November, 2016.  
> One of the issues is that operators update code without updating 
> configuration files.  I.e., a BIND upgraded today might be using a 
> configuration file from the pre-managed-key days.

Speaking only for myself - I have done many BIND upgrades without config
file changes (and I basically expect this to work).

Steinar Haug, AS2116

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

Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

[sthaug]

> Can you provide a technical reason for per-address IPv6 reverse DNS?
> 
> Where I work, we bulk populate reverse v4 DHCP pools just so we know that
> they are pools. We aren't going to bother doing that with v6 because
> everything is a pool, except for a relatively small number of statically
> configured switches and servers and suchlike.

Much the same here. The only IPv6 addresses getting reverse DNS will
be statically configured addresses.

Steinar Haug, AS2116

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

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

[sthaug]

> > adding complexity in the middle of any system increases the size of an
> > attack surface.
> 
> +1 This was described in detail several times (see for instance this
> report
> )
> and we already saw its consequences for the security and stability of
> the Internet
> 
> (in danish)
>  (in
> french)

Agreed about the general comment about adding complexity. However,
consider the fact that quite a few operators (I happen to work for
one of them) *already* have this complexity in the system, and the
use of RPZ would actually *reduce* complexity.

Steinar Haug, AS2116

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

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

[sthaug]

> > No, this draft simply specifies what operators are already doing. Not
> > because they are intent on destroying trust in the DNS or the Internet,
> > but because they are forced to do this by governments, they need to
> > protect their own network, they would like to protect their customers,
> > and lots of other reasons.
> 
> There are two things you mixed together:
> 
> 1) industry based filtering of DNS - a commercial opt-in service offering
> 
> 2) government mandated filtering of DNS - A misguided breakage of
> protocol forced upon operators.

I "mixed them together" because we use the same mechanism in both
cases. This is where RPZ (which we don't use today) would be handy.

> And 1) should not need to break DNSSEC. IETF should come up with a
> better solution for signaling a DNS lookup might be unhealthy for
> the enduser.

As others have pointed out, we don't only want to signal back to the
user "don't do this DNS lookup" - we want to prevent the lookup from
reaching the authoritative servers. "unhealthy for the end user" is
just one of several reasons why a DNS lookup might be blocked.

> For 2) if it breaks DNSSEC, that is fine. Governments will learn that
> ISPs are not the right tools for censorship, and endnodes will simply
> bypass the ISP DNS resolver.

Government mandated DNS filtering has been in use here in Norway for
more than 8 years, and there is absolutely no sign that the government
will learn what you suggested. Endnodes have been able to bypass the
ISP DNS resolvers all these years, the information on how to do this
has been freely available - and yet a large majority of the endnodes
continue to use the ISP DNS resolvers.

Steinar Haug, AS2116

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

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

[sthaug]

Since operator participation was mentioned,



> this draft actively destroys trust in the DNS, which reduces trust in the
> Internet overall.

No, this draft simply specifies what operators are already doing. Not
because they are intent on destroying trust in the DNS or the Internet,
but because they are forced to do this by governments, they need to
protect their own network, they would like to protect their customers,
and lots of other reasons.

It's possible that the ball will be dropped on this one like it was for
NAT. That would be stupid, IMHO.

Steinar Haug, AS2116

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

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

[sthaug]

> To be clear and to boil it down: This draft publishes a method to supply
> different answers to different users and to hide the truth of those lies to 
> the same users.

So do for instance BIND views.

> Unless a registry, court or resource owner authorizes this, it is
> lying, cheating, "fraudy" and definately deceptive. (like a cockroach
> when exposed to light)

This is, ultimately, always a local decision.

In "my" network I have at times returned incorrect answers to queries
for .domain - in order to mitigate the effects of "water
torture" attacks. Yes, this is definitely lying. The alternative is
to do nothing, and let the attack on the authoritative name servers
continue. I'm afraid your characterization above isn't going to change
this.

> I think that if people knew what we were talking about and
> truly understood the issues, there would be an uprising.

I think most people have little or no idea what DNS is about. However,
if they truly understood the issues, they would probably also understand
the need for RPZ.

Steinar Haug, AS2116

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

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

[sthaug]

> > So if this is the IP of a phishing site or the IP of an command and
> > control host that tells its bot to execute criminal action you still
> > valid the accuracy of the answer higher then possible damage this
> > could do to your user?
> > 
> yes. 
> 
> In your example, ethically, it is a problem that should be addressed on IP, 
> not on DNS
> 
> It is never okay to tell lies.

Unfortunately the real world isn't that simple.

Sometimes you are required by law to tell lies. Case in point: Various
domains belonging to Pirate Bay and several other torrent providers
have been explicitly blocked in Norway - explicitly as in: The biggest
ISPs in Norway (I happen to work for one of these) have been told by
the Oslo district court to block access to a list of domains supplied
by the court, and that this is to be implemented through DNS blocking
(lies, if you will).

It doesn't matter whether I *like* this or not, and it also doesn't
matter whether the domains in question are easily available by using
OpenDNS, Google Public DNS, running your own name server, etc. ISPs
are still required to block access as long as the verdict from the
Oslo district court is valid.

Today this blocking is done without using RPZ. Having RPZ standardized
and implemented in more DNS software would make it possible to perform
the same blocking as mentioned above with fewer moving parts and thus
a simpler system less likely to have "interesting" failure modes.

Note that it makes absolutely no difference to the blocking described
above whether the RPZ draft is published as an RFC or not - in both
cases the blocking would still be performed, because it is required
by law.

Steinar Haug, AS2116

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

Re: [DNSOP] warning

[sthaug]

> Regarding "Message-ID header"  - factually, over 80% of all spam 
> (I have not bothered to do the actual number check, it is probably closer
> to 99.99% but I am erring on the side of caution - as this is science
> and not opinion, it is what it is)
>  
> - All contain a Message-ID header. 

You're saying that most spam messages contain a Message-ID header. This
is not in conflict with what vjs wrote:

> Among the 399 messages sent toward v...@rhyolite.com in the last 24
> hours (usual weekend decrease), 43 or more than 10% lacked Message-ID
> headers.  For fun, I looked at all 43 and found only the single false
> positive, for a false positive rate of 0.023%, which is both not bad
> and 10X or 100X higher (worse) than usual.

so he's saying that most messages without a Message-ID header is spam.

>From my own statistics, I'd have to agree - lack of a Message-ID header
is indeed a strong predictor of spam.

Steinar Haug, AS2116

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

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-isp-ip6rdns

[sthaug]

> > The point of this document is not to make normative requirements.
> 
> But it does: 'Best practice is that "Every Internet-reachable host
> should have a name"'.

I agree. Especially with IPv6 in mind, "Every Internet-reachable host
should have a name" is *not* best practice.

Steinar Haug, AS2116

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

Re: [DNSOP] relax the requirement for PTR records?

[sthaug]

  Absolutely not (recommend ISPs should delegate).  While it would be good
  if an ISP offered this to interested parties, don't expect to saddle the
  operator with yet another service that expects the customer to
  reply/provide out-of-band information.
 
 The point of delegating is is that in most cases the customer won't populate 
 it, and in the cases where they want to, it is now their problem, not the 
 ISP's problem. So Paul gets his I am a luser signal, and I get my PTR tree. 
 All nodes are not equal on the Internet, but that should be by choice, not by 
 design. 
Putting my ISP hat on:

- Our business customers can already have reverse zones delegated if
they ask.

- For our residential customers, should we be expected to delegate
lots of reverse zones that mostly wouldn't be populated? I can easily
see how this could lead to extra calls to customer support, extra
logging of failures on name servers, etc. In short, most likely extra
cost. Since residential service is a very low margin game, anything
which adds to the cost of providing the service is a non-starter. Not
gonna happen.

Steinar Haug, AS 2116

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

Re: [DNSOP] Rejecting Practice for Theory

[sthaug]

  so, my hope is that we could recommend against machine-generated PTR's,
  and recommend in favour of PTR delegation when a customer requests it,
  all while understanding that ISP's will do whatever they want after they
  see whatever recommendations we make.
  
 
 I would vastly prefer to get a signed nxdomain from an isp then some BS
 machine generated record...

Machine generated PTR records are a non-starter for IPv6 in any case.
We're planning to skip them entirely.

 It would be super-annoying for delegations to nameservers that do not
 exist to occur for these, because not only will there be trillions of
 them but I get to wait for them to time out, so delegation to cpe for
 example seems like a non-starter.

This is my worry too. Even if there is a protocol which ensures that
delegations only take place to working name servers - what do you do
when the customer goes off net, or acquires a new dynamic address?
Does the protocol take care to *remove* the old delegation then? In
general I would be worried about a (probably) much higher error rate
for such delegations.

Steinar Haug, AS 2116

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

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

[sthaug]

  Putting my ISP hat on, I'd have to agree with the security/stability
  reasons (and several others I can think of). As of today, I have zero
  incentive to let my residential customers create their own PTR records.
 
 Putting my customer hat on: I want PTR for my machines (many hosters
 allow it, like Linode or Gandi). Is it sufficient incentive for a
 provider? N customers want it, with N  0

Business customers can already have static IPv6 PTRs, no problem.

Residential customers and the proposed scheme of dynamically creating/
updating PTRs: N would have to be sufficiently large, or there would
have to be other reasons (e.g. competitive pressure). Even if these
conditions were fulfilled, it would still be prioritized against many
other requirements.

In other words: Don't hold your breath.

Steinar Haug, AS 2116

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

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

[sthaug]

  Putting my ISP hat on, I'd have to agree with the security/stability
  reasons (and several others I can think of). As of today, I have zero
  incentive to let my residential customers create their own PTR records.
  Better tools and systems may change this, but it would in any case be
  *way* down on the priority list.
 
 Considering that PTRs generated by ISPs are too often useless,
 are you saying you won't provide PTRs?

For our residential customers, we provide IPv4 PTRs which indicate
that this is a dynamic address. We *don't* plan to provide IPv6 PTRs
for those same customers.

Steinar Haug, AS 2116

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

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

[sthaug]

  marka Or we could stop debating whether we should maintain it and
  marka assume that if we give people tools that will allow it to be
  marka automatically maintained they will eventually deploy them.
  
  For providers with millions or tens of millions of end customers, any
  system that just lets any customer scribble in DNS is unlikely to be
  employed for security or stability reasons.
 
 For in-addr.arpa you already have a PTR records.  Allowing the end
 user to set its content does not increase the amount of data you
 are serving.  It does increase the amount of churn in the zone.

Putting my ISP hat on, I'd have to agree with the security/stability
reasons (and several others I can think of). As of today, I have zero
incentive to let my residential customers create their own PTR records.
Better tools and systems may change this, but it would in any case be
*way* down on the priority list.

Steinar Haug, AS 2116

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

Re: [DNSOP] new version of IPv6 rDNS for ISPs

[sthaug]

 One observation is that the delegation to CPE routers (home gateways) is
 contradictory to RFC6092:
 
  REC-8   By DEFAULT, inbound DNS queries received on exterior
interfaces MUST NOT be processed by any integrated DNS
resolving server.
 
 Not suggesting delegation to CPE shouldn't happen, but would it would
 negate this requirement.

DNS amplification attacks caused, at least partly, by DNS proxies in
CPEs is a significant problem. Note that this is often due to the CPEs
being open to *recursive* queries. A delegation would only need replies
to zones the CPE was authoritative for - however, I'm afraid such a
distinction would be lost on many CPE manufacturers.

There are also ISPs that block outgoing DNS queries to (residential)
CPEs, precisely because of DNS amplification attacks by these CPEs.

Steinar Haug, Nethelp consulting, sth...@nethelp.no

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

Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document

[sthaug]

  I can't agree with this statement.  As others have said, the practice of 
  using a search list to allow 'ssh foo.bar' to reach 'foo.bar.example.com' 
  isn't going anywhere, and there are a lot of people that make extensive use 
  of the convenience.
 
 It needs to die because it's fundamentally broken.   Vanity TLDs will only 
 make it worse.   I understand that there are sites that use it and people who 
 are accustomed to it.   I don't pretend that we can stop them.   We can, 
 however, explain the negative consequences of doing this (some of which might 
 be specific to systems with multiple interfaces), and recommend that they 
 transition away from that practice.   And recommendations for systems with 
 multiple interfaces can be chosen in such a way as to allow search lists to 
 break even more.

I routinely use short names (and thus search lists) in my work. I am
aware of vanity domains, and of RFC 1535. Have I stopped using short
names and search lists? No, the convenience is just too great.

In trying to stop the use of short names and search lists I believe
you're trying to fight human nature. It's a waste of time, and unlikely
to be productive.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] m.root-servers.net DNSSEC TCP failures

[sthaug]

A small followup:

 So it looks like the IPv4 instance refuses TCP, while the IPv6 instance
 handles it okay. No filters in the way at my end. The m.root-servers.net
 instance looks like it is in Paris or thereabouts - but there is quite
 a bit of difference between the instances: IPv4 (highly variable ping,
 RTT 700 ms or more) and IPv6 (ping steady at RTT 44-45 ms).

Should of course have checked hostname.bind, which reveals:

% dig @202.12.27.33 hostname.bind ch txt +short
M-CDG-3
% dig @2001:dc3::35 hostname.bind ch txt +short
M-CDG-4

So it seems my guess of Paris or thereabouts wasn't too far off. And
M-CDG-3 seems to have problems with TCP.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS

[sthaug]

  I can't comment on that directive in particular (if indeed such a 
  directive with that name exists, per later mail) but in general I find 
  it a feature that a document with operational focus addressed to the 
  whole Internet should steer clear of regional policy requirements.

Agreed.

 Then commentary needs to be added to the Boiler Plate that no regional 
 issues were addressed in the testing - hence a test bed based on the 
 requirements for operating a data-center in the EU were not considered.  

I see no way that Directive 95/46/EC of the European Parliament and of
the Council of 24 October 1995 on the protection of individuals with
regard to the processing of *personal data and on the free movement of
such data* (my emphasis) is relevant for this requirements document.

 That's OK but it means that many in the EU may not be able to deploy 
 those protocols in their operating environments until those specific 
 implementations are tested now that the audit world is waking up to its 
 responsibilities under the digital evidence requirements globally.

I note that this is a directive from 1995. Yes, we have seen effects of
this directive, even here in Norway (not a EU member) - but I think you
are going way beyond what the EU directive is meant to cover when you
say it is relevant for the name server requirements document.

My opinins only, IANAL.

 If this turns out to be true - it will effect all IETF standards in use 
 today in the EU.

The EU directive deals with explicitly *personal data* and the storage
and movement of such data. It does not deal with *all data*.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A different question

[sthaug]

  it in their products or services.  Peter Koch did provide an interesting 
  data point that warrants further investigation (20-35% of queries having DO 
  bit on seems a bit high to me) and someone else responded privately that 
 
 I think Peter's data point sure warrants further investigation, yes.

From my own limited investigations (less than 10 servers, but millions
of DNS queries thus hopefully somewhat statistically significant):

  Authoritative servers: 35 - 45%
  Recursive servers: In the noise (less than 0.5%)

which seems to indicate that there are quite a few recursive servers
out there that set the DO bit when querying authoritative servers.

One of the authoritative servers measured is a ccTLD server for .no.

Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop