Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-04.txt
Hi all, Maybe I missed some earlier discussions or decisions, then just ignore my comment. I was thinking if more meta data in the report query. If only one of the authoritative servers for the domain test. is out of sync it may help with some extra data to pinpoint the faulty server. In unicast the IP address of the faulty authoritative server may help. With an anycast setup maybe NSID is better but then the resolver has to include "+NSID" in all queries to auth servers. RFC8914 also has error codes for network error related problems. Would it be helpful to be able to signal what protocol that was used, like UDP53, TCP53, DOT, DOH, DOQ, etc? I understand that this type of error reporting may generate a lot of "false negatives" if the protocols are not supported by the auth servers. But on the other hand it may signal some unknown filtering in the path. Some possible examples: _ip4.192.168.47.11._ip4 _ip6.2001-DB8-F00=53._ip6 (in this example : eq - and :: eq =, maybe not the best) _nsid.server.iata._nsid _proto.doh._proto Regards, // mem Den 2023-02-03 kl. 18:34, skrev internet-dra...@ietf.org: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS Error Reporting Authors : Roy Arends Matt Larson Filename: draft-ietf-dnsop-dns-error-reporting-04.txt Pages : 10 Date: 2023-02-03 Abstract: DNS error reporting is a lightweight reporting mechanism that provides the operator of an authoritative server with reports on DNS resource records that fail to resolve or validate. A domain owner or DNS hosting organization can use these reports to improve domain hosting. The reports are based on extended DNS errors as described in RFC 8914. When a domain name fails to resolve or validate due to a misconfiguration or an attack, the operator of the authoritative server may be unaware of this. To mitigate this lack of feedback, this document describes a method for a validating recursive resolver to automatically signal an error to a monitoring agent specified by the authoritative server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-04 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-dns-error-reporting-04 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ 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] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
Hi all, I think one of the problems are that we look at the term from different perspectives. For me "lame delegation" is a log messages from the resolver software. A lot of the comments are more from the human view and with different operational angles or potential end user experience. If we only see it from the resolver software point of view it is something in the lines of "the status of the response (from what I thought was an authoritative server) didn't match my expectations", or "I didn't get a response at all". When humans interpret that log message, we can see it from the resolver operation view, the zone owner view, the end users experience when trying to reach some service within the child zone, including slow responses as the resolver has to do extra work to find a way around the problem, etc. So too many looking glasses or angles to know what we try to make clearer. Regards, // mem (without hats) Den 2023-05-01 kl. 18:09, skrev Paul Hoffman: It would be grand if a bunch more people would speak up on this thread. --Paul Hoffman, wearing my co-author hat On Apr 27, 2023, at 1:05 PM, Benno Overeinder wrote: Dear WG, The WGLC was closed for draft-ietf-dnsop-rfc8499bis, and the discussion on lame delegation did not find consensus, but two specific suggestions were put forward. We would like to include one of them in rfc8499bis if we can get consensus to do so. The chairs are seeking input on the following two suggestions: * Either we leave the definition of “lame delegation” as it is with the comment that no consensus could be found, or * alternatively, we include a shorter definition without specific examples. 1) Leaving the definition of lame delegation as in the current draft-ietf-dnsop-rfc8499bis, and including the addition by the authors that: "These early definitions do not match current use of the term "lame delegation", but there is also no consensus on what a lame delegation is." (Maybe change to ... no consensus what *exactly* a lame delegation is.) 2) Update the definition as proposed by Duane and with the agreement of some others (see mailing list https://mailarchive.ietf.org/arch/msg/dnsop/4E1AQKGivEHtJDB85gSNhofRuyM/): "A lame delegation is said to exist when one or more authoritative servers designated by the delegating NS RRset or by the child's apex NS RRset answers non-authoritatively [or not at all] for a zone". The chairs ask the WG to discuss these two alternative definitions of the term "lame delegation". We close the consultation period on Thursday 4 May. Regards, Benno ___ 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] The DNSOP WG has placed draft-rebs-dnsop-svcb-dane in state "Call For Adoption By WG Issued"
Hi, I guess I found a typo in section 7.8 (DNS AliasMode) Original text; Given a DNS server dns.example.com and records: _dns.dns.example.com. SVCB 0 dns.my-dns-host.net. dns.my-dns-host.net. SVCB 1 . alpn=dot The TLSA QNAME is _853._tcp.ns1.my-dns-host.net. Shouldn't the TSLA be; The TLSA QNAME is _853._tcp.DNS.my-dns-host.net. ^^^ Regards, // mem Den 2022-07-12 kl. 15:02, skrev IETF Secretariat: The DNSOP WG has placed draft-rebs-dnsop-svcb-dane in state Call For Adoption By WG Issued (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-rebs-dnsop-svcb-dane/ ___ 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
