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] 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] 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] 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] 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] 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] 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] 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

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

[Mukund Sivaraman]

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.

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

___
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]

Hi Ted,

Thanks for your relevant comments, :-)

Ted Lemon 于2017年8月16日周三 上午1:28写道：

> I tried to ignore this thread for a while, but became alarmed after
> reading some of the recent comments, so I went and read the document.
>
> As far as I can tell, this document gives no clear justification for why
> it is a good idea.   We have not been told of the practical operational
> problems that motivate it.   It appears to solve a problem we have already
> solved, in a way that creates new security vulnerabilities.   We have not
> been told why the existing solution to the problem is not adequate.
>
> If the authors have a real problem that they feel has not already been
> solved, the first step in the process ought to be to present that
> information to the working group, rather than to present a solution to the
> working group with no clear statement about the problem it solves, and in
> particular no data about the seriousness of the problem.
>
For what it's worth, which isn't much since the chairs haven't issued a
> call for adoption, I don't think the working group should work on this.
>

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%

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.


>
> On Tue, Aug 15, 2017 at 9:41 AM, Vernon Schryver  wrote:
>
>> ] From: Lanlan Pan 
>>
>> ] Give the choice to operators, time is the best witness, like IP
>> surpassed
>> ] ATM.
>>
>> That is backwards.  IP did not surpass ATM, because IP came long before
>> ATM.  Instead, end-to-end ATM was the last gasp of the end-to-end
>> circuit switching point of view.  End-to-end ATM was supposed to replace
>> IP, but instead the new virtual circuits of ATM came far too late and
>> did not solve the problems that packet switching had already solved.
>>
>> ATM has not yet died and is still common for some uses.  For example,
>> ATM  is used as x.25 was used under IP in the early days of IP; many
>> DSL installations use AMT VCs.
>>
>> A better and more relevant history is that of the SPF RR.  The SPF RR
>> was supposed to replace the use of the TXT rtype for SPF.  The SPF RR
>> was widely available in deployed DNS authoritative servers (via BIND).
>> I think it was in milter modules for sendmail and postfix.  Nevertheless,
>> it died because it came late, was only a modest improvement, and required
>> operators to do something more than they were doing.
>>
>>
>> Vernon Schryverv...@rhyolite.com
>>
>> ___
>> 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
>
-- 
致礼  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

[Ted Lemon]

I tried to ignore this thread for a while, but became alarmed after reading
some of the recent comments, so I went and read the document.

As far as I can tell, this document gives no clear justification for why it
is a good idea.   We have not been told of the practical operational
problems that motivate it.   It appears to solve a problem we have already
solved, in a way that creates new security vulnerabilities.   We have not
been told why the existing solution to the problem is not adequate.

If the authors have a real problem that they feel has not already been
solved, the first step in the process ought to be to present that
information to the working group, rather than to present a solution to the
working group with no clear statement about the problem it solves, and in
particular no data about the seriousness of the problem.

For what it's worth, which isn't much since the chairs haven't issued a
call for adoption, I don't think the working group should work on this.

On Tue, Aug 15, 2017 at 9:41 AM, Vernon Schryver  wrote:

> ] From: Lanlan Pan 
>
> ] Give the choice to operators, time is the best witness, like IP surpassed
> ] ATM.
>
> That is backwards.  IP did not surpass ATM, because IP came long before
> ATM.  Instead, end-to-end ATM was the last gasp of the end-to-end
> circuit switching point of view.  End-to-end ATM was supposed to replace
> IP, but instead the new virtual circuits of ATM came far too late and
> did not solve the problems that packet switching had already solved.
>
> ATM has not yet died and is still common for some uses.  For example,
> ATM  is used as x.25 was used under IP in the early days of IP; many
> DSL installations use AMT VCs.
>
> A better and more relevant history is that of the SPF RR.  The SPF RR
> was supposed to replace the use of the TXT rtype for SPF.  The SPF RR
> was widely available in deployed DNS authoritative servers (via BIND).
> I think it was in milter modules for sendmail and postfix.  Nevertheless,
> it died because it came late, was only a modest improvement, and required
> operators to do something more than they were doing.
>
>
> Vernon Schryverv...@rhyolite.com
>
> ___
> 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] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Vernon Schryver]

] From: Lanlan Pan 

] Give the choice to operators, time is the best witness, like IP surpassed
] ATM.

That is backwards.  IP did not surpass ATM, because IP came long before
ATM.  Instead, end-to-end ATM was the last gasp of the end-to-end
circuit switching point of view.  End-to-end ATM was supposed to replace
IP, but instead the new virtual circuits of ATM came far too late and
did not solve the problems that packet switching had already solved.

ATM has not yet died and is still common for some uses.  For example,
ATM  is used as x.25 was used under IP in the early days of IP; many
DSL installations use AMT VCs.

A better and more relevant history is that of the SPF RR.  The SPF RR
was supposed to replace the use of the TXT rtype for SPF.  The SPF RR
was widely available in deployed DNS authoritative servers (via BIND).
I think it was in milter modules for sendmail and postfix.  Nevertheless,
it died because it came late, was only a modest improvement, and required
operators to do something more than they were doing.


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

[Lanlan Pan]

Hi Vernon,

Thanks for your advice, :-)

Vernon Schryver 于2017年8月15日周二 下午2:52写道：

> > From: Lanlan Pan 
>
> > Don't judy other's motivation with meaningless skeptics. The endless
> > skeptics can also push on your RPZ to DNSSEC.
>
> A significant difference between RPZ and the SWILD is that RPZ does
> not depend on non-participants doing anything.  For example, RPZ works
> fine on a single, isolated resolver.
> (Of course, the owners of the IETF printing presses would have to
> agree to publish anything, but publishing a description is neither
> implementing nor deploying.)
>
> The history of RPZ might suggest a temporary solution.  Why not implement
> SWILD using a private rtype or perhaps even TXT?  An implementation
> and a few 1000 installations might convince some skeptics and render
> many objections moot.
>

Yeah,  TXT is my history plan: Recursive Resolvers that support wildcard
detect method with TXT record


>
>
> > DNSSEC deployment will sharply rise if global nameservers desire *dns
> > security*, but almost impossible because of an addtional wildcards
> feature.
>
> I don't understand that.  My zones have plenty of wildcards, but as
> far as I can tell, no new wildcard features will break my DNSSEC
> signatures.
>
> I don't understand "global nameservers [desiring] dns security".
> Are "global nameservers" resolvers or authorities?

If they are resolvers, then there is absolutely no immediate prospect
> of many (any?) resolvers that might be called "global" dropping
> unsigned DNS data.
>

Both recursives and authoritatives.
I mean more and more recursives and authoritatives enable DNSSEC for dns
query by default configuration, sorry for my poor English.

If they are authorities, then I thought that the reasons why almost
> all com zones are unsigned are well understood, recently listed here,
> and have nothing to do with wildcards.  What am I missing?
> http://scoreboard.verisignlabs.com/
> http://scoreboard.verisignlabs.com/percent-trace.png


The deployment problem is on the Authoritative Nameservers of billions of
second level domains,  not on TLD.
And Recursive must enable DNSSEC validation for dns query by default
configuration.


>
>...
>
> ] From: Mark Andrews 
>
> ] I can't see how you can say push your RPZ to DNSSEC as RPZ breaks
> ] DNSSEC.
>
> I describe the same facts as the opposite, as "either DNSSEC breaks RPZ
> or DNSSEC and RPZ work together perfectly well"  (in either case,
> assuming a trusted path such as (trusted) localhost name or 127.0.0.1
> address to a trusted resolver, where "trusted resolver" includes
> "trusted to rewrite."  Of course, without a trusted path to a trusted
> resolver or a verifying stub, DNSSEC doesn't mean much.)
>
> As Mark Andrews understands but many people don't, the common RPZ
> implementation parameter "BREAK-DNSSEC yes" does NOT mean "RPZ breaks
> DNSSEC", but "RPZ should ignore DNSSEC request bits despite the fast
> that RPZ invalidates and removes signatures and so verifying stubbs
> and verifying downstream resolvers will not accept rewritten answers."
>
> Also, in the two RPZ implementations I've written, the default
> BREAK-DNSSEC value is "no" so that requesting DNSSEC turns off RPZ.
>
>
> Vernon Schryverv...@rhyolite.com
>
> ___
> 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

[Mark Andrews]

In message <201708150651.v7f6ptn7005...@calcite.rhyolite.com>, Vernon Schryver 
writes:
> ] From: Mark Andrews 
> 
> ] I can't see how you can say push your RPZ to DNSSEC as RPZ breaks
> ] DNSSEC.

I should have been more precise RPZ breaks DNSSEC for down stream
validators if it modifies responses from signed zones.  RPZ
implementations can be configured to do this.

> I describe the same facts as the opposite, as "either DNSSEC breaks RPZ
> or DNSSEC and RPZ work together perfectly well"  (in either case,
> assuming a trusted path such as (trusted) localhost name or 127.0.0.1
> address to a trusted resolver, where "trusted resolver" includes
> "trusted to rewrite."  Of course, without a trusted path to a trusted
> resolver or a verifying stub, DNSSEC doesn't mean much.)
> 
> As Mark Andrews understands but many people don't, the common RPZ
> implementation parameter "BREAK-DNSSEC yes" does NOT mean "RPZ breaks
> DNSSEC", but "RPZ should ignore DNSSEC request bits despite the fast
> that RPZ invalidates and removes signatures and so verifying stubbs
> and verifying downstream resolvers will not accept rewritten answers."
> 
> Also, in the two RPZ implementations I've written, the default
> BREAK-DNSSEC value is "no" so that requesting DNSSEC turns off RPZ.
> 
> 
> Vernon Schryverv...@rhyolite.com
> 
> ___
> 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

[Vernon Schryver]

> From: Lanlan Pan 

> Don't judy other's motivation with meaningless skeptics. The endless
> skeptics can also push on your RPZ to DNSSEC.

A significant difference between RPZ and the SWILD is that RPZ does
not depend on non-participants doing anything.  For example, RPZ works
fine on a single, isolated resolver.
(Of course, the owners of the IETF printing presses would have to
agree to publish anything, but publishing a description is neither
implementing nor deploying.)

The history of RPZ might suggest a temporary solution.  Why not implement
SWILD using a private rtype or perhaps even TXT?  An implementation
and a few 1000 installations might convince some skeptics and render
many objections moot.


> DNSSEC deployment will sharply rise if global nameservers desire *dns
> security*, but almost impossible because of an addtional wildcards feature.

I don't understand that.  My zones have plenty of wildcards, but as
far as I can tell, no new wildcard features will break my DNSSEC
signatures.

I don't understand "global nameservers [desiring] dns security".
Are "global nameservers" resolvers or authorities?
If they are resolvers, then there is absolutely no immediate prospect
of many (any?) resolvers that might be called "global" dropping
unsigned DNS data.
If they are authorities, then I thought that the reasons why almost
all com zones are unsigned are well understood, recently listed here,
and have nothing to do with wildcards.  What am I missing?
http://scoreboard.verisignlabs.com/
http://scoreboard.verisignlabs.com/percent-trace.png

   ...

] From: Mark Andrews 

] I can't see how you can say push your RPZ to DNSSEC as RPZ breaks
] DNSSEC.

I describe the same facts as the opposite, as "either DNSSEC breaks RPZ
or DNSSEC and RPZ work together perfectly well"  (in either case,
assuming a trusted path such as (trusted) localhost name or 127.0.0.1
address to a trusted resolver, where "trusted resolver" includes
"trusted to rewrite."  Of course, without a trusted path to a trusted
resolver or a verifying stub, DNSSEC doesn't mean much.)

As Mark Andrews understands but many people don't, the common RPZ
implementation parameter "BREAK-DNSSEC yes" does NOT mean "RPZ breaks
DNSSEC", but "RPZ should ignore DNSSEC request bits despite the fast
that RPZ invalidates and removes signatures and so verifying stubbs
and verifying downstream resolvers will not accept rewritten answers."

Also, in the two RPZ implementations I've written, the default
BREAK-DNSSEC value is "no" so that requesting DNSSEC turns off RPZ.


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

[Lanlan Pan]

Mark Andrews 于2017年8月15日周二 下午1:14写道：

>
> In message <
> canljsvwyo0nbisjgsqhrh33evbcuflnzcjceahj-l89fa+e...@mail.gmail.com>
> , Lanlan Pan writes:
> >
> > Hi Paul,
> >
> > Don't judy other's motivation with meaningless skeptics. The endless
> > skeptics can also push on your RPZ to DNSSEC.
>
> I can't see how you can say push your RPZ to DNSSEC as RPZ breaks
> DNSSEC.
>

Just for compare example, I mean that I also can't see how Paul can say
SWILD is to reduce DNSSEC deployment.

Not depend on,  is not equal to , reducing deployment.


> > As an network engineer, I think good faith is face to the realistic
> > internet world, try my best to offer a better solution to technology
> > problem.
> >
> > If we anticipated the subdomain wildcard scenario when designing wildcard
> > years ago, *make Authoritative give more precise wildcard information to
> > Recursive* (SWILD) is natually.
> > SWILD is not starting from "desire", not to mention "reducing DNSSEC
> > deployment".
> >
> > *1) I believe,  reduce solution interdependence between different problem
> > areas is comfortable.*
> >
> > Subdomain wildcard cache issue solution is not need to bind with security
> > issue, in natural.
>
> Only if you believe spoofed responses can't be delivered.
>
Everyone knows spoofed response can be delivered, that is why DNSSEC exists.
SWILD can work with DNSSEC validation, and save validation cost.
DNSSEC-enabled Recursive only need validate SWILD RR one time, not need
calculate/match NSEC3/NSEC5/... for yyy/zzz/.foo.com range.

>
> > *2) I believe,  design an alternative solution to an existed problem is
> > ordinary.*
> >
> > IPv4/IPv6 Migration can use Tunnel, NAT, ...
>
> And that is a problem for router vendors and OS developers because
> they end up having to implement them all.  Part of the reason there
> aren't lots of CPE Routers today that support IPv6 is that the
> vendors have to spend lots of $$ implemententing and testing
> all the different transition mechanisms.  If they don't want to
> spend lot of $$ then there is no real guidance on what mechanisms
> to discard.
>
> > Subdomain wildcard cache optimization can use NSEC aggressive wildcards,
> > SWILD, ...
> >
> > You can oppose to SWILD,  but wish you not oppose to the alternative
> > solution designing.
> >
> > *3) I believe,  network protocol / feature deployment progress is decided
> > by the key function, not because of additional function.*
> >
> > IPv6 deployment  will sharply rise mostly because of *IPv4 addresses
> > exhaustion*,  but almost impossible because of any improved IPv6 featue
> > that IPv4 not have, such as MTU detect, auto addressing, built in IPsec,
> ...
> > DNSSEC deployment will sharply rise if global nameservers desire *dns
> > security*, but almost impossible because of an addtional wildcards
> feature.
> >
> > That is why I say "SWILD has no influnence on reducing DNSSEC
> deployment",
> > going further,  "NSEC aggressive wildcard has no influnence on rising
> > DNSSEC deployment".
> >
> > Repeat the Google example,  as far as I can see:
> > - Google has expert on NSEC aggressive wildcard.
> > - Google likes to support some optimized protocols/features, such as
> QUIC,
> > SPDY, ...
> >
> > Nowadays: dig @ns1.google.com .google.com +dnssec, only return
> > NXDOMAIN.
> > Sum it up, I believe Google will deploy DNSSEC because of DNS SECURITY
> NEED
> > in future, more probability than because of NSEC aggressive wildcards.
>
> Google validates answers on its recursive servers so Google has already
> partially deployed DNSSEC.
>
My example is Google's Authoritative Server,  ns1.google.com.

>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 <+61%202%209871%204742> INTERNET:
> ma...@isc.org
>
-- 
致礼  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

[Mark Andrews]

In message 
, Lanlan Pan writes:
> 
> Hi Paul,
> 
> Don't judy other's motivation with meaningless skeptics. The endless
> skeptics can also push on your RPZ to DNSSEC.

I can't see how you can say push your RPZ to DNSSEC as RPZ breaks
DNSSEC.

> As an network engineer, I think good faith is face to the realistic
> internet world, try my best to offer a better solution to technology
> problem.
> 
> If we anticipated the subdomain wildcard scenario when designing wildcard
> years ago, *make Authoritative give more precise wildcard information to
> Recursive* (SWILD) is natually.
> SWILD is not starting from "desire", not to mention "reducing DNSSEC
> deployment".
> 
> *1) I believe,  reduce solution interdependence between different problem
> areas is comfortable.*
> 
> Subdomain wildcard cache issue solution is not need to bind with security
> issue, in natural.

Only if you believe spoofed responses can't be delivered.
 
> *2) I believe,  design an alternative solution to an existed problem is
> ordinary.*
> 
> IPv4/IPv6 Migration can use Tunnel, NAT, ...

And that is a problem for router vendors and OS developers because
they end up having to implement them all.  Part of the reason there
aren't lots of CPE Routers today that support IPv6 is that the
vendors have to spend lots of $$ implemententing and testing
all the different transition mechanisms.  If they don't want to
spend lot of $$ then there is no real guidance on what mechanisms
to discard.

> Subdomain wildcard cache optimization can use NSEC aggressive wildcards,
> SWILD, ...
> 
> You can oppose to SWILD,  but wish you not oppose to the alternative
> solution designing.
> 
> *3) I believe,  network protocol / feature deployment progress is decided
> by the key function, not because of additional function.*
> 
> IPv6 deployment  will sharply rise mostly because of *IPv4 addresses
> exhaustion*,  but almost impossible because of any improved IPv6 featue
> that IPv4 not have, such as MTU detect, auto addressing, built in IPsec, ...
> DNSSEC deployment will sharply rise if global nameservers desire *dns
> security*, but almost impossible because of an addtional wildcards feature.
> 
> That is why I say "SWILD has no influnence on reducing DNSSEC deployment",
> going further,  "NSEC aggressive wildcard has no influnence on rising
> DNSSEC deployment".
> 
> Repeat the Google example,  as far as I can see:
> - Google has expert on NSEC aggressive wildcard.
> - Google likes to support some optimized protocols/features, such as QUIC,
> SPDY, ...
> 
> Nowadays: dig @ns1.google.com .google.com +dnssec, only return
> NXDOMAIN.
> Sum it up, I believe Google will deploy DNSSEC because of DNS SECURITY NEED
> in future, more probability than because of NSEC aggressive wildcards.

Google validates answers on its recursive servers so Google has already
partially deployed DNSSEC.

Mark
-- 
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

[Lanlan Pan]

Hi Paul,

Don't judy other's motivation with meaningless skeptics. The endless
skeptics can also push on your RPZ to DNSSEC.

As an network engineer, I think good faith is face to the realistic
internet world, try my best to offer a better solution to technology
problem.

If we anticipated the subdomain wildcard scenario when designing wildcard
years ago, *make Authoritative give more precise wildcard information to
Recursive* (SWILD) is natually.
SWILD is not starting from "desire", not to mention "reducing DNSSEC
deployment".

*1) I believe,  reduce solution interdependence between different problem
areas is comfortable.*

Subdomain wildcard cache issue solution is not need to bind with security
issue,  in natural.

*2) I believe,  design an alternative solution to an existed problem is
ordinary.*

IPv4/IPv6 Migration can use Tunnel, NAT, ...
Subdomain wildcard cache optimization can use NSEC aggressive wildcards,
SWILD, ...

You can oppose to SWILD,  but wish you not oppose to the alternative
solution designing.

*3) I believe,  network protocol / feature deployment progress is decided
by the key function, not because of additional function.*

IPv6 deployment  will sharply rise mostly because of *IPv4 addresses
exhaustion*,  but almost impossible because of any improved IPv6 featue
that IPv4 not have, such as MTU detect, auto addressing, built in IPsec, ...
DNSSEC deployment will sharply rise if global nameservers desire *dns
security*, but almost impossible because of an addtional wildcards feature.

That is why I say "SWILD has no influnence on reducing DNSSEC deployment",
going further,  "NSEC aggressive wildcard has no influnence on rising
DNSSEC deployment".

Repeat the Google example,  as far as I can see:
- Google has expert on NSEC aggressive wildcard.
- Google likes to support some optimized protocols/features, such as QUIC,
SPDY, ...

Nowadays: dig @ns1.google.com .google.com +dnssec, only return
NXDOMAIN.
Sum it up, I believe Google will deploy DNSSEC because of DNS SECURITY NEED
in future, more probability than because of NSEC aggressive wildcards.


Paul Vixie 于2017年8月15日周二 上午5:32写道：

> WG Chairs: i oppose adoption of this draft.
>
> Lanlan Pan wrote:
> > Hi Paul,
> >
> > ...
>
> tl;dr: this message marks the end of this thread from my side.
>
> > I think, SWILD has no influence on DNSSEC deployment : 1) If
> > recursive wants to deploy DNSSEC, it is almost impossible because of
> > NSEC/NSEC3 aggressiveuse Wildcards. *Security need is the greatest
> > motivation behind DNSSEC depolyment.* 2) If recursive doesn't want
> > to deploy DNSSEC, it is almost impossible because of SWILD. Imagine
> > that, there is no SWILD to give precise subdomain wildcard
> > information from authoritative, recursive can use random subdomain
> > detect method to make cache optimization, which was described in DNS
> > Noise: Measuring the Pervasiveness of Disposable Domains in Modern
> > DNS Traffic
> > .
>
> Mr. Pan, your words above are a striking example of absurd reduction,
> which through a series of difficult-to-assail false equivalencies, an
> outcome unacceptable to your correspondent may begin to "look good on
> paper".
>
> Proof of this can by found by trying to reason your way to the
> conclusion you are offering, by any other path. You'll find this
> difficult, since the likelihood of someone deploying DNSSEC if it has no
> compelling features is lower, and aggressive negative caching with or
> without a wildcard is a feature of both DNSSEC and SWILD.
>
> In any case I find that you are arguing in bad faith, starting from your
> desire and then finding ways to justify it, rather than starting from
> the facts and finding out where those lead to. I won't play along any
> further. For your possible use, see these words from the NY Times
> opinion pages, published a day or so ago:
>
> < that hardly any climate skeptics are in fact trying to get at the truth.
> I’m not a climate scientist, but I do know what bogus arguments look
> like — and I can’t think of a single prominent climate skeptic who isn’t
> obviously arguing in bad faith.
>
> Take, for example, all the people who seized on the fact that 1998 was
> an unusually warm year to claim that global warming stopped 20 years ago
> — as if one unseasonably hot day in May proves that summer is a myth. Or
> all the people who cited out-of-context quotes from climate researchers
> as evidence of a vast scientific conspiracy.>>
>
> --
> P Vixie
>
> --
致礼  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

[Lanlan Pan]

Hi Matthew,

Thanks for your detailed reply, :-)

Matthew Pounsett 于2017年8月13日周日 上午12:31写道：

> On 12 August 2017 at 04:29, Lanlan Pan  wrote:
>
>> Hi Matthew ＆ Paul,
>>
>> Good question, :-)
>>
>> SWILD is a feature just for recusive cache optimization, only dealing
>> with the wildcard subdomain issue (with no nodes below).
>> DNSSEC + NSEC aggressive is security feature, with cryptographic contents
>> such as KSK/ZSK/NSEC/NSEC3/NSEC5/...
>>
>> My assumption is: *we can give recursive server an alternative solution
>> for wildcard subdomain cache issue, not need to depend on DNSSEC.*
>> Authoritative server just simply add one SWILD RR, not much deploy cost.
>> Recursive server can add SWILD support if it has an interest in wildcard
>> subdomain cache optimization,  it is OPT-IN.
>>
>
> I confess it was a rhetorical question. All of the major implementations
> already support DNSSEC.  8198 doesn't have an implementation status
> section, but there's every reason to think the major implementations will
> have support within a version of two.  A quick survey of a few issues
> databases shows that at least Knot is already working on it.  That is a
> significant head start; SWILD support without DNSSEC support can't happen
> in any significant way, and SWILD support without support for 8198 doesn't
> seem likely.
>

We know that we will have a Swiss Army knife (DNSSEC) in the future, can we
also put a Fruit knife (SWILD) in the kitchen now?


>
> As for operator adoption, the incentives are all wrong for this to
> actually get used.
>
> Recursive operators already have a very low operational bar to turn on
> DNSSEC and get the same benefit to their cache.  In both cases (SWILD and
> DNSSEC) they rely on the authoritative operator opting in before that
> benefit can be realized.
>
> Authoritative operators may choose to use DNSSEC  because it will secure
> their zone, and if recursive operators also have 8198-capable name servers
> then the workload for both authoritative and recursive is reduced for all
> terminal names.
>
> With SWILD, there is no direct benefit to the authoritative operator, as
> far as I can see.  Given that the only benefit to using SWILD is to the
> recursive operator, what is the motivation for the authoritative operator
> to add complexity to their deployment by adopting it?  Traditional
> wildcards work fine for them.
>

Authoritative will be directly benefit, save cost, reduce wildcard
subdomain response laterncy.

As methioned in the draft : "Intermediate Nameservers' cache hit rate will
rise, avoid to query Authoritative Nameserver for the same wildcard domain
configuration."
Imagine that Recursive Resolver knows that SWILD RR of wildcard domain "*.
foo.com". In TTL time, if Recursive Resolver receives "
yyy.foo.com/zzz.foo.com/..." A RR query, it can directly return this
subdomain wildcard response without send dns queries to Authoritative.

Traditional wildcards work no so fine for them, it make recursive send many
subdomain dns queries to Authoritative.

Authoritative operators can choose DNSSEC because of security,  they can
also choose SWILD because of wildcard domain response optimization.  Not
contradictory.


> To make the adoption problem worse, it appears as if SWILD is more limited
> in its use than traditional wildcards.  For example, I don't see how you
> could occlude an SWILD record with a more-specific domain name, as you can
> with traditional wildcards.
> Here's a common scenario based on the example from the draft:
>@86400  IN   SWILD  _
>_ 3600  IN   CNAME  map.bar.net.
>*  600  IN   CNAME  _
>  dev  600  IN   CNAME  map.dev.bar.net.
>
> How does SWILD behave when a client queries for dev?  According to the
> draft, the authoritative server would return the SWILD record at the apex.
> An SWILD-aware recursive server seems like it would ignore the CNAME
> returned for dev and instead use the CNAME for _, which is not what the
> operator intended.
>

As I replied to Petr, "many wildcards occupy the Resolver cache, with no
nodes below them."

Most of the subdomain wildcards for CDN, P2P, advertise, anti-virus, DNSBLs
service have not specific subdomain like "dev",  SWILD is not for this
condition.


>
>>
>> *I don't expect implementers would adopt SWILD 100% before adopting
>> DNSSEC+NSEC aggressive. Just give an alternative choice, implementers can
>> decide adopting or not, before or after, we won't pre-select for them.*
>> Even if both Authoritative server and Recursive server support
>> DNSSEC+NSEC aggressive, when will they configure default dns query with
>> dnssec ? (for NSEC agreesive cached deduced wildcard)
>>
>
> We already know that a year ago 26% of all end users were behind some sort
> of validating resolver, a number which continues to climb as more ISPs turn
> on validation, and more users switch to things like Google Public DNS
> 

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

[Dave Crocker]

On 8/12/2017 8:42 AM, Paul Vixie wrote:

we do, though, and we must. DNSSEC development began in 1996,



Hmmm.  As I recall, discussions on the topic began in 1990 and I thought 
I was cognizant AD, briefly, when the first working group was formed, 
after that.


I had understood that the IETF effort went through two false-starts in 
design before landing on the current design, but don't have an adequate 
sense of the milestone dates for these phases.


I note that the DNSSEC History Project should document this, in detail, 
but lacks dates(*)



d/

(*) https://wiki.tools.isoc.org/DNSSEC_History_Project

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
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

[Matthew Pounsett]

On 12 August 2017 at 04:29, Lanlan Pan  wrote:

> Hi Matthew ＆ Paul,
>
> Good question, :-)
>
> SWILD is a feature just for recusive cache optimization, only dealing with
> the wildcard subdomain issue (with no nodes below).
> DNSSEC + NSEC aggressive is security feature, with cryptographic contents
> such as KSK/ZSK/NSEC/NSEC3/NSEC5/...
>
> My assumption is: *we can give recursive server an alternative solution
> for wildcard subdomain cache issue, not need to depend on DNSSEC.*
> Authoritative server just simply add one SWILD RR, not much deploy cost.
> Recursive server can add SWILD support if it has an interest in wildcard
> subdomain cache optimization,  it is OPT-IN.
>

I confess it was a rhetorical question. All of the major implementations
already support DNSSEC.  8198 doesn't have an implementation status
section, but there's every reason to think the major implementations will
have support within a version of two.  A quick survey of a few issues
databases shows that at least Knot is already working on it.  That is a
significant head start; SWILD support without DNSSEC support can't happen
in any significant way, and SWILD support without support for 8198 doesn't
seem likely.

As for operator adoption, the incentives are all wrong for this to actually
get used.

Recursive operators already have a very low operational bar to turn on
DNSSEC and get the same benefit to their cache.  In both cases (SWILD and
DNSSEC) they rely on the authoritative operator opting in before that
benefit can be realized.

Authoritative operators may choose to use DNSSEC  because it will secure
their zone, and if recursive operators also have 8198-capable name servers
then the workload for both authoritative and recursive is reduced for all
terminal names.

With SWILD, there is no direct benefit to the authoritative operator, as
far as I can see.  Given that the only benefit to using SWILD is to the
recursive operator, what is the motivation for the authoritative operator
to add complexity to their deployment by adopting it?  Traditional
wildcards work fine for them.

To make the adoption problem worse, it appears as if SWILD is more limited
in its use than traditional wildcards.  For example, I don't see how you
could occlude an SWILD record with a more-specific domain name, as you can
with traditional wildcards.
Here's a common scenario based on the example from the draft:
   @86400  IN   SWILD  _
   _ 3600  IN   CNAME  map.bar.net.
   *  600  IN   CNAME  _
 dev  600  IN   CNAME  map.dev.bar.net.

How does SWILD behave when a client queries for dev?  According to the
draft, the authoritative server would return the SWILD record at the apex.
An SWILD-aware recursive server seems like it would ignore the CNAME
returned for dev and instead use the CNAME for _, which is not what the
operator intended.


>
> *I don't expect implementers would adopt SWILD 100% before adopting
> DNSSEC+NSEC aggressive. Just give an alternative choice, implementers can
> decide adopting or not, before or after, we won't pre-select for them.*
> Even if both Authoritative server and Recursive server support DNSSEC+NSEC
> aggressive, when will they configure default dns query with dnssec ? (for
> NSEC agreesive cached deduced wildcard)
>

We already know that a year ago 26% of all end users were behind some sort
of validating resolver, a number which continues to climb as more ISPs turn
on validation, and more users switch to things like Google Public DNS
.  This
isn't an ideal deployment status so long after DNSSEC was standardized, but
it's a long way ahead of SWILD.

You'll need to have a very compelling argument for me to believe that SWILD
is both more useful than DNSSEC and more likely to be deployed at any kind
of scale that would make a difference.  I just don't see it.

Add to that Paul's point that we would very much like to encourage DNSSEC
adoption, I don't see why we'd add support for an alternative technology
that accomplishes a subset of its features.
___
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]

On Saturday, August 12, 2017 8:29:45 AM GMT Lanlan Pan wrote:
> ...
> 
> SWILD is a feature just for recusive cache optimization, only dealing with
> the wildcard subdomain issue (with no nodes below).
> DNSSEC + NSEC aggressive is security feature, with cryptographic contents
> such as KSK/ZSK/NSEC/NSEC3/NSEC5/...
> 
> My assumption is: *we can give recursive server an alternative solution for
> wildcard subdomain cache issue, not need to depend on DNSSEC.*
> Authoritative server just simply add one SWILD RR, not much deploy cost.
> Recursive server can add SWILD support if it has an interest in wildcard
> subdomain cache optimization,  it is OPT-IN.
> 
> *I don't expect implementers would adopt SWILD 100% before adopting
> DNSSEC+NSEC aggressive. Just give an alternative choice, implementers can
> decide adopting or not, before or after, we won't pre-select for them.*

we do, though, and we must. DNSSEC development began in 1996, and deployment 
is stalled due to lack of motivation. it is the IETF's position that DNSSEC is 
a public good in that it will enable a general world-wide security level that 
has always eluded the Internet.

any DNSSEC feature that we decide to offer separately ("a la carte") is both a 
missed opportunity to increase the deployment of DNSSEC, and a self-inflicted 
wound that deliberately further stalls that deployment.

noting that DNSSEC as a protocol is of atrociously low quality ("it's crap"), 
i am in no way defending the design itself. however, it does work, and we 
would be acting contrary to our own best interests ("folly") if we took up 
anything like SWILD, or allowed anything like SWILD on the individual track.

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.

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]

Hi Matthew ＆ Paul,

Good question, :-)

SWILD is a feature just for recusive cache optimization, only dealing with
the wildcard subdomain issue (with no nodes below).
DNSSEC + NSEC aggressive is security feature, with cryptographic contents
such as KSK/ZSK/NSEC/NSEC3/NSEC5/...

My assumption is: *we can give recursive server an alternative solution for
wildcard subdomain cache issue, not need to depend on DNSSEC.*
Authoritative server just simply add one SWILD RR, not much deploy cost.
Recursive server can add SWILD support if it has an interest in wildcard
subdomain cache optimization,  it is OPT-IN.

*I don't expect implementers would adopt SWILD 100% before adopting
DNSSEC+NSEC aggressive. Just give an alternative choice, implementers can
decide adopting or not, before or after, we won't pre-select for them.*
Even if both Authoritative server and Recursive server support DNSSEC+NSEC
aggressive, when will they configure default dns query with dnssec ? (for
NSEC agreesive cached deduced wildcard)

As old features, why DNSSEC + NSEC is not forthcoming global deployed ?
(maybe an old question, tired of discussing)
Both Authoritative server and Recursive server consider about the DNSSEC
validation cost / DDoS.
Authoritative's Zone Enumeration risk, NSEC -> NSEC3 -> NSEC5 -> ???
other reasons...
For example, Google likes to support some optimized protocols/features,
such as QUIC, SPDY, ...
dig @ns1.google.com .google.com +dnssec ,  only return NXDOMAIN.

Matthew Pounsett 于2017年8月11日周五 下午10:39写道：

> On 11 August 2017 at 01:02, Lanlan Pan  wrote:
>

>
>>> We can get even better behavior from aggressive NSEC use. Here are
>>> advantages of aggressive NSEC use:
>>> - does not require changes to existing authoritatives or signed zones
>>> - less fragile (if we consider manual SWILD specification as an option)
>>> - supports wildcards with nodes below it
>>>
>>
>> Yes, aggressive NSEC use has advantages if:
>> 1) AUTH give NSEC RR.
>> 2) Every Intermediate Resolver supports DNSSEC validating and the NSEC
>> aggressive use.
>>
>
> 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?
>
>
>
>>
>> Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that
>>> is okay: New features are provided only by the latest version of
>>> the protocol.
>>>
>> But:
>> 1) many wildcards occupy the Resolver cache, with no nodes below them.
>> 2) many wildcards AUTH not give NSEC RR.
>> 3) many resolvers not support DNSSEC validating, not to mention NSEC
>> aggressive use.
>>
>> On the view of new feature, SWILD can be an alternative simpler choice to
>> deploy.
>>
> --
致礼  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

[Richard Gibson]

I'm assuming there's a very obvious answer to this question, but what would
break if unsigned wildcard caching were covered by allowing
DNSSEC-independent NSEC (and therefore
https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse )?

$ cat zones/github.io
; apex records
github.io. 900 IN SOA ns-1622.awsdns-10.co.uk. awsdns-hostmaster.amazon.com.
1 7200 900 1209600 86400
github.io. 900 IN NS ns-1339.awsdns-39.org.
github.io. 900 IN NS ns-1622.awsdns-10.co.uk.
github.io. 900 IN NS ns-393.awsdns-49.com.
github.io. 900 IN NS ns-692.awsdns-22.net.
github.io. 900 IN NS ns1.p16.dynect.net.
github.io. 900 IN NS ns2.p16.dynect.net.
github.io. 900 IN NS ns3.p16.dynect.net.
github.io. 900 IN NS ns4.p16.dynect.net.
github.io. 30 IN A 151.101.193.147
github.io. 30 IN A 151.101.129.147
github.io. 30 IN A 151.101.1.147
github.io. 30 IN A 151.101.65.147
github.io. 300 IN TXT "v=spf1 a -all"
; wildcard answer records
*.github.io. 3600 IN CNAME sni.github.map.fastly.net.
; aggressive-use signal covering LDH wildcard-synthesized names
*.github.io. 3600 IN NSEC github.io. CNAME NSEC
; aggressive-use signal covering pre-* wildcard synthesized names (omitted
to demonstrate selective application)
; github.io. 3600 IN NSEC *.github.io. A NS SOA TXT NSEC

$ dig @$resolver +noall +answer example.github.io. A; positive answer
with covering NSEC for aggressive use
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; ANSWER SECTION:
example.github.io. 3600 IN CNAME sni.github.map.fastly.net.
sni.github.map.fastly.net. 30 IN A 151.101.117.147
;; AUTHORITY SECTION:
*.github.io. 3600 IN NSEC github.io. CNAME NSEC

$ dig @$resolver +noall +answer foo.github.io. A; positive answer from
cache
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; ANSWER SECTION:
foo.github.io. 3590 IN CNAME sni.github.map.fastly.net.
sni.github.map.fastly.net. 20 IN A 151.101.117.147
;; AUTHORITY SECTION:
*.github.io. 3590 IN NSEC github.io. CNAME NSEC

$ dig @$resolver +noall +answer bar.github.io. ; negative answer
from cache plus fresh SOA
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; AUTHORITY SECTION:
github.io. 900 IN SOA ns-1622.awsdns-10.co.uk. awsdns-hostmaster.amazon.com.
1 7200 900 1209600 86400
*.github.io. 3579 IN NSEC github.io. CNAME NSEC

$ dig @$resolver +noall +answer baz.github.io. ; negative answer
from cache
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; AUTHORITY SECTION:
github.io. 890 IN SOA ns-1622.awsdns-10.co.uk. awsdns-hostmaster.amazon.com.
1 7200 900 1209600 86400
*.github.io. 3569 IN NSEC github.io. CNAME NSEC

$ dig @$resolver +noall +answer '\032.github.io.' A; positive answer
with non-covering NSEC (due to partial application; could be remedied by
adding another NSEC to the zone)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; ANSWER SECTION:
\032.github.io. 3600 IN CNAME sni.github.map.fastly.net.
sni.github.map.fastly.net. 30 IN A 151.101.117.147
;; AUTHORITY SECTION:
*.github.io. 3600 IN NSEC github.io. CNAME NSEC

On Thu, Aug 10, 2017 at 7:04 AM, Petr Špaček  wrote:

> Hello,
>
> On 4.7.2017 05:54, Lanlan Pan wrote:
> > Hi Tony,
> >
> > We try to solve similar wildcard problem.
> >
> > NSEC/NSEC3 aggressiveuse (Section 5.3 Wildcards
> >  aggressiveuse-10#page-6>)
> > :
> > - NSEC/NSEC3 RR: give "NOT EXIST SUBDOMAIN" information.
> > - cached deduced wildcard: give the default wildcard RR.
> >
> > SWILD:
> > - Directly give "ALL SUBDOMAIN" information, and the default wildcard RR.
> >
> > SWILD is applicable even when Authoritative Nameservers don't give
> > NSEC/NSEC3 RR.
> > SWILD is applicable on non-validating Forwarding Resolvers.
>
> If I understand it correctly:
> - the only information added by SWILD RR is an explicit information
> about the original (unexpanded) name of wildcard owner
> - the very same information can be obtained from RRSIG RR in a
> synthtetised answer (RRSIG labels < owner name labels)
> - SWILD will work only if there are no nodes below the wildcard
>
> Assuming this analysis is right, I'm against this proposal.
>
> We can get even better behavior from aggressive NSEC use. Here are
> advantages of aggressive NSEC use:
> - does not require changes to existing authoritatives or signed zones
> - less fragile (if we consider manual SWILD specification as an option)
> - supports wildcards with nodes below it
>
> Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that
> is okay: New features are provided only by the latest version of
> the protocol.
>
> Petr Špaček  @  CZ.NIC
>
>
> >
> > Regards,
> >
> > Tony Finch 

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

[Matthew Pounsett]

On 11 August 2017 at 01:02, Lanlan Pan  wrote:

>
>> We can get even better behavior from aggressive NSEC use. Here are
>> advantages of aggressive NSEC use:
>> - does not require changes to existing authoritatives or signed zones
>> - less fragile (if we consider manual SWILD specification as an option)
>> - supports wildcards with nodes below it
>>
>
> Yes, aggressive NSEC use has advantages if:
> 1) AUTH give NSEC RR.
> 2) Every Intermediate Resolver supports DNSSEC validating and the NSEC
> aggressive use.
>

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?



>
> Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that
>> is okay: New features are provided only by the latest version of
>> the protocol.
>>
> But:
> 1) many wildcards occupy the Resolver cache, with no nodes below them.
> 2) many wildcards AUTH not give NSEC RR.
> 3) many resolvers not support DNSSEC validating, not to mention NSEC
> aggressive use.
>
> On the view of new feature, SWILD can be an alternative simpler choice to
> deploy.
>
___
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]

Hi Petr,

Thanks for your comments, :-)

Petr Špaček 于2017年8月10日周四 下午7:04写道：

> Hello,
>
> On 4.7.2017 05:54, Lanlan Pan wrote:
> > Hi Tony,
> >
> > We try to solve similar wildcard problem.
> >
> > NSEC/NSEC3 aggressiveuse (Section 5.3 Wildcards
> > <
> https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-10#page-6
> >)
> > :
> > - NSEC/NSEC3 RR: give "NOT EXIST SUBDOMAIN" information.
> > - cached deduced wildcard: give the default wildcard RR.
> >
> > SWILD:
> > - Directly give "ALL SUBDOMAIN" information, and the default wildcard RR.
> >
> > SWILD is applicable even when Authoritative Nameservers don't give
> > NSEC/NSEC3 RR.
> > SWILD is applicable on non-validating Forwarding Resolvers.
>
> If I understand it correctly:
> - the only information added by SWILD RR is an explicit information
> about the original (unexpanded) name of wildcard owner
> - the very same information can be obtained from RRSIG RR in a
> synthtetised answer (RRSIG labels < owner name labels)
> - SWILD will work only if there are no nodes below the wildcard
>

Your analysis is totally right.

Assuming this analysis is right, I'm against this proposal.
>
> We can get even better behavior from aggressive NSEC use. Here are
> advantages of aggressive NSEC use:
> - does not require changes to existing authoritatives or signed zones
> - less fragile (if we consider manual SWILD specification as an option)
> - supports wildcards with nodes below it
>

Yes, aggressive NSEC use has advantages if:
1) AUTH give NSEC RR.
2) Every Intermediate Resolver supports DNSSEC validating and the NSEC
aggressive use.

>
Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that
> is okay: New features are provided only by the latest version of
> the protocol.
>
But:
1) many wildcards occupy the Resolver cache, with no nodes below them.
2) many wildcards AUTH not give NSEC RR.
3) many resolvers not support DNSSEC validating, not to mention NSEC
aggressive use.

On the view of new feature, SWILD can be an alternative simpler choice to
deploy.

Petr Špaček  @  CZ.NIC
>
>
> >
> > Regards,
> >
> > Tony Finch >于2017年7月3日周一 下午
> > 8:18写道：
> >
> > Lanlan Pan > wrote:
> > >
> > > This document specifies a new SWILD RR type for Intermediate
> > Nameservers to
> > > cache subdomain wildcard record, in order to reduce the cache size
> and
> > > optimize the wildcard domain cache miss.
> >
> > Isn't this functionality already provided by
> > https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse ?
> >
> > Tony.
> > --
> > f.anthony.n.finch  >
> > http://dotat.at/  -  I xn--zr8h punycode
> > Fitzroy: Variable 4 for a time in north, otherwise northeasterly
> > becoming
> > cyclonic 5 to 7. Slight or moderate. Occasional rain. Moderate,
> > occasionally
> > poor.
> >
> > --
> > 致礼  Best Regards
> >
> > 潘蓝兰  Pan Lanlan
>
> ___
> 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

[Petr Špaček]

Hello,

On 4.7.2017 05:54, Lanlan Pan wrote:
> Hi Tony,
> 
> We try to solve similar wildcard problem.
> 
> NSEC/NSEC3 aggressiveuse (Section 5.3 Wildcards
> )
> :
> - NSEC/NSEC3 RR: give "NOT EXIST SUBDOMAIN" information.
> - cached deduced wildcard: give the default wildcard RR.
> 
> SWILD:
> - Directly give "ALL SUBDOMAIN" information, and the default wildcard RR.
> 
> SWILD is applicable even when Authoritative Nameservers don't give
> NSEC/NSEC3 RR.
> SWILD is applicable on non-validating Forwarding Resolvers.

If I understand it correctly:
- the only information added by SWILD RR is an explicit information
about the original (unexpanded) name of wildcard owner
- the very same information can be obtained from RRSIG RR in a
synthtetised answer (RRSIG labels < owner name labels)
- SWILD will work only if there are no nodes below the wildcard

Assuming this analysis is right, I'm against this proposal.

We can get even better behavior from aggressive NSEC use. Here are
advantages of aggressive NSEC use:
- does not require changes to existing authoritatives or signed zones
- less fragile (if we consider manual SWILD specification as an option)
- supports wildcards with nodes below it

Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that
is okay: New features are provided only by the latest version of
the protocol.

Petr Špaček  @  CZ.NIC


> 
> Regards,
> 
> Tony Finch >于2017年7月3日周一 下午
> 8:18写道：
> 
> Lanlan Pan > wrote:
> >
> > This document specifies a new SWILD RR type for Intermediate
> Nameservers to
> > cache subdomain wildcard record, in order to reduce the cache size and
> > optimize the wildcard domain cache miss.
> 
> Isn't this functionality already provided by
> https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse ?
> 
> Tony.
> --
> f.anthony.n.finch  > 
> http://dotat.at/  -  I xn--zr8h punycode
> Fitzroy: Variable 4 for a time in north, otherwise northeasterly
> becoming
> cyclonic 5 to 7. Slight or moderate. Occasional rain. Moderate,
> occasionally
> poor.
> 
> -- 
> 致礼  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

[Lanlan Pan]

Hi Tony,

We try to solve similar wildcard problem.

NSEC/NSEC3 aggressiveuse (Section 5.3 Wildcards
)
:
- NSEC/NSEC3 RR: give "NOT EXIST SUBDOMAIN" information.
- cached deduced wildcard: give the default wildcard RR.

SWILD:
- Directly give "ALL SUBDOMAIN" information, and the default wildcard RR.

SWILD is applicable even when Authoritative Nameservers don't give
NSEC/NSEC3 RR.
SWILD is applicable on non-validating Forwarding Resolvers.

Regards,

Tony Finch 于2017年7月3日周一 下午8:18写道：

> Lanlan Pan  wrote:
> >
> > This document specifies a new SWILD RR type for Intermediate Nameservers
> to
> > cache subdomain wildcard record, in order to reduce the cache size and
> > optimize the wildcard domain cache miss.
>
> Isn't this functionality already provided by
> https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse ?
>
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h
> punycode
> Fitzroy: Variable 4 for a time in north, otherwise northeasterly becoming
> cyclonic 5 to 7. Slight or moderate. Occasional rain. Moderate,
> occasionally
> poor.
>
-- 
致礼  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

[Tony Finch]

Lanlan Pan  wrote:
>
> This document specifies a new SWILD RR type for Intermediate Nameservers to
> cache subdomain wildcard record, in order to reduce the cache size and
> optimize the wildcard domain cache miss.

Isn't this functionality already provided by
https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse ?

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Fitzroy: Variable 4 for a time in north, otherwise northeasterly becoming
cyclonic 5 to 7. Slight or moderate. Occasional rain. Moderate, occasionally
poor.

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

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

[Lanlan Pan]

Hi all,

We have submitted a new draft as draft-pan-dnsop-swild-rr-type-00.

Nowadays wildcard domain is globally used, especially on CDN, P2P,
advertise, anti-virus, DNSBLs service. Wildcard domain is simple configured
on Authoritative Nameserver, but Intermediate Nameservers have to cache
various domains (for example, xxx.github.io, yyy.github.io, ... ) of the
same wildcard domain configuration.

This document specifies a new SWILD RR type for Intermediate Nameservers to
cache subdomain wildcard record, in order to reduce the cache size and
optimize the wildcard domain cache miss.

Your comments are appreciated.

Thanks
Lanlan & Yu

-- Forwarded message -
From: 
Date: 2017年7月3日周一 下午7:15
Subject: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt
To: Pan Lanlan , Yu Fu 



A new version of I-D, draft-pan-dnsop-swild-rr-type-00.txt
has been successfully submitted by Lanlan Pan and posted to the
IETF repository.

Name:   draft-pan-dnsop-swild-rr-type
Revision:   00
Title:  SWILD RR Type (Wildcard on Intermediate Nameservers)
Document date:  2017-07-03
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/internet-drafts/draft-pan-dnsop-swild-rr-type-00.txt
Status:
https://datatracker.ietf.org/doc/draft-pan-dnsop-swild-rr-type/
Htmlized:   https://tools.ietf.org/html/draft-pan-dnsop-swild-rr-type-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-pan-dnsop-swild-rr-type-00


Abstract:
   This document describes a new SWILD RR type for Intermediate
   Nameservers to cache subdomain wildcard record, in order to reduce
   the cache size and optimize the wildcard domain cache miss.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
致礼  Best Regards

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