Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Paul Vixie]

Vernon Schryver wrote:

By "signed" I guess you mean signed by the resolver itself with some
sort of public key ... If so, I agree that works,


yes.


but I still don't see how that is as good as two dig's with one to
a resolver trusted to give the truth.


there will in my model be only one resolver, and while it may or may not 
be trusted to tell the truth, it may or may not also be trusted to tell 
a useful lie. that is, truth has value, and some lies also have value, 
for example an RPZ answer of NXDOMAIN when the qname is a DGA. but right 
now we have no authentication of the lies, while we do have it for the 
truth (if DNSSEC is used). so, i am conflating two issues in my 
stick-figure of the moment: authentication of lie source and content, 
and, the ability of an end-user via resolv.conf or API to tell her local 
applications what lie-source to believe, if any.



Whenever that in-band DNS truth red light *might* blink, you'll want
a trusted resolver available so that when the light does blink your
application gets honest DNS truth or honest RPZ lies.  ...


no, really. it's blink red first, and then either go offline or remain 
online, according to the user's risk tolerance. for me it's go offline.


there is no other resolver present to ask-also or ask-instead or ask-after.

rpz must become hop-by-hop authenticated, since there's no end-to-end 
for it. this may become the first valid use for dnscrypt.



Principled objections to RPZ cannot be answered by RPZbis including
truth with lies.  That is because an application must consistently
choose either truth or possible RPZ lies.  Choosing RPZ lies for
security and privacy defenses makes including the truth in RPZbis
answers a sham and waste of bandwidth.  On the other hand, an application
choosing truth makes the RPZ lies a waste of bandwidth.


i'm on a different trail entirely. we have to include the truth if it's 
dnssec signed, since the client will know we're lying if we do 
otherwise. but, in any valid RPZ deployment, the lies we tell are of 
value to the client, so we must include those. and, because those lies 
can otherwise be MITM'd, we must authenticate them hop-by-hop (that is, 
from the rDNS to the stub.)



Which gets back yet again to the only place I think RPZ belongs, which
is in a verifying resolver that you trust to do only the RPZ lying
that you want (and so where you don't need that red light except when
debugging).


between arp spoofing and ip-source spoofing, a stub has no reason to 
trust its rDNS -- that's why DNSSEC has to be visible end-to-end for 
DNSSEC-aware applications. we need to authenticate the source of a lie, 
since otherwise it could be inserted by some on-LAN malicious actor. 
while we might be able to use SIG(0) and the KEY RR for this, and that 
would be a form of DNSSEC, the form would be degenerate, since it's not 
the same as end-to-end source authentication of the DNS data as having 
been created by the legitimate operator of the zone whose key signed it. 
RPZ is divorced entirely from the zone whose key normally signs data 
having the owner = qname. so we have to authenticate hop by hop.


--
P Vixie

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Lanlan Pan]

Yes, I agree, in fact the *online cache rate* is small (0.12% queries), LRU
& TTL works fine.
SWILD not save many online cache size, because of the queries rate.
And Temporary Domain Names/ All Names: 41.7% for 7 days statistics,  the
rate can be about 10% for 1 day statistics. Because temporary domain names
expire after TTL time.  Ralf has similar curious.

The problem is:

1)  cache size
Recursives commonly cache "all queried domain in n days" for some
SERVFAIL/TIMEOUT condition, which has been documented in
https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-01
The subdomain wildcards cache are needlessly,  we can use heuristics
algorithm for deciding what to cache, or just use simple rule like "select
domain which queies time > 5 in last n days".
We can use SWILD to optimize it, not need to detecting, just remove items
which SWILD marked, to save cost.

2) cache miss
All of temporary subdomain wildcards will encounter cache miss.
Query xxx.foo.com,  then query yyy.foo.com, zzz.foo.com, ...
We can use SWILD to optimize it,  only query xxx.foo.com for the first time
and get SWILD, avoid to send yyy/zzz.foo.com queries to authoritative
server.

3) DDoS risk
The botnet ddos risk and defense is like NSEC aggressive wildcard, or NSEC
unsigned.
For example,  [0-9]+.qzone.qq.com is a popular SNS website in China, like
facebook. If botnets send "popular website wildcards" to recursive,  the
cache size of recursive will rise, recursive can not just simply remove
them like some other random label attack.
We prefer recursive directly return the IP of subdomain wildcards, and not
rise recursive cach, not send repeat query to authoritative.

Ted Lemon 于2017年8月16日周三 下午8:54写道：

> El 16 ag 2017, a les 0:19, Lanlan Pan  va escriure:
>
> We analyzed our recursive query log, about 18.6 billion queries from
> 12/01/2015 to 12/07/2015.
>
> We found about 4.7 Million temporary domains occupy the recursive's cache,
> which are subdomain wildcards from Skype, QQ, Mcafee, Microsoft,
> 360safedns, Cloudfront, Greencompute...
>
> Temporary Domain Names/ All Names: 41.7%
> Queries for Temporary Domain Names/ All Queries: 0.12%
>
>
> Okay.   So it sounds like you have an algorithm for detecting temporary
> domain names.   It seems to me that a quicker solution to your problem is
> to publish an operational document describing that algorithm and proposing
> ways that recursive caches can use it to prune such domains from the cache
> early.
>
> I'm curious if you studied the behavior of existing recursive caches in
> the presence of these domains: do they in fact cache at the rate you
> predict they will?   The reason I ask is that I know that my own company's
> cache, which is widely deployed in the exact scenario you are describing,
> has a pretty sophisticated set of heuristics for deciding what to cache.
> It would surprise me if it exhibited the behavior you are concerned about.
>
> BTW, your paper is behind a paywall, so please don't cite it as a reason
> to do anything in the IETF.   If you want the IETF to take action based on
> what is in the paper, you need to publish it openly.
>
> --
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] fragile dnssec, was Fwd: New Version

[Mark Andrews]

In message <20170816230917.4475.qm...@ary.lan>, "John Levine" writes:
> In article <20170816071920.ba2c98287...@rock.dv.isc.org> you write:
> >> A colleague says "If TLDs allowed UPDATE messages to be processed most
> >> of the issues with DNSSEC would go away. At the moment we have a whole
> >> series of kludges because people are scared of signed update messages."
> 
> Someone is wildly overoptimistic.  
> 
> The problem I run into over and over again is that I run someone's DNS
> and other services, but I am not the registrant and I am not the
> registrar, I just run the DNS.  Either I have to walk the registrant
> through the process of installing DNSSEC keys, or she has to give me
> her registrar account password, neither of which scales.  Slightly
> more automatic processing of updates for which I do not have the
> credentials will not help.

Or you can have credentials to allow the hoster to update the DS
records alone.  UPDATE allows for fine grained credentials.  Named
has had fine grain update support for over a decade now.  You can
specify keys that can do everything and you can specify keys that
can just update a single type.  This isn't hard to do.

The DNS hoster gives the registrant the public key they use to
update DS records.  This is passed to the registrar which uses it
to verify UPDATE requests that change the DS records.  You can do
similar with TSIG but that is a shared secret between three parties.

This is like using master keys and more specific keys.  The only
reason this isn't done today is that we aren't using UPDATE and are
forcing all the transactions through a web interface.

Mark

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

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Vernon Schryver]

> From: Paul Vixie 

> > A network that routes requests to 8.8.8.8 to inject DNS lies will also
> > arrange to ignore or pervert any DNS-in-band tell-the-truth signaling.
> > Without access to a trustworthy resolver, tell-the-truth signaling is
> > useless because you can't trust it.
> 
> i would like to be able to know that i can't trust it, rather than
> merely assuming that i can't trust it, as happens today. if neither the
> truth nor the lie is signed, i can make a red light blink, or even go
> offline, refusing the local edition of the social compact ("if you want
> to use the internet you have to accept dns answers w/o provenance.")

By "signed" I guess you mean signed by the resolver itself with some
sort of public key (perhaps DLV, double dnssec, one of the other secure
DNS schemes, or something new) or with TSIG using a symmetric key
previously shared with the resolver.  (Having the stub verify DNSSEC
to validate the truth and turn off the red light would make the stub
a lot like a verifying resolver.)

If so, I agree that works,

but I still don't see how that is as good as two dig's with one to
a resolver trusted to give the truth.

Whenever that in-band DNS truth red light *might* blink, you'll want
a trusted resolver available so that when the light does blink your
application gets honest DNS truth or honest RPZ lies.  But with that
trusted verifying resolver you can use 2 digs and don't need the
protocol or implementation costs of inband RPZ truth and you needn't
to surmount principled IETF opposition to sanctioning RPZ.

Principled objections to RPZ cannot be answered by RPZbis including
truth with lies.  That is because an application must consistently
choose either truth or possible RPZ lies.  Choosing RPZ lies for
security and privacy defenses makes including the truth in RPZbis
answers a sham and waste of bandwidth.  On the other hand, an application
choosing truth makes the RPZ lies a waste of bandwidth.

Which gets back yet again to the only place I think RPZ belongs, which
is in a verifying resolver that you trust to do only the RPZ lying
that you want (and so where you don't need that red light except when
debugging).  All other uses of RPZ should be considered attacks on
your security and privacy.  (I think that's a short form of the agreed
words that I'm waiting to be told to add to the draft.)


Vernon Schryverv...@rhyolite.com

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Paul Vixie]

Vernon Schryver wrote:

A network that routes requests to 8.8.8.8 to inject DNS lies will also
arrange to ignore or pervert any DNS-in-band tell-the-truth signaling.
Without access to a trustworthy resolver, tell-the-truth signaling is
useless because you can't trust it.


i would like to be able to know that i can't trust it, rather than 
merely assuming that i can't trust it, as happens today. if neither the 
truth nor the lie is signed, i can make a red light blink, or even go 
offline, refusing the local edition of the social compact ("if you want 
to use the internet you have to accept dns answers w/o provenance.")



No jurisdiction will allow foreign visitors to bypass local filters
forever, because foreign visitors blab both the banned data and the
banned tools.


as a frequent visitor to china, my verizon wireless roaming service is 
tunnelled back to the USA. i can read facebook, search google, and so 
on. verizon isn't a pirate -- they have a license to operate in china 
and they honor the terms of that license. but they don't sell this 
service inside china.


i expect more, not less, arrangements of this kind going forward, now 
that other nation-states are making decisions about internet content 
filtering for their citizens. note that i blogged on this specific 
point, and mentioned rpz, recently:


http://www.circleid.com/posts/20170718_nation_scale_internet_filtering_dos_and_donts/


... Isn't there
talk about China blocking all tunnels including those of foreigners?


not that i've heard. china has a delicate balancing act, and they do not 
seem to want to completely discourage tourism, even if that means there 
are leaks in the great firewall as a result. on wifi or wired, they 
don't know who isn't a citizen. on LTE or GSM, they do. but the tunnel i 
use is slow, and expensive for both verizon and i. i'd like to offer 
china the opportunity to carry both dns truth and dns lies, in the same 
packet, with one of them a little harder to get at using older software, 
and with newer software having a switch, "do you trust policy having 
this key?" i expect that for android and iOS devices sold in china, this 
switch would be hardwired "on".


this reflects my broader belief that neither the open source community, 
or the internet technology community, will ever be taken seriously by 
the chinese gov't if we tell them how they should run their country's 
internet or its connections to the rest of the world. if they want to be 
able to express policy data more reliably using DNS than will be 
possible in a ubiquitous-DNSSEC scenario, then we ought to provide that, 
and encourage engineers from within china to help define, model, test, 
develop, and deploy it. this would ease the complexity burden for 
companies selling internet devices and services inside china. it will 
not make anybody in the world less autonomous than they already aren't.



Even with the acquiescence of regimes, there are insurmountable practical
technical and non-technical issues in providing both RPZ filtered and
raw DNS answers, configuring applications, and ensuring that citizens
don't get foreign, uncensored versions of applications.  It's one thing
for a regime to allow foreigners to use foreign services (which I claim
never lasts), and quite another thing for in-country operators to
expect government censors to understand and believe that citizens can't
use the truthful results in DNS responses.  If you were a DNS operator
in China, would you ever allow your resolver to give truthful answers
about some domains in any form or in response to any signaling?--of course
not!


as a provider i would, whether in china or elsewhere, follow the law.

--
P Vixie

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

Re: [DNSOP] fragile dnssec, was Fwd: New Version

[John Levine]

In article <20170816071920.ba2c98287...@rock.dv.isc.org> you write:
>> A colleague says "If TLDs allowed UPDATE messages to be processed most
>> of the issues with DNSSEC would go away. At the moment we have a whole
>> series of kludges because people are scared of signed update messages."

Someone is wildly overoptimistic.  

The problem I run into over and over again is that I run someone's DNS
and other services, but I am not the registrant and I am not the
registrar, I just run the DNS.  Either I have to walk the registrant
through the process of installing DNSSEC keys, or she has to give me
her registrar account password, neither of which scales.  Slightly
more automatic processing of updates for which I do not have the
credentials will not help.

R's,
John

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Vernon Schryver]

> From: Paul Vixie 

> well, yes, but a directive in /etc/resolv.conf saying what lies to 
> trust, or whether to trust all of them, or whether to trust none of 
> them, would be a way for a system operator or owner to set response 
> policy for all applications.

> if an application wants a different kind of lies than is the default in 
> /etc/resolv.conf, it will need API hooks to say so.

That's what I meant.
It could be done today with small, upward compatible changes to
libresolv to allow the application to specify resolver IP addresses,
port numbers, and TSIG keys.  (and equivalently in Windows)

(Note that TSIG keys in resolv.conf would help provide a trustworthy
path to your trusted resolver for reasons unrelated to RPZ.)
(well, getting libresolv to sign and check TSIG might not be that small.)


> > On the other hand, there is already signaling that provides both DNS
> > truth and lies.  A UNIX shell command like `alias honest "dig @8.8.8.8"`
> > implements kludge "signaling" to get the DNS truth, while straight
> > `dig` gets the possible lie.
>
> alas, this is unreliable. 

A network that routes requests to 8.8.8.8 to inject DNS lies will also
arrange to ignore or pervert any DNS-in-band tell-the-truth signaling.
Without access to a trustworthy resolver, tell-the-truth signaling is
useless because you can't trust it.

If you have a trustworthy path to a trustworthy verifying resolver,
then by definition you trust that resolver to do the things you
want with RPZ and everything else, and so none of your applications
need both answers.
With a trustworthy resolver, you don't need in-band trugh signaling
except for debugging, and all of the many people who have debugged RPZ
installations have not needed more than log files and `dig` to different
resolvers and resolver views so far.


> > The SOA added by RPZ to the additional section is perfectly sufficient
> > to signal the honest presence of an RPZ lie.
>
> well, yes. but it may be the law of the land in some countries that 
> citizens accept DNS lies, whereas foreign visitors can accept DNS truth. 
> so i'd like the protocol to carry both (lies and truth), with 
> policy-level digital signatures on the lies, to be sure they are coming 
> from the place we're expecting our lies to come from.

No jurisdiction will allow foreign visitors to bypass local filters
forever, because foreign visitors blab both the banned data and the
banned tools.  We've a very long history of this in print media.  Recall
that the Iron Curtain borders took an extremely dim view of smuggling
subversive literature.  And didn't Tailand recently sanction some
foreigners for lese magesty in forgien on-line media?  Isn't there
talk about China blocking all tunnels including those of foreigners?

Even with the acquiescence of regimes, there are insurmountable practical
technical and non-technical issues in providing both RPZ filtered and
raw DNS answers, configuring applications, and ensuring that citizens
don't get foreign, uncensored versions of applications.  It's one thing
for a regime to allow foreigners to use foreign services (which I claim
never lasts), and quite another thing for in-country operators to
expect government censors to understand and believe that citizens can't
use the truthful results in DNS responses.  If you were a DNS operator
in China, would you ever allow your resolver to give truthful answers
about some domains in any form or in response to any signaling?--of course
not!

We're seeing something like this happen with the European demands that
the "rights to be forgotten" apply accross borders.


Vernon Schryverv...@rhyolite.com

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

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Warren Kumari]

On Wed, Aug 16, 2017 at 4:05 AM, Ralf Weber  wrote:
> Moin!
>
> On 16 Aug 2017, at 2:44, Warren Kumari wrote:
>>> If it's a commonly-used name, I suspect the more straightforward
>>> "prefetching" should suffice in practice:
>>> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-hammer/
>>> Several popular recursive servers already implement the feature.
>>> Some of them even enable it by default.
>>>
>>
>> One of the main outstanding items on the "Stop! Hammer Time!" document
>> that we need to clean up the implementation section (Appendix A), but
>> it does note that at least Unbound (NLNet Labs), OpenDNS, and ISC BIND
>> 9.10 implement this.
> From how I read the document and understand the implementations none of
> those implements the actual draft, but instead they have implementations
> that do some sort of prefetching. If that is the case you can add Nominum
> Cacheserve to the list,

Awesome!

> but I really think we should do some more general
> document describing prefetching as a concept and not just one way how to
> do it with a hammer ;-).

Yeah, we keep meaning to go back and fix up the document. I think that
it (and, even more so,  the discussions) has already served it's
primary purpose - it led to this being implemented. But, I think that
it would be good if we now update it to explain what is now
implemented, and how...

I must admit that I some of my hesitance has been because I'm still
entertained by the "joke", and know that I need to just get over this
:-)

W
>
> So long
> -Ralf



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [DNSOP] Status of "let localhost be localhost"?

[Warren Kumari]

On Wed, Aug 2, 2017 at 2:02 PM, Robert Edmonds  wrote:
> Ted Lemon wrote:
>> But we are arguing that "localhost" should be treated specially by every 
>> piece of software that looks at it, when its default meaning is "look up 
>> localhost in the DNS and connect to one of the addresses that you get in 
>> response."
>
> RFC 6761 §6.3 already says that "localhost" should be treated specially
> by pretty much every piece of software that looks at it. But especially:
>
>2.  Application software MAY recognize localhost names as special, or
>MAY pass them to name resolution APIs as they would for other
>domain names.
>
>3.  Name resolution APIs and libraries SHOULD recognize localhost
>names as special and SHOULD always return the IP loopback address
>for address queries and negative responses for all other query
>types.  Name resolution APIs SHOULD NOT send queries for
>localhost names to their configured caching DNS server(s).
>
> (In practice, "localhost" already does get treated specially, especially
> by operating systems that place a "Name Service Switch" or similar
> component in front of the DNS stub resolver.

Yup, you would think so -- unfortunately, this seems less true than
we'd expect (or hope!)

Around 0.3% of responses from Google Public DNS are for "localhost".
As an honest DNSSEC-validating resolver, Google Public DNS returns
NXDOMAIN for queries of localhost. (and all its subdomains). If you
ask with DO set, it returns the root NSEC records proving there is no
such domain (yes, this disagrees with the SHOULD in 6.3.4 of RFC6761).

As with many things in the DNS, the real world is messier than we'd --
I would have hoped that most systems would be answering locally for
queries for localhost, and never asking the DNS, but this turns out
not to be as true as we would have liked. I think that this supports
the case for the localhost document; this behavior should be firmed
up. It also exposes the fact that an application naively resolving
"localhost" and trusting the answer (for security purposes) is not
currently safe.

W


> If you put
> "http://localhost/; into your browser bar, you shouldn't see a DNS query
> for "localhost" leave your machine.)
>
> Doesn't "Application software MAY recognize localhost names as special"
> already give more than enough permission for browser developers to treat
> "localhost" (and any subdomain of "localhost") specially, for instance
> by hardcoding the names to a loopback address, or filtering the result
> from the system's name resolver to verify that only a loopback address
> is used? Or only allowing the "Secure Context" flag to be set when the
> localhost name resolves to a loopback address.
>
> draft-west-let-localhost-be-localhost-03 upgrades the requirements in
> RFC 6761 §6.3 to make them much stricter, for all applications,
> converting SHOULDs to MUSTs, etc. So we're not arguing about whether
> localhost "should" be treated specially, but whether it MUST be treated
> specially, by all applications. Can the W3C not impose stricter
> requirements on browser developers even if 6761 doesn't impose mandatory
> treatment for "localhost"?
>
> Maybe a smaller addition to RFC 6761 §6.3 would be sufficient for the
> W3C? Something like:
>
> Application software specifications MAY require that application
> software recognize localhost names as special.
>
> But that seems weird because it's arguably just a specific case of
> requirement #2.
>
> --
> Robert Edmonds
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Paul Vixie]

Vernon Schryver wrote:

From: Paul Vixie



some time before bad people get around to using dnssec to bypass rpz,
the spec will have to evolve to allow new signalling ("i want to hear
both the truth and the lie, and please sign the lie with our shared key
so i'll know it's from you").


I disagree.  The last year has shown there there is limited appetite
in the IETF for RPZ work


i think we have to keep trying until and unless the co-chair say to stop.


A second issue concerns the use and purpose of the DNS.  No applications
that are not DNS debugging or forensic tools want both DNS truth and
lies.  All ordinary applications want an IP address and sometimes
application protocol data such as in SRV, MX, TLSA, and TXT.  ...


well, yes, but a directive in /etc/resolv.conf saying what lies to 
trust, or whether to trust all of them, or whether to trust none of 
them, would be a way for a system operator or owner to set response 
policy for all applications. the resolver is a dns-aware application.



Users of applications might want either truth or RPZ lies, but not both
except for debugging and forensics.  Those user preferences can vary
depending on the application.


if an application wants a different kind of lies than is the default in 
/etc/resolv.conf, it will need API hooks to say so. i predict that the 
getdnsapi team would offer such hooks if there were an underlying 
protocol with knobs like that. obviously "dig" will always just print 
both the truth and the lies, and let /dev/stdout sort out the meaning.



On the other hand, there is already signaling that provides both DNS
truth and lies.  A UNIX shell command like `alias honest "dig @8.8.8.8"`
implements kludge "signaling" to get the DNS truth, while straight
`dig` gets the possible lie.


alas, this is unreliable. i've been hooked up to networks with policy at 
the IP layer causing 8.8.8.8 requests to be rerouted to a local DNS 
server with advertising (NXDOMAIN substitution) support. considering 
that google's original motive for creating the 8.8.8.8 service in the 
first place was that various rDNS services were giving locally-faked 
responses to "www.google.com/A", i think this shows the slipperiness of 
the slope, in neon glowing detail.



The SOA added by RPZ to the additional section is perfectly sufficient
to signal the honest presence of an RPZ lie.


well, yes. but it may be the law of the land in some countries that 
citizens accept DNS lies, whereas foreign visitors can accept DNS truth. 
so i'd like the protocol to carry both (lies and truth), with 
policy-level digital signatures on the lies, to be sure they are coming 
from the place we're expecting our lies to come from.


--
P Vixie

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Paul Vixie]

Davey Song wrote:

If any operator would like to implement SWILD without DNSSEC or NAT44
without IPv6, It's OK. It maybe a good solution in their network for
their custormer. I do know many people and solutions walk around DNSSEC,
IPv6 (due to IPsec) and TLS for surveillance issues. But IETF as a
worldwide standard body has its position on the technical path towards a
better Internet.


agreed. and, see also:

https://mailarchive.ietf.org/arch/msg/ietf-announce/ObCNmWcsFPNTIdMX5fmbuJoKFR8

noting that DNSSEC isn't a form of confidentiality, the general spirit 
of the IAB's position as linked above, supports a co-goal of end-to-end 
authenticity. i see no reason to expend community development effort, or 
to add complexity costs, on alternatives in whole or in part to DNSSEC, 
unless it's a complete replacement protocol, or complete abandonment of 
the goal itself.


--
P Vixie

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Vernon Schryver]

> From: Paul Vixie 
 
> some time before bad people get around to using dnssec to bypass rpz,
> the spec will have to evolve to allow new signalling ("i want to hear
> both the truth and the lie, and please sign the lie with our shared key
> so i'll know it's from you"). 

I disagree.  The last year has shown there there is limited appetite
in the IETF for RPZ work

A second issue concerns the use and purpose of the DNS.  No applications
that are not DNS debugging or forensic tools want both DNS truth and
lies.  All ordinary applications want an IP address and sometimes
application protocol data such as in SRV, MX, TLSA, and TXT.  They
don't want and generally can't deal with multiple answers, as demonstrated
by the very few applications that look past the first IP address from
gethostbyname() (or modern replacements) even when the first IP address
fails.  Except for debugging or forensic tools, the application code
itself should not and even if the IETF says it should, will not care
about more than the first usable DNS result.

Users of applications might want either truth or RPZ lies, but not both
except for debugging and forensics.  Those user preferences can vary
depending on the application.  A user of ssh might want the truth,
because ssh has its own authentication system that is more secure than
DNSSEC.  The same user might choose RPZ filtering for smtp and http.
To facilitate such user choices, it would be good if applications could
tell stubs to use an alternate /etc/resolv.conf.

On the other hand, there is already signaling that provides both DNS
truth and lies.  A UNIX shell command like `alias honest "dig @8.8.8.8"`
implements kludge "signaling" to get the DNS truth, while straight
`dig` gets the possible lie.  (Note that a single system can host both
honest and RPZ resolvers.  BIND with views can distiguish requests for
truth from requests for lies with TSIG keys and answer appropriately.
You can include TSIG keys in dig commands.)

That kludge, dual-dig "signalling" would work with future RPZ installations
with real "give me both" signaling, old RPZ installations, and covert
DNS liars.  Even if a future version of RPZ has real "give me both"
signaling, you will always need and will reach first for dual digs.


The SOA added by RPZ to the additional section is perfectly sufficient
to signal the honest presence of an RPZ lie.


Vernon Schryverv...@rhyolite.com

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

Re: [DNSOP] Status of "let localhost be localhost"?

[Ted Lemon]

El 16 ag 2017, a les 6:17, Mike West  va escriure:
> In the commit linked above, I've adopted the second and third paragraphs with 
> minor wording changes. It's not really clear to me where the crux of the 
> first paragraph lies. IMO, malware is pretty clearly out of scope for 
> software's security decisions, as anything running on the local machine with 
> privilege equal to (or exceeding!) your own is basically impossible to 
> defeat. Are there scenarios in which you think that's not the case, at least 
> insofar as this draft is concerned?

That's why I mentioned sandboxing.   A process running on the local host, 
inside a sandbox, listening on a local port, could be reachable by processes 
that aren't sandboxed, or are running in other sandboxes.   So trusting 
localhost provides a way for a sandboxed process to screw you, basically.   I 
don't know how serious a threat this is, but I think the idea that the set of 
trust zones on a single host is flat is not valid, and that's why I actually 
don't think that, even with this document published and in wide use, 
"localhost" should be considered trustworthy.

A slightly less vulnerable approach would be to allow reserved ports on 
localhost to be trusted, but to not trust other ports, on the basis that 
something that can get a reserved port has privileges.   This is still 
questionable, since a trusted sandboxed app could be compromised, but it's at 
least a smaller attack surface.

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Ted Lemon]

El 16 ag 2017, a les 0:19, Lanlan Pan  va escriure:
> We analyzed our recursive query log, about 18.6 billion queries from 
> 12/01/2015 to 12/07/2015.
> We found about 4.7 Million temporary domains occupy the recursive's cache, 
> which are subdomain wildcards from Skype, QQ, Mcafee, Microsoft, 360safedns, 
> Cloudfront, Greencompute...
> 
> Temporary Domain Names/ All Names: 41.7%
> 
> Queries for Temporary Domain Names/ All Queries: 0.12%

Okay.   So it sounds like you have an algorithm for detecting temporary domain 
names.   It seems to me that a quicker solution to your problem is to publish 
an operational document describing that algorithm and proposing ways that 
recursive caches can use it to prune such domains from the cache early.

I'm curious if you studied the behavior of existing recursive caches in the 
presence of these domains: do they in fact cache at the rate you predict they 
will?   The reason I ask is that I know that my own company's cache, which is 
widely deployed in the exact scenario you are describing, has a pretty 
sophisticated set of heuristics for deciding what to cache.   It would surprise 
me if it exhibited the behavior you are concerned about.

BTW, your paper is behind a paywall, so please don't cite it as a reason to do 
anything in the IETF.   If you want the IETF to take action based on what is in 
the paper, you need to publish it openly.

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Mikael Abrahamsson]

On Wed, 16 Aug 2017, Davey Song wrote:


Accroding to your description, I feel that IPv6 has better chance to win
than its "brother" DNSSEC. LoL


Currently they're both winning, and in kind of the same fashion.

https://www.google.com/intl/en/ipv6/statistics.html

Clients are sitting behind DNSSEC validating resolvers, but there are few 
zones to validate (apart from in a few markets, like .se and .cz). Clients 
are more and more getting IPv6 enabled, but the long tail content is not 
being enabled, and neither is the enterprise.


So generally, enterprise is problematic in both spaces.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Davey Song]

Accroding to your description, I feel that IPv6 has better chance to win
than its "brother" DNSSEC. LoL

On 16 August 2017 at 14:48, Mukund Sivaraman  wrote:

> On Wed, Aug 16, 2017 at 08:21:37AM +0200, Mikael Abrahamsson wrote:
> > On Wed, 16 Aug 2017, Mukund Sivaraman wrote:
> >
> > > 24 / 500 top domains (4.8%)
> > > 20548 / 1 million top domains (2.05%)
> > >
> > > (12 years after introduction of 403{3,4,5})
> >
> > https://stats.labs.apnic.net/dnssec/XE?o=cXAw1x1g1r1
> >
> > 20% of European users is behind a validating resolver, in some countries
> > it's 70% plus.
> >
> > So this is now happening, albeit at a not high enough pace. But at least
> > it's going in the right direction, and I do believe that there is enough
> > people behind validating resolvers that people can't mess up signing
> their
> > zone and push away blame on who needs to fix things.
> >
> > So at least there is benefit in signing your zone now, there wasn't as
> much
> > before when nobody was validating.
>
> The validating resolver is half of the system.
>
> DNSSEC is brittle. It has an all-or-nothing behavior (that's what it was
> designed for) that many businesses cannot afford to bank on if something
> were to go wrong. An administrative error or signer software bug on the
> authoritative side can take the whole zone down and every service with
> it (as DNS is at the head of network activity). Software is still not
> perfect, so I don't know how this can change - I see practical signer
> bugs still that take down the zone entirely. It's also still painfully
> inconvenient to update parent zones, that makes fixing mishaps
> difficult. The amount of damage that a break in DNSSEC validation chain
> could do is far greater than other implementations of crypto such as TLS
> where it is limited to a service.
>
> (Note that I'm not advocating against DNSSEC, as much as this email may
> sound so. The things I mention are practical issues that I see as an
> implementor.)
>
> A colleague says "If TLD’s allowed UPDATE messages to be processed most
> of the issues with DNSSEC would go away. At the moment we have a whole
> series of kludges because people are scared of signed update messages."
>
> Mukund
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Lanlan Pan]

Ralf Weber 于2017年8月16日周三 下午4:22写道：

> Moin!
>
> On 16 Aug 2017, at 6:19, Lanlan Pan wrote:
>
> > We analyzed our recursive query log, about 18.6 billion queries from
> > 12/01/2015 to 12/07/2015.
> >
> > We found about 4.7 Million temporary domains occupy the recursive's
> > cache,
> > which are subdomain wildcards from Skype, QQ, Mcafee, Microsoft,
> > 360safedns, Cloudfront, Greencompute...
> >
> > Temporary Domain Names/ All Names: 41.7%
> > Queries for Temporary Domain Names/ All Queries: 0.12%
> So you are designing a protocol change for 0.12% of your queries? IMHO
> not a
> good use of engineering time.
>

The temporary domain name's rate > 40%.

Every xxx/yyy/zzz.foo.com query must be sent to Authoritative Nameserver
for the subdomain wildcard same answer, we can try to reduce this cost, and
shorten the response laterncy.

>
> Details in: Dealing with temporary domain name issues in the DNS
> > <
> https://www.computer.org/csdl/proceedings/iscc/2016/0679/00/07543831-abs.html
> >
> >
> > <
> https://www.computer.org/csdl/proceedings/iscc/2016/0679/00/07543831-abs.html
> >
> > The operational problem is, subdomain wildcards waste recursive cache
> > capacity. Existing solution to the problem is not adequate in
> > recursive
> > operating environment at present, because of low DNSSEC deployment.
> Sorry can't read that, but from the abstract and your emails I think the
> main
> flaw in your thinking is that you want to cache all the records,
> regardless of
> how often they are queried. That is not how caching resolvers work.
> Records that
> are not used frequently and most of these signalling queries are one
> time queries
> just expire from the cache, either by LRU mechanism or TTL.
>

Yes, LRU and TTL can expire from the cache, which were also discussed in
the paper.

Recursives commonly cache "all queried domain in n days" for some
SERVFAIL/TIMEOUT condition, which has been documented in
https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-01
The subdomain wildcards cache are needlessly,  and we can make some
optimization.


> So long
> -Ralf
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Davey Song]

On 12 August 2017 at 23:42, Paul Vixie  wrote:

>
>
> failing that level of commitment, the IETF ought to kill DNSSEC altogether.
>
> this is very similar to the "shall we had IPv6's features to IPv4, since
> V6 is
> taking so long to deploy, and these features are badly needed?" debate.
>
>
+1.

If any operator would like to implement SWILD without DNSSEC or NAT44
without IPv6, It's OK. It maybe a good solution in their network for their
custormer. I do know many people and solutions walk around DNSSEC, IPv6
(due to IPsec) and TLS for surveillance issues. But IETF as a worldwide
standard body has its position on the technical path towards a better
Internet.

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

Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Ralf Weber]

Moin!

On 16 Aug 2017, at 6:19, Lanlan Pan wrote:


We analyzed our recursive query log, about 18.6 billion queries from
12/01/2015 to 12/07/2015.

We found about 4.7 Million temporary domains occupy the recursive's 
cache,

which are subdomain wildcards from Skype, QQ, Mcafee, Microsoft,
360safedns, Cloudfront, Greencompute...

Temporary Domain Names/ All Names: 41.7%
Queries for Temporary Domain Names/ All Queries: 0.12%
So you are designing a protocol change for 0.12% of your queries? IMHO 
not a

good use of engineering time.


Details in: Dealing with temporary domain name issues in the DNS



The operational problem is, subdomain wildcards waste recursive cache
capacity. Existing solution to the problem is not adequate in 
recursive

operating environment at present, because of low DNSSEC deployment.
Sorry can't read that, but from the abstract and your emails I think the 
main
flaw in your thinking is that you want to cache all the records, 
regardless of
how often they are queried. That is not how caching resolvers work. 
Records that
are not used frequently and most of these signalling queries are one 
time queries

just expire from the cache, either by LRU mechanism or TTL.

So long
-Ralf

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Lanlan Pan]

Mukund Sivaraman 于2017年8月16日周三 下午1:45写道：

> On Fri, Aug 11, 2017 at 10:39:50AM -0400, Matthew Pounsett wrote:
> > It sounds like you're assuming that SWILD would be supported by caching
> > servers that do not support DNSSEC or NSEC aggressive use.  Why do you
> > expect implementers would adopt SWILD before adopting these much older
> > features?
>
> (Without commenting about SWILD)
>
> It does not have to be due to implementation support alone. Many
> operators stick to unsigned zones. There are many reasons, some of which
> I'd mentioned in the unsigned NSEC thread. Resolvers have to deal with
> cache pollution and unnecessary upstream queries, but they have no
> control over whether the authoritative zones are signed.
>
> 2 mails up this thread, there is a comment about "New features are
> provided only by the latest version of the protocol." This seems to mix
> unrelated things together. The latest version of DNS (if there's such a
> thing) doesn't mandate operational use of DNSSEC. Use of unsigned zones
> is not obsolete and may well outlive us. Most zones today are unsigned
> and a carrot like NSEC agressive use is unlikely to change the level of
> adoption of DNSSEC significantly.
>
+1
DNS Poison Attack risk such as Brazilian Bank Targeted By Phishing Site And
DNS Poisoning
is
the greatest motivation to deploy DNSSEC.

>
> Alexa Top domains and DNSSEC:
>
> 24 / 500 top domains (4.8%)
> 20548 / 1 million top domains (2.05%)
>
> (12 years after introduction of 403{3,4,5})
>
> Mukund
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Ralf Weber]

Moin!

On 16 Aug 2017, at 2:44, Warren Kumari wrote:
>> If it's a commonly-used name, I suspect the more straightforward
>> "prefetching" should suffice in practice:
>> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-hammer/
>> Several popular recursive servers already implement the feature.
>> Some of them even enable it by default.
>>
>
> One of the main outstanding items on the "Stop! Hammer Time!" document
> that we need to clean up the implementation section (Appendix A), but
> it does note that at least Unbound (NLNet Labs), OpenDNS, and ISC BIND
> 9.10 implement this.
>From how I read the document and understand the implementations none of
those implements the actual draft, but instead they have implementations
that do some sort of prefetching. If that is the case you can add Nominum
Cacheserve to the list, but I really think we should do some more general
document describing prefetching as a concept and not just one way how to
do it with a hammer ;-).

So long
-Ralf

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Paul Vixie]

Lanlan Pan wrote:

(Without commenting about SWILD)

Is your RPZ a mixture ?


no.


Doesn't RPZ rewrite DNS answer, break DNSSEC validation ?


the I-D advises against this. some implementations offer a switch to 
rewrite DNSSEC-signed results. i don't use this myself, and i recommend 
against its use. my reasoning is that if the initiator indicates a 
desire for dnssec meta data, and there is in fact dns metadata, then any 
lie will be transparently obvious, and you should not in that case tell 
that lie.


some time before bad people get around to using dnssec to bypass rpz, 
the spec will have to evolve to allow new signalling ("i want to hear 
both the truth and the lie, and please sign the lie with our shared key 
so i'll know it's from you"). i figure we have a few years to get it 
done. it's one of the first things this WG will take up if an RFC is 
published on the current protocol, at which point vernon and i have 
agreed to surrender change control.


thank you for giving me this platform to explain the dnssec dilemma 
faced by rpz, along with my position, and my expectations. RPZ is not 
meant to be a censorship tool and will not, and should not, work as one. 
DNS filtering must be seen as a value-add by its user community or else 
it should be, and will in fact be, nonfunctional.



Should we give up , or we shouldn't ?


see #1, #4, especially #7, and #12 from .

your lacks of respect and of professionalism is noted.

--
P Vixie

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Mark Andrews]

In message <20170816064855.GB16977@jurassic>, Mukund Sivaraman writes:
> On Wed, Aug 16, 2017 at 08:21:37AM +0200, Mikael Abrahamsson wrote:
> > On Wed, 16 Aug 2017, Mukund Sivaraman wrote:
> >
> > > 24 / 500 top domains (4.8%)
> > > 20548 / 1 million top domains (2.05%)
> > >
> > > (12 years after introduction of 403{3,4,5})
> >
> > https://stats.labs.apnic.net/dnssec/XE?o=cXAw1x1g1r1
> >
> > 20% of European users is behind a validating resolver, in some countries
> > it's 70% plus.
> >
> > So this is now happening, albeit at a not high enough pace. But at least
> > it's going in the right direction, and I do believe that there is enough
> > people behind validating resolvers that people can't mess up signing
> their
> > zone and push away blame on who needs to fix things.
> >
> > So at least there is benefit in signing your zone now, there wasn't as
> much
> > before when nobody was validating.
>
> The validating resolver is half of the system.
>
> DNSSEC is brittle. It has an all-or-nothing behavior (that's what it was
> designed for) that many businesses cannot afford to bank on if something
> were to go wrong. An administrative error or signer software bug on the
> authoritative side can take the whole zone down and every service with
> it (as DNS is at the head of network activity). Software is still not
> perfect, so I don't know how this can change - I see practical signer
> bugs still that take down the zone entirely. It's also still painfully
> inconvenient to update parent zones, that makes fixing mishaps
> difficult. The amount of damage that a break in DNSSEC validation chain
> could do is far greater than other implementations of crypto such as TLS
> where it is limited to a service.
>
> (Note that I'm not advocating against DNSSEC, as much as this email may
> sound so. The things I mention are practical issues that I see as an
> implementor.)
>
> A colleague says "If TLDs allowed UPDATE messages to be processed most
> of the issues with DNSSEC would go away. At the moment we have a whole
> series of kludges because people are scared of signed update messages."

And there is even a IANA assign SRV prefix to allow UPDATE messages
to be directed to directed to a server other than those that are
answering the queries.  Apple was good enough to get it registered
several years ago.  SIG(0) and TSIG UPDATE messages are forwardable
so all the TLD operator needs to do is to redirect the messages to
the appropriate registrar, based on the records being updated, for
processing then return the reply.

Named forwards both types of messages and returns the replies so
this is all technically possible.

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

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

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Paul Vixie]

Mukund Sivaraman wrote:

DNSSEC is brittle.


then let's fix it.

or give up on it.

--
P Vixie

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Lanlan Pan]

(Without commenting about SWILD)

Is your RPZ a mixture ?

Doesn't RPZ rewrite DNS answer, break DNSSEC validation ?

Should we give up , or we shouldn't ?


Paul Vixie 于2017年8月16日周三 下午2:30写道：

>
>
> Mukund Sivaraman wrote:
> ...
> >
> > Alexa Top domains and DNSSEC:
> >
> > 24 / 500 top domains (4.8%)
> > 20548 / 1 million top domains (2.05%)
> >
> > (12 years after introduction of 403{3,4,5})
>
> we should give up.
>
> or we shouldn't.
>
> not a mixture.
>
> --
> P Vixie
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Paul Vixie]

Mukund Sivaraman wrote:

On Tue, Aug 15, 2017 at 11:29:56PM -0700, Paul Vixie wrote:

we should give up.

or we shouldn't.

not a mixture.


I'm not saying we should give up.. but it's going to be a while before
we get to an utopia of maximal DNSSEC deployment. In the meantime, there
are practical problems that need mitigation.


anybody who needs secure denial of existence, of wildcards or other 
data, should deploy dnssec.


anybody who needs their networking partners to have this, should urge 
their partners to deploy dnssec.


if we don't believe that this can be done, then we should give up on dnssec.

there is no middle road here.

--
P Vixie

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Mikael Abrahamsson]

On Wed, 16 Aug 2017, Mukund Sivaraman wrote:



The validating resolver is half of the system.

DNSSEC is brittle.


Absolutely. But before we were in a situation where people signed zones, 
screwed it up, and then the (sometime single) ISP running a validating 
resolver got the run-around "must be wrong at your end, nobody else is 
complaining" and the zone signing was never fixed.


Now I think we're past that. There are enough users behind validating 
resolvers nowadays that you can't get away with getting your signing 
wrong and blaming others.


Yes, we need better APIs so applications can tell the user what went 
wrong, instead of just throwing a DNS failure. If there is need to update 
the DNS specs for this to be possible, then that should be done.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Mukund Sivaraman]

On Wed, Aug 16, 2017 at 08:21:37AM +0200, Mikael Abrahamsson wrote:
> On Wed, 16 Aug 2017, Mukund Sivaraman wrote:
> 
> > 24 / 500 top domains (4.8%)
> > 20548 / 1 million top domains (2.05%)
> > 
> > (12 years after introduction of 403{3,4,5})
> 
> https://stats.labs.apnic.net/dnssec/XE?o=cXAw1x1g1r1
> 
> 20% of European users is behind a validating resolver, in some countries
> it's 70% plus.
> 
> So this is now happening, albeit at a not high enough pace. But at least
> it's going in the right direction, and I do believe that there is enough
> people behind validating resolvers that people can't mess up signing their
> zone and push away blame on who needs to fix things.
> 
> So at least there is benefit in signing your zone now, there wasn't as much
> before when nobody was validating.

The validating resolver is half of the system.

DNSSEC is brittle. It has an all-or-nothing behavior (that's what it was
designed for) that many businesses cannot afford to bank on if something
were to go wrong. An administrative error or signer software bug on the
authoritative side can take the whole zone down and every service with
it (as DNS is at the head of network activity). Software is still not
perfect, so I don't know how this can change - I see practical signer
bugs still that take down the zone entirely. It's also still painfully
inconvenient to update parent zones, that makes fixing mishaps
difficult. The amount of damage that a break in DNSSEC validation chain
could do is far greater than other implementations of crypto such as TLS
where it is limited to a service.

(Note that I'm not advocating against DNSSEC, as much as this email may
sound so. The things I mention are practical issues that I see as an
implementor.)

A colleague says "If TLD’s allowed UPDATE messages to be processed most
of the issues with DNSSEC would go away. At the moment we have a whole
series of kludges because people are scared of signed update messages."

Mukund

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Mukund Sivaraman]

On Tue, Aug 15, 2017 at 11:29:56PM -0700, Paul Vixie wrote:
> 
> 
> Mukund Sivaraman wrote:
> ...
> > 
> > Alexa Top domains and DNSSEC:
> > 
> > 24 / 500 top domains (4.8%)
> > 20548 / 1 million top domains (2.05%)
> > 
> > (12 years after introduction of 403{3,4,5})
> 
> we should give up.
> 
> or we shouldn't.
> 
> not a mixture.

I'm not saying we should give up.. but it's going to be a while before
we get to an utopia of maximal DNSSEC deployment. In the meantime, there
are practical problems that need mitigation.

Mukund

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Paul Vixie]

Mukund Sivaraman wrote:
...


Alexa Top domains and DNSSEC:

24 / 500 top domains (4.8%)
20548 / 1 million top domains (2.05%)

(12 years after introduction of 403{3,4,5})


we should give up.

or we shouldn't.

not a mixture.

--
P Vixie

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Mikael Abrahamsson]

On Wed, 16 Aug 2017, Mukund Sivaraman wrote:


24 / 500 top domains (4.8%)
20548 / 1 million top domains (2.05%)

(12 years after introduction of 403{3,4,5})


https://stats.labs.apnic.net/dnssec/XE?o=cXAw1x1g1r1

20% of European users is behind a validating resolver, in some countries 
it's 70% plus.


So this is now happening, albeit at a not high enough pace. But at least 
it's going in the right direction, and I do believe that there is enough 
people behind validating resolvers that people can't mess up signing their 
zone and push away blame on who needs to fix things.


So at least there is benefit in signing your zone now, there wasn't as 
much before when nobody was validating.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

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