Re: [DNSOP] .alt filtering in recursive servers
> On 8 Nov 2022, at 10:56, Peter Thomassen wrote: > > > > On 11/8/22 10:33, Mark Andrews wrote: >> Filtering .alt in recursive servers should be a MUST NOT. > > Whenever SHOULD or MUST (NOT) is used, or we're making a promise for the > indefinite future, or we're (in the case of NXDOMAIN synthesis) altering > behavior from the client's perspective (by precluding a DoE from the root), > then the document should be on Standards Track, not Informational. I was saying “do not do anything special” in recursive servers for .alt. A modern recursive server does QNAME minimisation. It may be doing NXDOMAIN means NXDOMAIN (in BIND this is qname-minimisation strict). It does DNSSEC validation. It does aggressive negative caching. It may be configured as a mirror for the root zone. When you query for alt you get enough information in the response from the root with aggressive negative caching to answer every other query for *.alt for 10800 seconds. % dig +dnssec alt ; <<>> DiG 9.19.6-dev <<>> +dnssec alt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8597 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 39041e1bfde7b212facacc52636a39c4ff7818022e6dc01e (good) ;; QUESTION SECTION: ;alt. IN A ;; AUTHORITY SECTION: . 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2022110800 1800 900 604800 86400 . 10800 IN RRSIG SOA 8 0 86400 2022112105 2022110804 18733 . AS0aswPnUf8/YdZE/Xeub17fLCWmp/OJXvqrH1+qcYN4WD0TV6mVS1Uc mrTeVGp52anSqxkzxfUQaPyiF1Clxnx1wGtncsNkDJpKX9fPdbMmMsk+ wm/URiOpwzCQC7nlcUESraWo5WW4Z1olGWMLK7mBA260GT/FmZq5wVtv 9WRKmyZGTPz6ETG9wb1k2WXstLUWuB/snlcyi7VZHpCvcOdK1ebiPkET BJY/0FMeWpEncR5KsK27mNTyXucjic04jj9h8LOew+SwA32LWKZg5cgn XT3Pssj1imKEUcSIM2Dl3I/G0z4FOYhvImqDkbiYEWVkB+OoAr9RvKGs T5cv8g== . 10800 IN RRSIG NSEC 8 0 86400 2022112105 2022110804 18733 . lG9D6KVTMh09Iu7SWWR+c2b8bOyi5xe+6PoD9u0kBOMOa0SdS4/Tm9z0 nRM1dV2zc1bdYHLSyOyb5CmdCvYO0dxpLPxpJIXope/cxDwUZaOG3zq/ kPqgBGTjJZSddFYYuSPxXhjBpoF1YFy3PzjfFMS0QytIX+pmbqvqTtg+ vgFr1sZHr8COiWcNQ2MYMqN81+nKmGyX9oCXFJO9bASXEfaSDCJf5979 Pg8yXWBrNpA+IoFbplkJhnqi+ApSmjH4t19xgh49kxbusm8GZImGimH9 QLFlpbUZ6yP1R/gOwMxkKfjfFyScvzWmuI4viFSKOZFlRXGF7xSKeBpy OHCgWg== . 10800 IN NSECaaa. NS SOA RRSIG NSEC DNSKEY alstom. 10800 IN RRSIG NSEC 8 1 86400 2022112105 2022110804 18733 . WORaA7GTkm3H7nB4x+32UfhmgxelNotpoVBf95eV1QptzGBTZiFebDz2 /aYogXYhV7gd1w9hAZjOW2qtsISR21qD9zTyHoG7JUty21UQfkLrm5QX 8X2EtVxD9+CmrI/+bJ2p91gEpEGvIcA6uslBKAoNuXFF6xZ/OqdtyIuV xYnJuYJHoFqC1rEk/ZbjS49UraLNpgkvPZGPpAVVzsussItT7lC2SECf WBOiY3ElxotTvD18rkn6EhQasuxiVxUP2uUiTxlJWYui4O6c6D37BuGL iXZoLOfRztesm+ISptOM+soTutN1NxHQZnXsoRYYTSOWhB0lsEQWSNBp IOJckw== alstom. 10800 IN NSECam. NS DS RRSIG NSEC ;; Query time: 190 msec ;; SERVER: 2001:67c:370:229::7#53(2001:67c:370:229::7) (UDP) ;; WHEN: Tue Nov 08 11:13:08 WET 2022 ;; MSG SIZE rcvd: 1049 % The alternative is that the recursive server maps ‘whatever.alt/QTYPE’ to ‘alt/DS’ when iterating then returns the result of that query to the client with the original QNAME and QTYPE. It can use the cached result of ‘alt/DS’ until it times out. > ~Peter > > -- > https://desec.io/ > > ___ > 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] the requested change to the dns-alt draft
On 08.11.22 10:42, Eliot Lear wrote: > As mentioned in the dnsop meeting the proposed change would be to remove the > following sentences in Section 2: > > OLD: > >Alternative namespaces should differentiate themselves from other >alternative namespaces by choosing a name and using it in the label >position just before the .alt pseudo-TLD. For example, a group >wishing to create a namespace for Friends Of Olaf might choose the >string "foo" and use any set of labels under foo.alt. > > OLD: > > They should attempt to choose a label that they >expect to be unique among similar groups and, ideally, descriptive. > IMO this should also be struk. If the WG decides to not govern the namespace, then this implied or recommended governance is only confusing if there is an effort to govern it externallly. For one: Why only one label per group and not two? Three? Ten? All ASCII? It is unclear what this means if the spirit of draft is what matters here. So, I think this should be struk and what happens under .alt will happen. I do not think you can have both: Not set a governance inplace for the namespace through a registry and set down (albeit not binding but implied) rules/recommendations. BR Martin > > This comes under the "do/do not" approach, and the WG has chosen to "do not" > as far as a registry is concerned. > > Regards, > > Eliot > ___ > 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] .alt filtering in recursive servers
On 11/8/22 10:33, Mark Andrews wrote: Filtering .alt in recursive servers should be a MUST NOT. Whenever SHOULD or MUST (NOT) is used, or we're making a promise for the indefinite future, or we're (in the case of NXDOMAIN synthesis) altering behavior from the client's perspective (by precluding a DoE from the root), then the document should be on Standards Track, not Informational. ~Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] .alt filtering in recursive servers
On 08/11/2022 11.33, Mark Andrews wrote: Filtering .alt in recursive servers should be a MUST NOT. [...] It would be nice to define this *in RFCs* somewhat uniformly for *all* the different special-use names. There's this unfortunate conflict between blocking and not blocking: total prevention of leaks, providing DNSSEC proofs, and simplicity (as "knowing whole root" can be a non-trivial implementation change). --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] .alt filtering in recursive servers
On Tue, 8 Nov 2022, Mark Andrews wrote: Filtering .alt in recursive servers should be a MUST NOT. Mirror zones (copies of the root zone) and aggressive negative caching will reduce the traffic to the root and not break downstream validating clients. AS112 is not needed. I agree. However, doing query minimalization for .alt should be recommended, but there is hardly a point of the draft defining that because no one should implement query minimalization just for alt. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] the requested change to the dns-alt draft
As mentioned in the dnsop meeting the proposed change would be to remove the following sentences in Section 2: OLD: Alternative namespaces should differentiate themselves from other alternative namespaces by choosing a name and using it in the label position just before the .alt pseudo-TLD. For example, a group wishing to create a namespace for Friends Of Olaf might choose the string "foo" and use any set of labels under foo.alt. OLD: They should attempt to choose a label that they expect to be unique among similar groups and, ideally, descriptive. This comes under the "do/do not" approach, and the WG has chosen to "do not" as far as a registry is concerned. Regards, Eliot ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] .alt filtering in recursive servers
Filtering .alt in recursive servers should be a MUST NOT. Mirror zones (copies of the root zone) and aggressive negative caching will reduce the traffic to the root and not break downstream validating clients. AS112 is not needed. -- 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
