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. AAAA ; 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. AAAA ; 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 <petr.spa...@nic.cz> 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 > > <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 > > 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 <d...@dotat.at <mailto:d...@dotat.at>>于2017年7月3日周一 下午 > > 8:18写道： > > > > Lanlan Pan <abby...@gmail.com <mailto:abby...@gmail.com>> 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 <d...@dotat.at <mailto:d...@dotat.at>> > > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
