Re: [DNSOP] Meaning of lame delegation
Joe Abley> One nameserver in the delegation set of a particular child zone might provide Joe Abley> non-authoritative responses. By my usage, that nameserver is lame for that zone. Joe Abley> The delegation of that zone to that nameserver is a lame delegation. Identified Joe Abley> when receiving a response with aa = 0 when aa = 1 was expected. Possible causes: Joe Abley> wrong nameserver in the delegation set, incorrect configuration of the nameserver. The name server is lame, but the delegation might still work if there are other name servers in the deletation that are not lame. Joe Abley> (All nameservers in the delegation set might be lame, by my understanding of the Joe Abley> term. Mats thinks this is the necessary condition to use the term "lame", if I am Joe Abley> understanding him correctly. I think Mats' meaning is less useful, since it's often Joe Abley> the case that not all nameservers are lame, by my usage, and in those cases there Joe Abley> is still something to describe and fix. I am sympathetic to the idea that "delegation" Joe Abley> should refer to a collective of nameservers, a whole NS set, but I think it's actually Joe Abley> useful for it to mean that *and also* a single nameserver in a set, depending on Joe Abley> context.) I agree that it is a more common situation that a single server is lame than that the entire delegation is lame, but the latter is a more severe situation, which I assume all agree on. We need a term for when the delegation is lame, and that is what I call “lame delegation” of a specific zone, and when a single name server i a delegation is lame, which could be called lame name server, but it has to be specified for which zone. Since the term ”lame delegation” refer to the delegation it would be confusing to let it mean something which does not include the entire delegation. The delegation is more than a single name server in the delegation. Mats --- Mats Dufberg mats.dufb...@internetstiftelsen.se<mailto:mats.dufb...@internetstiftelsen.se> Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Meaning of lame delegation
mats> For the *delegation* to be lame it is not enough for one name mats> server to be ``broken''. The entire set must be such that the path mats> to the child zone content is not available. mats> For individual name servers it could be meaningful that say that mats> it is a *lame name server* in relation to a certain zone. Paul> I like this distinction. Agree that calling just one server not working Paul> is a lame name server. Paul> Still want better clarity for lame delegation on if we really care why Paul> we aren't getting auth/AA responses from at least one nameserver. If no Paul> listed nameserver gives auth/AA, I'd call that a clear criteria for lame Paul> delegation, regardless of the underlying reason, at least as far as a Paul> recursive server should care. Paul> Humans debugging may care but I don't see a "better" definition of lame Paul> server really informs that debugging process. I agree with you. The first step is to see that the delegation is lame or the server is lame. That is enough to conclude that the service is not provide at all (lame delegation) or from that server (lame server, repectively. The second step is to analyze why – no IP address avaiable, the IP address not reachable, server not responding with a DNS response, unexpect RCODE value or not authoritative. And the second step is for how to resolve the lameness. Yours, Mats --- Mats Dufberg mats.dufb...@internetstiftelsen.se<mailto:mats.dufb...@internetstiftelsen.se> Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Meaning of lame delegation
Under this issue is a discussion on the meaning of “lame delegation” but I see a focus on quality of individual name servers (in relation a certain zone). Delegation is an entity consisting of a set of name servers and, in some cases, glue address records. One part of the delegation is to provide the path to the child zone content. For the *delegation* to be lame it is not enough for one name server to be “broken”. The entire set must be such that the path to the child zone content is not available. For individual name servers it could be meaningful that say that it is a *lame name server* in relation to a certain zone. Mats --- Mats Dufberg mats.dufb...@internetstiftelsen.se<mailto:mats.dufb...@internetstiftelsen.se> Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Meaning of lame delegation
“If none of the name servers in the delegating NS RRset responds with an authoritative answer for the zone delegated then that zone has a lame delegation. If a name server cannot be resolved into an IP address or cannot be reached of UDP port 53 then that is, for this definition, equal to not respond with an authoritative answer.” Sometime a cached delegation becomes lame when the NS RRset is fetched from the zone, and none of the name servers in the zone NS RRset responds with an authoritative answer. If “lame delegation” is defined in such a way that it is enough with one failing name server in the delegation, the term becomes less useful. DNS usually forgives one failing name server. Yours, Mats --- Mats Dufberg mats.dufb...@internetstiftelsen.se<mailto:mats.dufb...@internetstiftelsen.se> Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ From: DNSOP on behalf of paul=40redbarn@dmarc.ietf.org Date: Sunday, 9 April 2023 at 09:32 To: Paul Hoffman , dnsop@ietf.org Subject: Re: [DNSOP] [Ext] Meaning of lame delegation "If one or more authoritative servers designated by the delegating NS rrset or by the apex NS rrset answers non-authoritatively for a zone, that zone is said to have a lame delegation." p vixie On Apr 9, 2023 04:13, Paul Hoffman wrote: I have been on vacation this week and am just seeing this thread now. Now that a bunch of people have spoken up on the topic, if someone wants to propose a *specific* change to the definition in draft-ietf-dnsop-rfc8499bis, this would be a very good time to do it, given that we are after WG Last Call but waiting for AD writeup. Otherwise, the current wording will be used for IETF Last Call. --Paul Hoffman ___ 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] Meaning of lame delegation
Yes, I would consider it to be lame delegation in all three scenarios below of EXAMPLE.NET. There is a delegation (from NET) but there is no possible path the the contents of the EXAMPLE.NET zone. Mats --- Mats Dufberg mats.dufb...@internetstiftelsen.se<mailto:mats.dufb...@internetstiftelsen.se> Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ From: DNSOP on behalf of Wessels, Duane Date: Monday, 3 April 2023 at 22:03 To: dnsop@ietf.org Subject: [DNSOP] Meaning of lame delegation Dear DNSOP, I am participating in an SSAC work party where we are writing about DNS delegations where a delegated name server might be available for registration, allowing an attacker to participate in the resolution for the domain. During report drafting we considered using the term "lame delegation" to describe this and a broader class of delegation problems. Naturally, we turned to RFC 8499, DNS Terminology, but found the entry not particularly helpful since it simply quotes previous, imprecise uses of the term: Lame delegation: "A lame delegations exists [sic] when a nameserver is delegated responsibility for providing nameservice for a zone (via NS records) but is not performing nameservice for that zone (usually because it is not set up as a primary or secondary for the zone)." (Quoted from [RFC1912], Section 2.8) Another definition is that a lame delegation "...happens when a name server is listed in the NS records for some domain and in fact it is not a server for that domain. Queries are thus sent to the wrong servers, who don't know nothing [sic] (at least not as expected) about the queried domain. Furthermore, sometimes these hosts (if they exist!) don't even run name servers." (Quoted from [RFC1713], Section 2.3) The first appears to assume that the name server exists, while the latter parenthetically notes the name server might not exist, but without any specific meaning of existence. We are wondering if the idea of a lame delegation should be interpreted broadly, or more narrowly to include only cases where a response is proof of lameness. Consider a delegation of the domain EXAMPLE.NET to name server NS.EXAMPLE.ORG. There are three possible situations in which this might be considered a lame delegation: (1) NS.EXAMPLE.ORG resolves to an IP address. Queries to the IP address result in a REFUSED, SERVFAIL, upward referral, or some other indication the name server is not configured to serve the zone. (2) NS.EXAMPLE.ORG resolves to an IP address. Queries to the IP address do not elicit a response (e.g., timeout). (3) NS.EXAMPLE.ORG does not resolve to an IP address, so there is nowhere to send a query. We welcome the working group's thoughts whether "lame delegation" encompasses these three possibilities. DW ___ DNSOP mailing list DNSOP@ietf.org https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop=05%7C01%7Cmats.dufberg%40internetstiftelsen.se%7Cb254e86788054440bc4708db347e6b48%7Cc2aa68f818f348ae81ba02301d121d9a%7C0%7C0%7C638161489807442090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=F7qevkR7HoiItfCi7pDyFQfl4agaDOkQ%2F%2FBnRtt4vPU%3D=0 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-01.txt
I have no problem to understand the need and wish to test new configuration before it is alive, but I do not think that it is correct to increase the complexity of the DNSSEC protocol as the draft suggests. There are other ways to achieve the same goal. Zonemaster (https://zonemaster.net/) and other tools can test a proposed delegation of a zone before it is delegated. Zonemaster also partially meets the needs by the draft by allowing proposed DS RRset to be included in the test. The model is there, but you can only test the zone, not a specific name by Zonemaster. When reading the documentation for DNSViz (https://github.com/dnsviz/dnsviz) it says that if you run DNSViz on the command line, you can insert a DS RRset. A DNS resolver, e.g. Bind, can be configured with a trust anchor for any domain and DS. With such a configuration the proposed DS record can be tested without publishing it and affecting production. I do not say that the tools above are ready for the use cases in the draft, but it shows that there is an alternative path to meed the needs of the use cases in the draft. Instead there are opportunities for some party to create a tool, maybe based on the tools above, to make it easy to test names and record types in a zone based on a proposed DS RRset. Keep testing outside the protocol as much as possibly to keep complexity down. I am against turning the draft into an RFC, especially since it is propsed to be a standards track RFC. Yours, Mats --- Mats Dufberg mats.dufb...@internetstiftelsen.se<mailto:mats.dufb...@internetstiftelsen.se> Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ From: DNSOP on behalf of Willem Toorop Date: Tuesday, 12 July 2022 at 16:36 To: DNSOP Working Group Subject: Re: [DNSOP] New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-01.txt Dear dnsop, We submitted a new version of a “dry-run DNSSEC” draft. The draft describes a method that allows for testing DNSSEC deployments in real world DNS(SEC) deployments without affecting the DNS service in case of DNSSEC errors. Any encountered errors are signaled to the DNS operator of the faulty zone with DNS Error Reporting (draft-ietf-dnsop-dns-error-reporting). This is a new idea which will be presented during dnsop at the IETF114 and was also presented at the IETF113. A recording of the IETF113 presentation is here: https://youtu.be/watch?v=7HxcmvFOnlU=3675s Slides here: https://datatracker.ietf.org/meeting/113/materials/slides-113-dnsop-dry-run-dnssec-01 We received a lot of feedback with our presentation which we used to reorganize the draft to convey the idea more clearly and coherently. We also received some critique and objections which were non-technical in nature. Below is a list with these objections followed by our response. ** This is another straw on the camel’s back ** Not all resolvers have to support/implement it. Most important is that provisioning at the registry and signaling of Dry-run is supported. If needed we can say it is OPTIONAL for resolvers in the draft. We intend to implement it ourselves in Unbound and have it enabled by default when error reporting is enabled. We know from experience with trust-anchor signaling and sentinel record that with only a small, up to date resolver population, the signaling is already quite substantial. There are different kinds of straws and this one is one that has the good cause of enabling operators to deploy DNSSEC with confidence. ** Why not have a duplicate parallel test deployment? ** There is nothing better than testing with your actual user population to dry-run your DNSSEC deployment. Note that slack’s parallel test deployment did not show them the Route53 failure that caused them to have an DNSSEC outage eventually[1] ** Why not sell DNSSEC domains cheaper? ** Yes, we’re all for that too, but that’s orthogonal to seeing what the actual effect of starting DNSSEC with your deployment with your real user population would be. The other objections which were more technical, like for example “registries supporting only fixed sized hashes per algorithm” and “couldn’t we normalize the different DS hacks somehow” are all addressed in the new version of the document. We’re looking forward to a new round of feedback and critique ;) Both on-list and in-person at the IETF-114! Kind regards, Yorgos, Willem and Roy Op 11-07-2022 om 23:58 schreef internet-dra...@ietf.org: > > A new version of I-D, draft-yorgos-dnsop-dry-run-dnssec-01.txt > has been successfully submitted by Yorgos Thessalonikefs and posted to the > IETF repository. > > Name: draft-yorgos-dnsop-dry-run-dnssec > Revision: 01 > Title:dry-run DNSSEC > Document date:2022-07-11 > Group:Individual Submission > Pages:12 > URL: > https://www.ietf.org/archiv
Re: [DNSOP] signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)
Parent is not authoritative of the NS in the delegation. The same with any glue address records on or below the delegation point. The parent does not sign non-authoritative records. Parent is authoritative of any DS records and any NSEC records in the delegation point. Those are signed by the parent. Mats --- Mats Dufberg mats.dufb...@internetstiftelsen.se<mailto:mats.dufb...@internetstiftelsen.se> Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ From: DNSOP on behalf of Ólafur Guðmundsson Date: Tuesday, 26 July 2022 at 15:29 To: Petr Špaček Cc: dnsop@ietf.org WG Subject: Re: [DNSOP] signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency) Parent is authoritative for the existence of the delegation Child is authoritative for the contents of the delegation DNS design did not take this into account thus there is no "range" of Parent only records, DS is the only record that is explicitly a "violation" of this IMHO RFC103x should have defined a DEL record in parent and NS in the child then resolvers could have kept both sides. Olafur On Tue, Jul 26, 2022 at 9:22 AM Petr Špaček mailto:pspa...@isc.org>> wrote: On 28. 06. 22 16:20, Bob Harold wrote: > But the parent NS set is not covered by DNSSEC, and thus could be spoofed?? > (Wish we could fix that!) I share your wish. Does anyone else want to contribute? Can people here share their memories of why it is not signed? I wasn't doing DNS when this was designed and I think it would be good to understand the motivation before we start proposing crazy things. Thank you for your time. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org<mailto:DNSOP@ietf.org> https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Neither authenticated nor SERVFAIL
A validating resolver is expected to either return the AD flag for authenticated data or SERVFAIL for data that cannot be authenticated when answering for data in a signed zone. I have here an example of a signed zone that resolvers return data from that is neither AD set nor SERVFAIL. If you query for "lindforslaw.se A" you will get an authenticated answer (AD): ; <<>> DiG 9.10.6 <<>> lindforslaw.se A +dns +mult @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 There is a wildcard record in the zone, and if you query for that you will also get authenticated answer, as expected. ; <<>> DiG 9.10.6 <<>> *.lindforslaw.se A +dns +mult @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30395 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 (...) ;; ANSWER SECTION: *.lindforslaw.se. 3408 IN A 194.9.94.86 *.lindforslaw.se. 3408 IN A 194.9.94.85 *.lindforslaw.se. 3408 IN RRSIG A 8 2 3600 (...) If you query for something that matches that wildcard, e.g. "x.lindforslaw.se A", then AD is not set, but it is not SERVFAIL. ; <<>> DiG 9.10.6 <<>> x.lindforslaw.se A +dns +mult @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10661 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 1 (...) ;; ANSWER SECTION: x.lindforslaw.se. 3600 IN A 194.9.94.86 x.lindforslaw.se. 3600 IN A 194.9.94.85 x.lindforslaw.se. 3600 IN RRSIG A 8 2 3600 (...) When data comes from a signed zone, then if the resolver can validate the response, it should set the AD flag, else return a SERVFAIL. Does anyone disagree? Does anyone have an explanation to the behavior? I get the same responses from different resolvers. Mats -- --- Mats Dufberg mats.dufb...@internetstiftelsen.se Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Algorithm implementation recommendations in 8624
On 17 Jun 2020, at 00:35, Tim Wicinski mailto:tjw.i...@gmail.com>> wrote: All The more time I spend referring to the implementation recommendation table in 8624 https://www.rfc-editor.org/rfc/rfc8624.html#page-5 The more time I wonder if there is a way to extend https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml to add signing/validation recommendations. This seems "hard" from the world of IANA, but I'm not an expert. Any opinions or suggestions? What strikes me is that IANA has no reference to RFC 8624 and that IANA still seems to consider SHA-1 and GOST to be algorithms to be used. Mats --- Mats Dufberg mats.dufb...@internetstiftelsen.se<mailto:mats.dufb...@internetstiftelsen.se> Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
On 15 Jun 2020, at 19:58, Tim Wicinski wrote: > > or since domains are cheap, why not buy a new domain, and use that for the > namespace? > A wise person liked to remind me "Namespaces are architecture decisions”. I have a different use case for private TLDs and that is in teaching material. We give a DNS class at a university here and in examples you cannot be restricted to .example as TLD because you need more than one TLD. And then you cannot rely on domain names that you can buy. The private two-letter codes are perfect for that. --- Mats Dufberg mats.dufb...@internetstiftelsen.se Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
I support the adoption and I am willing to review the document. --- Mats Dufberg mats.dufb...@internetstiftelsen.se<mailto:mats.dufb...@internetstiftelsen.se> Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ On 12 Jun 2020, at 17:36, Bob Harold mailto:rharo...@umich.edu>> wrote: On Fri, Jun 12, 2020 at 11:12 AM Tim Wicinski mailto:tjw.i...@gmail.com>> wrote: All, As we stated in the meeting and in our chairs actions, we're going to run regular calls for adoptions over the next few months. We are looking for *explicit* support for adoption. This starts a Call for Adoption for draft-arends-private-use-tld The draft is available here: https://datatracker.ietf.org/doc/draft-arends-private-use-tld/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 26 June 2020 Thanks, tim wicinski DNSOP co-chair Support, will review. Just read it - quite an exhaustive study of the subject. -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org<mailto: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] Hybird Resolver/ DNS invariants
In general, the resolver function and the authoritative function are best separated on different servers. When serving local data on a local network it is usually necessary to integrate serving authoritative data into the resolver function. If the proposal if for public DNS servers I no not see a value of such recommendations. Keep those apart. --- Mats Dufberg mats.dufb...@internetstiftelsen.se Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ -Original Message- From: DNSOP on behalf of Ralf Weber Date: Tuesday, 16 June 2020 at 08:57 To: Davey Song Cc: dnsop Subject: Re: [DNSOP] Hybird Resolver/ DNS invariants Moin! On 16 Jun 2020, at 4:23, Davey Song wrote: > I happened to run into a discussion of behaviors of Hybrid Resolver/ DNS > invariants where some of the non-typical uses of DNS are listed, especially > on the resolver. I'm encouraged to put them down as a requirement draft of > these uses of DNS and ask the mailing list whether it is a good idea. I > hope it is helpful to provide information including risk for people who are > doing or going to the same thing. > > There are some existing cases in the discussion: > 1. A resolver syncs (pull or receive server push) with an authoritative > server. It reduces the recursion and resolves the very-short TTL > requirement. RFC7706 provides an approach. Other resolveless approaches are > used as well.. > 2. A resolver can forward queries to another resolver if the load is high > to reduce the recursion. > 3. A resolver/authoritative server mode serving Apps via DoH or other > Application-level DNS. Operators of apps can edit each response on demand > and propagate the changes of DNS RR in seconds. It also provides a private > zone and names for each Apps. > 4. A Hybrid DNS which is used as a name server but cache and pull the > authoritative data from another authoritative server. It provides an > approach to easily scale the system without any change of existing > authoritative DNS. > > Do you think it is a useful effort for DNSOP WG? Any suggestions or > observed related discussions on the DNS invariants? Some of these are the same old combination of authoritative and recursive function. Mixing these has caused a lot of problems, please don’t suggest to do that again. How DoX (T, H, Q) changes the DNS landscape is yet to be seen, but I don’t understand how answering via a different network protocol makes a server different. The DNS tree still is the same. What you describe is mix of observed behaviour and local implementations, and IMHO not the best way to deploy DNS, but others may have different opinions here. So if you want to describe these deployments, so that we can discuss them go ahead. But I don’t think that we want to require DNS being build that way. So long -Ralf —-- Ralf Weber ___ 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
[DNSOP] Comments on draft-ietf-dnsop-extended-error version 10
Section 1 ends with "Receivers MUST NOT change the processing of RCODEs in
messages based on extended error codes" but it is not fully clear what that
statement means in the light of the description in the beginning of the same
section where the motivation for extended error codes is that the resolver
cannot know what specific error that is behind, e.g., REFUSED and there does
not know what the best next step is.
Both section 3.18 (filtered) and section 3.19 (prohibited) has code 17. In the
registry table (4.2) it is code 17 and 18, respectively.
Both 3.14 (Cached error) and 3.20 (Stale NXDOMAIN answer) reports that the
RCODE returned was taken from cached. In 3.20 it is described in detail what
the resolver has done before the answer is returned, whereas in 3.14 there are
not details at all.
3.14 needs more specification of when to use cached SERVFAIL.
I think that the last sentence in 3.20 ("This is typically caused [...] result
of a DoS attack against another network") does not belong to a standard
document.
In 3.22 it would be better to say that the operation or query is not supported
("Not supported"). As the text is now it is unclear by whom it is deprecated.
I suggest that the sentence "This may occur because its most recent zone is too
old, or has expired, for example" is removed from 3.25 since there could be
multiple reasons and it is not needed to give an example in a standard document.
---
Mats Dufberg
DNS Specialist
Internetstiftelsen (The Swedish Internet Foundation)
Mobile: +46 73 065 3899
https://internetstiftelsen.se/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Unsupported algorithm or unknown algorithm in draft-ietf-dnsop-extended-error
Error codes 1 and 2, respectively, says "unsupported algorithm" in the headline but "unknown algorithm" in the description. It should be consistent, and I think unsupported makes most sense. --- Mats Dufberg DNS Specialist Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to Proposed Standard
If this draft is approved, the new RFC will obsolete RFC 6944. RFC 6944, in turn, updates eight other RFCs. As I interpret it, the new RFC will inherit that role. I think that should be explicitly stated in the new RFC. Yours, Mats --- Mats Dufberg DNS Specialist, IIS Mobile: +46 73 065 3899 https://www.iis.se/en/ -Original Message- From: DNSOP on behalf of The IESG Reply-To: "i...@ietf.org" Date: Wednesday, 13 February 2019 at 20:30 To: IETF-Announce Cc: Tim Wicinski , "draft-ietf-dnsop-algorithm-upd...@ietf.org" , "dnsop@ietf.org" , "dnsop-cha...@ietf.org" Subject: [DNSOP] Last Call: (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to Proposed Standard The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Algorithm Implementation Requirements and Usage Guidance for DNSSEC' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-02-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of non- existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes [RFC6944]. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ballot/ No IPR declarations have been submitted directly on this I-D. ___ 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] Last Call: (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to Proposed Standard
The table in section 3.3 ("DS and CDS Algorithms") of the draft states that
SHA-1 is "MUST NOT" for "DNSSEC Delegation" but in the narrative text under the
table it states "SHA-1 [...] is NOT RECOMMENDED for use in generating new DS
and CDS records."
The two statements should be consistent in the final RFC.
Yours,
Mats
---
Mats Dufberg
DNS Specialist, IIS
Mobile: +46 73 065 3899
https://www.iis.se/en/
-Original Message-
From: DNSOP on behalf of The IESG
Reply-To: "i...@ietf.org"
Date: Wednesday, 13 February 2019 at 20:30
To: IETF-Announce
Cc: Tim Wicinski ,
"draft-ietf-dnsop-algorithm-upd...@ietf.org"
, "dnsop@ietf.org"
, "dnsop-cha...@ietf.org"
Subject: [DNSOP] Last Call:
(Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to
Proposed Standard
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Algorithm Implementation
Requirements and Usage Guidance for DNSSEC'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2019-02-27. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning
of
the Subject line to allow automated sorting.
Abstract
The DNSSEC protocol makes use of various cryptographic algorithms in
order to provide authentication of DNS data and proof of non-
existence. To ensure interoperability between DNS resolvers and DNS
authoritative servers, it is necessary to specify a set of algorithm
implementation requirements and usage guidelines to ensure that there
is at least one algorithm that all implementations support. This
document defines the current algorithm implementation requirements
and usage guidance for DNSSEC. This document obsoletes [RFC6944].
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ballot/
No IPR declarations have been submitted directly on this I-D.
___
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] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
I prefer a regex and I think that Dave's "_ta-.*" makes most sense. An
explanation that it is a regex and that the exact format of the name is found
in RFC 8145 is needed.
Mats
---
Mats Dufberg
DNS Specialist, IIS
Mobile: +46 73 065 3899
https://www.iis.se/en/
On 2018-07-25, 21:58, "DNSOP on behalf of John Levine" wrote:
In article <9ac469b7-031a-4d8c-53d0-a82abca0d...@dcrocker.net>,
Dave Crocker wrote:
>On 7/25/2018 10:59 AM, Bob Harold wrote:
>> Dot "." has special meaning in DNS, so I would prefer:
>>
>> Â Â _ta-*
>>
>> Not regex, but a common wildcard usage.
>
>wfm.
I suppose. A plausible actual regex would be
_ta(-[0-9a-z]{4}){1,12}
which might be a bit dense. That's not quite right because the
numbers in the label have to be sorted, but there's no way to say that
in a regex other than enumerating them which would be bulky.
Whatever you do, please put include some text reminding people that it's
a conceptual glob stype wildcard, not a DNS wildcard.
R's,
John
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for
Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
RFC 8145 defines the _ta- node name: A Key Tag query consists of a standard DNS query of type NULL and of class IN [RFC1035]. The first component of the query name is the string "_ta-" followed by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag values. The zone name corresponding to the trust anchor is appended to this first component. (RFC 8145, page 8) _ta- should go into table 2 on page 9 of draft-ietf-dnsop-attrleaf. Mats --- Mats Dufberg DNS Specialist, IIS Mobile: +46 73 065 3899 https://www.iis.se/en/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
