Re: [DNSOP] .alt filtering in recursive servers
Mark Andrews wrote on 2022-11-11 02:26: ... 4. Caching DNS Servers: Caching servers MUST [or SHOULD] NOT attempt to resolve .alt names in the global DNS root. They MAY respond to queries for such names with NXDOMAIN [or REFUSED?]. Caching servers MUST NOT intercept DO=1 queries as the client will not be able to validate such responses. The caching recursive server MAY synthesise a provable NXDOMAIN response as per RFC 8198. Caching servers SHOULD perform QNAME minimisation as per RFC 7816 for the .alt namespace by default. Querying for alt/DS or alt/NS will achieve this without leaking the query type. i'm comfortable with either. a query for anything.ALT appearing on any wire is a sign of misconfiguration. dropping it, answering insecurely, answering servfail, or letting qname minimization from the root zone happen and sending secure nxdomain, are all in-scope here. as long as we are protecting the root zone from .ALT query storms, we're good. no other predictable or reliable response should be specified. makers and operators who allow .ALT queries to appear on the wire should learn fear and should live in fear. being liberal in how we receive those queries is in absolutely nobody's best interests. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] .alt filtering in recursive servers
Dne 11. 11. 22 v 10:48 Wessels, Duane napsal(a): 5. Authoritative DNS Servers: Authoritative servers MUST respond to queries for .alt names with NXDOMAIN. I don't like to repeat myself, but I still consider this requirement proposal inproper and I disagree with it. The reasons have been already stated. Libor ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] .alt filtering in recursive servers
> On 11 Nov 2022, at 09:48, Wessels, Duane > wrote: > > I find the latest alt-tld draft to be inconsistent when it first > says “[alt names] should not be looked up in a DNS context” and > "DNS stub and recursive resolvers do not need to look them up in > the DNS context” but then later "Caching DNS servers will treat > [alt names] just as they would any other name whose TLD does not > appear in the global DNS root.” Since caching servers lookup names > with non existent TLDs in the DNS, then of course alt names will > also be looked up in the DNS context. > > I'm also struck how radically different the special use considerations > for .onion (RFC 7868) and .alt are. onion has multiple MUST-level > requirements for not leaking queries into the global DNS. > > IMO we should write requirements to describe the behavior we want. > Even though we know from experience that not all implementations > will adhere to the requirements it is appropriate to say that alt names > MUST NOT or (at least SHOULD NOT) not leak. > > And even if we don't end up with strong anti-leaking requirements, > then we should at least openly acknowledge that leaked queries > will happen (i.e., to root name servers). > > Lastly, I'd like to see the special use considerations for .alt > formatted more like the examples given in that RFC 6761 and the one > in RFC 7686. > > I’d like to propose this new/updated text for the alt-tld draft: > > == > > 1. Users: Human users might or might not recognize that names > in the .alt pseudo-TLD are special. > > 2. Application Software: Applications that use alternative > namespaces in .alt MUST have their own processing > rules for their own names, probably in specialized resolver > APIs, libraries, and/or application software. > > 3. Name Resolution APIs and Libraries: Resolvers MUST NOT resolve > .alt names in a DNS context. They MAY respond to > queries for such names with NXDOMAIN. > > 4. Caching DNS Servers: Caching servers MUST [or SHOULD] NOT > attempt to resolve .alt names in the global DNS root. They > MAY respond to queries for such names with NXDOMAIN [or > REFUSED?]. Caching servers MUST NOT intercept DO=1 queries as the client will not be able to validate such responses. The caching recursive server MAY synthesise a provable NXDOMAIN response as per RFC 8198. Caching servers SHOULD perform QNAME minimisation as per RFC 7816 for the .alt namespace by default. Querying for alt/DS or alt/NS will achieve this without leaking the query type. > 5. Authoritative DNS Servers: Authoritative servers MUST respond to > queries for .alt names with NXDOMAIN. > > 6. DNS Server Operators: Operators MUST NOT configure an > authoritative DNS server to answer queries for .alt. > > 7. DNS Registries/Registrars: Registries and Registrars MUST > NOT register .alt names because .alt will not exist in the > global DNS root. All such requests MUST be denied. > > Note that despite the requirements given here, it is generally expected > that queries for .alt names will "leak" into the global DNS. The root > name servers [RFC 7720?] will receive leaked queries and respond with > NXDOMAIN. Techniques such as qname minimization, aggressive NSEC caching, > and root-on-loopback can reduce the amount of leaked queries received by > root name servers. > > == > > DW > > > ___ > 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] .alt filtering in recursive servers
I find the latest alt-tld draft to be inconsistent when it first says “[alt names] should not be looked up in a DNS context” and "DNS stub and recursive resolvers do not need to look them up in the DNS context” but then later "Caching DNS servers will treat [alt names] just as they would any other name whose TLD does not appear in the global DNS root.” Since caching servers lookup names with non existent TLDs in the DNS, then of course alt names will also be looked up in the DNS context. I'm also struck how radically different the special use considerations for .onion (RFC 7868) and .alt are. onion has multiple MUST-level requirements for not leaking queries into the global DNS. IMO we should write requirements to describe the behavior we want. Even though we know from experience that not all implementations will adhere to the requirements it is appropriate to say that alt names MUST NOT or (at least SHOULD NOT) not leak. And even if we don't end up with strong anti-leaking requirements, then we should at least openly acknowledge that leaked queries will happen (i.e., to root name servers). Lastly, I'd like to see the special use considerations for .alt formatted more like the examples given in that RFC 6761 and the one in RFC 7686. I’d like to propose this new/updated text for the alt-tld draft: == 1. Users: Human users might or might not recognize that names in the .alt pseudo-TLD are special. 2. Application Software: Applications that use alternative namespaces in .alt MUST have their own processing rules for their own names, probably in specialized resolver APIs, libraries, and/or application software. 3. Name Resolution APIs and Libraries: Resolvers MUST NOT resolve .alt names in a DNS context. They MAY respond to queries for such names with NXDOMAIN. 4. Caching DNS Servers: Caching servers MUST [or SHOULD] NOT attempt to resolve .alt names in the global DNS root. They MAY respond to queries for such names with NXDOMAIN [or REFUSED?]. 5. Authoritative DNS Servers: Authoritative servers MUST respond to queries for .alt names with NXDOMAIN. 6. DNS Server Operators: Operators MUST NOT configure an authoritative DNS server to answer queries for .alt. 7. DNS Registries/Registrars: Registries and Registrars MUST NOT register .alt names because .alt will not exist in the global DNS root. All such requests MUST be denied. Note that despite the requirements given here, it is generally expected that queries for .alt names will "leak" into the global DNS. The root name servers [RFC 7720?] will receive leaked queries and respond with NXDOMAIN. Techniques such as qname minimization, aggressive NSEC caching, and root-on-loopback can reduce the amount of leaked queries received by root name servers. == DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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] .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
