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 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
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
[DNSOP] Minutes from IETF115
All Thanks everyone for attending (and apologies for my bad audio from multiple devices it seems). Thanks also to Paul Hofman for taking minutes. I merged my notes and added some Chairs Actions (still being discussed), and uploaded them: https://datatracker.ietf.org/meeting/115/materials/minutes-115-dnsop-00 If anyone feels their comments are recording incorrectly, please let us know so we can fix. As a bonus, the chatlogs are now being included in the meeting materials https://datatracker.ietf.org/doc/chatlog-115-dnsop-202211080930/ thanks tim DNSOP WG IETF 115 2022-11-08 Chairs: Benno Overeinder, Suzanne Woolf, Tim Wicinski Notes here are only what happened at the mic, not on the slides Minutes taken by Paul Hoffman Chairs' slides https://datatracker.ietf.org/meeting/115/materials/slides-115-dnsop-chairs-slides The ALT Special Use Top Level Domain draft-ietf-dnsop-alt-tld, Paul Hoffman Wes Hardaker: Root Server Operator. Add should not forward statement. Preference is "Should" Anthony Somerset: Does not AS112. Leakage from root operators? Do not need to do anything. Eliot Lear: Many thanks, GNS relies on this Paul Wouters: AS112 wrong tool for this Ben Schwartz: Queries to the root. wants DNSSEC vaidated. "DNS Context" is confusuing Rob Wilton: Thanks for working on this, could this now focus on stub resolvers. Recommends Standards Track not Infomational. **Chairs Action: Time for WGLC** Hackathon at IETF 115 Willem Toorop presented on the Hackathon results Perl libraries for DNS error reporting Encrypted Client Hello was also implented by one implementer DNS Error Reporting draft-ietf-dnsop-dns-error-reporting, Roy Arends Viktor Dukhovni: Should a resolver behind a forwarder do something different: Roy: Could cause cascading Will add language regarding forwarders, or clients who don't do error detecting Negative Caching of DNS Resolution Failures draft-ietf-dnsop-caching-resolution-failures, Duane Wessels Peter Thomassen: Partitioning of the cache is up to the implementers, but the ECS breaks that Duane: If an implementation normally has different caches based on the ECS, the cache can blow up Peter: Could go into "protect yourself" section Peter Koch: Resolution is not DNSSEC protected; add this to Security Considerations Ralf Weber: It would be great to ignore ECS, but doing so would be hard Leave up to the implementation Control Options For DNS Client Proxies draft-homburg-add-codcp, Philip Homburg Benno: Wants to know if the WG wants this Ralf: Is this local-only, or can you extend it? Only between two programs Why not do this as an API Philip: Wants to do this within the DNS protocol Outside the DNS community if we do an API Ralf: Prefers API for on-machine, DNS for off-machine Viktor: DANE/PKIX is either no mention or mandatory: this is fragile This ignores opportunistic DANE Philip: Set both bits to zero to get that operation Can clarify the language to use DANE Benjamin: Disagrees that we don't stanardize APIs This feels like an API Browsers have rapidly-evolving requirements for how they do DNS lookups This is a new protocol between two parties Philip: The client has a probing query is already there Consistency for CDS/CDNSKEY and CSYNC is Mandatory draft-thomassen-dnsop-cds-consistency, Peter Thomassen Wes: Supports this Likes mandating checking everywhere Ralf: Supports this Can't ask "all" servers in anycast What if you don't get a response Peter: Ask each provider Is willing to add in wording about unresponses Paul Wouters: This wasn't in CSYNC, our bug Viktor: Concern was hidden masters and nameservers that are gone and are never going to come back **Chairs Action: CfA** Multi-Signer Key-Exchange (MSKE) draft-thomassen-dnsop-mske, Peter Thomassen Viktor: What about ongoing ZSK rollovers, particularly timing Peter: If one provider does a ZSK rollover unilaterally: unsafe Needs to think more about it Structured Data for Filtered DNS draft-wing-dnsop-structured-dns-error-page, Tirumal Reddy Lots of industry interest **Chairs Action: CfA** ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] .alt filtering in recursive servers
On Nov 11, 2022, at 9:48 AM, 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. The first quote, “[alt names] should not be looked up in a DNS context”, is clearly meant to be about applications that act as stub resolvers or actual stub resolvers. That is, not that "it is bad to $x so don't do it", but "it is not designed to $x so don't do it". That should be made clearer in the text. The second quote, "DNS stub and recursive resolvers do not need to look them up in the DNS context” does not conflict with "Caching DNS servers will treat [alt names] just as they would any other name whose TLD does not appear in the global DNS root.” - A DNS stub or recursive resolver that knows about one alt name does not need to look up names from that namespace in the DNS context because it will look them up in the special context. - A DNS stub or recursive resolver that knows about one alt name does not need to look up names from an alt namespace it does not recognize in the DNS context because it can treat it like a DNS name if it wants to; it could also treat it as an inherently unknown name (due to alt) if it wants. In the latter case, it needs to follow DNSSEC processing rules. > 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. The authors (and some of the WG) felt that the current wording was an improvement, so hopefully it would not strike you too hard. > IMO we should write requirements to describe the behavior we want. Yes. > 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. That is only true if you weigh the cost of reducing leakage against the benefit. > 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). Yes. > 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. Again, the current wording is considered an improvement over the requirements of RFC 6761 and the worked-out example in RFC 7686. If the WG wants the enumeration, we should be more careful about it. > 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. This seems very wrong. I think it should be allowed, but definitely not required, for applications to have special processing rules. It is quite conceivable that naive applications would work fine if the special processing is done in the stub resolver they talk to. > 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?]. See above. To me, it is natural to do the processing in a stub resolver, not in the applications. (Note that RFC 6761 doesn't talk about stub resolvers at all, so I'm assuming it would consider a stub resolver here not in #3.) For upstream recursive resolvers, saying "MUST" seems wrong because there is no significant effect if a resolver does not follow the specification. Saying "SHOULD" without explaining the exception is bad form. Further, Mark Andrews' observation about queries with DO set should bring pause to anyone wanting a MUST NOT for resolvers here. > 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
[DNSOP] draft-thomassen-dnsop-mske: DNSKEYs in non-apex
Hello. It's not a major thing in your design, but I see a risk that DNSKEYs at non-apex might have trouble validating, so at some point I'd expect your proposal to choose a different approach (e.g. allocate a new identical RR type) or at least confirm that it won't be a major problem. --Vladimir | knot-resolver.cz ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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
