[DNSOP] Heads up: DANE TLSA lookup issues with some nameservers.

With draft-ietf-dane-ops and draft-ietf-dane-smtp-with-dane both now in the RFC editor queue, I'd like to bring to your attention important related considerations for DNS operators. When opportunistic DANE TLS clients try to determine whether TLSA records exist for peers whose address records are

Re: [DNSOP] Order of CNAME and A in Authoritative Reply.

On Wed, Aug 12, 2015 at 01:59:55PM -0400, Andrew Sullivan wrote: The question, for the purposes of the protocol definition, is whether a message section (or maybe just the answer section) is an ordered set of unordered RRsets. If so, we probably ought to write that down somewhere, and

Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt

On Sun, Oct 25, 2015 at 11:39:25PM -0700, Paul Vixie wrote: > sanity check, someone? Yes, you're quite sane. :-) > I believe that in dnssec, an empty non-terminal has a proof that the name > exists, and a proof that there are no RR's. thus, vastly different from the > signaling for NXDOMAIN.

Re: [DNSOP] Asking TLD's to perform checks.

On Wed, Nov 11, 2015 at 07:53:25AM +0100, Patrik Fältström wrote: > > It may not be possible for everyone to agree on a comprehensive > > set of 'wrongs' with no omissions, but it should be possible to > > get consensus on a core set of 'wrongs' that are not controversial. > > Yes and no. I

Re: [DNSOP] Asking TLD's to perform checks.

On Wed, Nov 11, 2015 at 12:22:05PM +, Lawrence Conroy wrote: > ISTM that the IETF isn't in a position to force its suggestions through > the 'industry'. Who said anything about "forcing", I thought this was intended to be a BCP. As for whether the checks are done by registries or

Re: [DNSOP] Asking TLD's to perform checks.

On Wed, Nov 11, 2015 at 07:25:39AM +0100, Patrik Fältström wrote: > Everything has so far collapsed into collision between tech people not > agreeing on what is right and wrong. It also collapses into clashes between > registry policy and the tests made. I.e. just the registration policy is >

Re: [DNSOP] Asking TLD's to perform checks.

On Wed, Nov 11, 2015 at 07:43:30AM +1100, Mark Andrews wrote: > Perhaps we should be getting Jari, Suzanne and Andrew to push this > at IGF meetings. Not knowing what IGF meetings are, I can't comment on this specific point. > So we don't say what's right because you fear that not everybody >

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query

On Tue, Nov 10, 2015 at 09:29:30PM +, Tony Finch wrote: > Paul Hoffman wrote: > > > > With the current DNS protocol, a stub resolver can get all the records it > > > needs to validate a response in 1RTT, by sending multiple concurrent > > > queries for all the

Re: [DNSOP] Asking TLD's to perform checks.

On Fri, Nov 06, 2015 at 10:54:02AM +1100, Mark Andrews wrote: > I keep getting told the IETF can't tell people what to do > but that is *exactly* what we do do when we issue a BCP. > We tell people what best current practice is and ask them > to follow it. > > Today

Re: [DNSOP] Open Aggregated Datasets and stats on DNS (.NL ccTLD)

On Thu, Sep 03, 2015 at 03:32:12PM +0200, Giovane C. M. Moura wrote: > https://stats.sidnlabs.nl/ Quick question/observation about the TLSA query portion of the data-set. At least for SMTP, the query pattern is: ; sent to .nl authoritative servers when cache is cold ; Q:

Re: [DNSOP] Fwd: New Version Notification for draft-sury-dnskey-ed25519-03.txt

On Wed, Sep 09, 2015 at 09:44:23PM -0400, Paul Wouters wrote: > >>Once the CFRG algorithms are done, I would also publish an updated > >>list of MTI algorithms for DNSSEC that would consist of: > >> > >>8, 12 and both of the CFRG algorithms. > > You listed 12 as both deprecate and MTI ?

Re: [DNSOP] Fwd: New Version Notification for draft-sury-dnskey-ed25519-03.txt

On Tue, Sep 08, 2015 at 11:19:13AM +0200, Ondřej Surý wrote: > Dear DNS colleagues, > > this might be of some interest to you. > Thanks. Shouldn't this wait for the CFRG to finalize the new EC signature schemes? We already have too many DNSSEC algorithm ids, and are likely to add very

Re: [DNSOP] Fwd: New Version Notification for draft-sury-dnskey-ed25519-03.txt

On Wed, Sep 09, 2015 at 08:12:41PM +0200, Ondřej Surý wrote: > Yes, we are waiting exactly for the cfrg to finish the signature schemas. > But the rest can get a review early. f.e. it's evident now, we have to > add more material about motivation to add new curves into the draft(s). Great. My

Re: [DNSOP] Open Aggregated Datasets and stats on DNS (.NL ccTLD)

On Mon, Sep 21, 2015 at 02:23:15PM +0200, Giovane C. M. Moura wrote: > > I'd be curious to know what you're seeing for the dominant "_" > >> number in the observed TLSA queries, and whether any particular > >> resolvers are responsible for the bulk of the "_25" queries. > > Now I see you meant

Re: [DNSOP] new Resource record?

On Thu, Dec 10, 2015 at 09:56:26PM +0100, Hosnieh Rafiee wrote: > > Second, from the quick description, I don't quite understand what you want > > to solve. Not complaining, but in preparing to ask for a new type, the > > use case might need to be clearer. > > Authentication and authorization

Re: [DNSOP] The DNSOP WG has placed draft-andrews-dns-no-response-issue in state "Candidate for WG Adoption"

On Fri, Nov 27, 2015 at 05:20:05PM +, Warren Kumari wrote: > On Wed, Nov 25, 2015 at 5:51 PM Roy Arends wrote: > > > I support the general concept (responsive servers are often better > > netizens) and will review the draft, so I support this draft for WG > > adoption. > >

Re: [DNSOP] DNSOP Digest, Vol 122, Issue 24

> On Jan 23, 2017, at 3:00 PM, dnsop-requ...@ietf.org wrote: > > I've been following this discussion and have taken a few weeks to think > about the comments rendered here in some depth. I find that I most agree > with this statement: > > On Tue, Dec 20, 2016 at 10:53:39PM +, Warren Kumari

Re: [DNSOP] DNSOP Digest, Vol 123, Issue 70

> On Feb 20, 2017, at 4:19 PM, dnsop-requ...@ietf.org wrote: > > Accept that TLSA is dead. Don't tilt at windmills with yet more discovery > schemes. There at least ~2400 MX hosts with published TLSA records for SMTP serving over 100k domains and growing. In addition to Postfix and Exim,

Re: [DNSOP] [Ext] A nudge on the new terms in draft-ietf-dnsop-terminology-bis

On Fri, Feb 10, 2017 at 01:12:28PM +, Edward Lewis wrote: > I have a fundamental problem with that, meaning that a document within > DNSOP is defining domain names. Work I did to write (the still in progress) > draft on Domain Names has led me to believe that domain names are a concept >

Re: [DNSOP] draft-ietf-dnsop-no-response-issue-03

On Thu, Aug 18, 2016 at 02:34:54PM +, Edward Lewis wrote: > ##1. Introduction > ## > ## The DNS [RFC1034], [RFC1035] is a query / response protocol. Failure > ## to respond to queries or to respond incorrectly causes both immediate > ## operational problems and long term problems with

Re: [DNSOP] Mandated order of CNAME records in a CNAME chain?

On Thu, Sep 29, 2016 at 09:03:33AM -0400, Robert Edmonds wrote: > > Very good question but, IMHO, it is thread-stealing (hence changing > > the subject, and removing thread headers). > > I think there was already a thread on this topic recently on this list > ("Order of CNAME and A in

Re: [DNSOP] Where in a CNAME chain is the QNAME?

On Fri, Sep 23, 2016 at 10:22:32AM +0200, Stephane Bortzmeyer wrote: > On Tue, Sep 20, 2016 at 06:13:50PM +0200, > Stephane Bortzmeyer wrote > a message of 68 lines which said: > > > This issue was spotted by Peter van Dijk. It is about > >

Re: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

On Wed, Sep 28, 2016 at 11:27:20PM -, John Levine wrote: > The codes AA, QM-QZ, XA-XZ, and ZZ are "user assigned" and will never > be used for countries. Last year Ed Lewis wrote an I-D proposing that > XA-XZ be made private use and the rest future use, but as far as I can > tell it never

Re: [DNSOP] Where in a CNAME chain is the QNAME?

On Wed, Sep 28, 2016 at 09:26:38PM +, Stephane Bortzmeyer wrote: > On Mon, Sep 26, 2016 at 12:33:39PM +0100, > Ólafur Guðmundsson wrote > a message of 148 lines which said: > > > The RCODE applies to the RRSET pointed to by the last CNAME in answer > > section (or

Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05

On Tue, Oct 11, 2016 at 01:56:42AM +1100, Mark Andrews wrote: > If the IETF was setting servers that went and checked DNS servers > and informed the operators then the IETF would be in the business > of enforcing protocols. At this stage I don't see the IETF doing > that nor is this document

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On Mon, Jan 09, 2017 at 03:51:31PM +, Vernon Schryver wrote: > Note that the vast majority of clients of RPZ rewriting resolvers are > stubs that don't do validation So far, and at present, correct. Validating resolvers (unbound and the like) are seeing deployment on servers first,

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On Thu, Dec 29, 2016 at 05:45:59AM -, John Levine wrote: > >I'm seeing how it really helps governments cheaply create and enforce > >the creation of national internets -- especially with the walled garden > >features. Are those the good guys to you, or are there other benefits? > > Please

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On Wed, Dec 21, 2016 at 12:39:55PM -0500, Matthew Pounsett wrote: > RPZ is not the ideal, but it works, and goes beyond being deployable–it is > deployed. I am curious to understand how RPZ zone transfers are (intended to be) secured. It sounds like the reason for standardizing RPZ is to allow

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mon, Mar 20, 2017 at 09:06:40PM -0400, Ted Lemon wrote: > On Mar 20, 2017, at 8:48 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > FWIW, when adding DANE support to Postfix, > > The homenet use case is completely different. Here we are talking about > dev

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mon, Mar 20, 2017 at 05:44:27PM -0400, Steve Crocker wrote: > > You should bear in mind that homenet is assuming the Internet of maybe > > five years from now, more so than the Internet of now, although obviously > > we'd like to get done sooner than that. So you should assume that stub > >

Re: [DNSOP] Status of IDNA

On Wed, Apr 12, 2017 at 01:36:49PM +0200, Florian Weimer wrote: > What's the current standardization status of IDNA? > > in different browsers. Some browsers are still doing "transitional" UTS#46, it is time they move on. In up to date releases: Firefox:Already

Re: [DNSOP] Status of IDNA

On Wed, Apr 12, 2017 at 07:45:41PM -0400, Andrew Sullivan wrote: > On Wed, Apr 12, 2017 at 03:47:14PM +0000, Viktor Dukhovni wrote: > > > Just move on to non-transitional UTS#46. > > Given that its mappings include many emojis, which aren't allowed > under either IDNA2003

Re: [DNSOP] DNSOP Digest, Vol 125, Issue 31

> On Apr 13, 2017, at 7:30 AM, dnsop-requ...@ietf.org wrote: > > Well, IIRC they sensibly converged on a case-folded normal form > that ensures that https://Духовный.org maps to the same underlying > wire-form domain as https://духовный.org, i.e. both result in > queries for

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On Sun, Mar 12, 2017 at 04:38:20PM -0700, Dave Crocker wrote: > On 3/12/2017 4:23 PM, Paul Wouters wrote: > > I do not want to adopt it unmodified > > as informational RFC for running existing code. > > You do not want the IETF to document existing practice? In general, yes. However, in this

Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

On Sat, Jul 29, 2017 at 08:53:48AM -0400, Paul Wouters wrote: > > This starts a Call for Adoption for draft-wkumari-dnsop-extended-error > > I have reviewed the draft, and while I think it could be useful, I'm > seriously worried about sending unauthenticated errors back to the user, > and fear

Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

On Mon, Jul 31, 2017 at 05:11:07PM +, Evan Hunt wrote: > Are there applications specifically trusting AD=1 and behaving differently > than with AD=0? Or are they just ignoring it and trusting every answer > equally? I would have expected the latter, but I confess to being > surprised if

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

On Tue, Aug 15, 2017 at 10:28:15AM -0700, Paul Vixie wrote: > > There has been much discussion about doing away with any/255 and I > > seem to recall some discussion of a ANYA type which would return > > and A. > > > > This is something I see value in being implemented. > > as i've said

Re: [DNSOP] DNSOP Digest, Vol 132, Issue 45

> On Nov 23, 2017, at 11:13 AM, dnsop-requ...@ietf.org wrote: > > Even so, I know that at least one CA has received enough complaints from > customers with REFUSED private domains that they have already updated > their implementation to permit certificates in unresolvable zones that > lack

Re: [DNSOP] Error handling in CAA

On Wed, Nov 22, 2017 at 12:09:51PM +, Tony Finch wrote: > > If the SOA lookup fails, then the domain is severely broken > > No, it might just be private. We are not using the same (mine is correct :-) definition of failure. An NXDomain reply is not a lookup failure. The security status of

Re: [DNSOP] About draft-ietf-dnsop-extended-error

On Tue, Nov 14, 2017 at 07:56:00AM +, Shane Kerr wrote: > > And indeed unlike actual errors, there is nothing one could possibly > > add in the form extended "error" diagnostics when returning a NODATA > > or NXDomain response, these non-error conditions don't require any > > additional

Re: [DNSOP] About draft-ietf-dnsop-extended-error

On Mon, Nov 13, 2017 at 06:02:11PM -0800, Wes Hardaker wrote: > Tony Finch writes: > > >> It can be argued that NODATA (pseudo rcode, I know) is an "error" as > >> well as NXDOMAIN... > > > > Or, neither of them are errors :-) > > We'll remove the restriction in any wording that

Re: [DNSOP] Error handling in CAA

On Fri, Nov 17, 2017 at 12:49:33PM -0800, Jacob Hoffman-Andrews wrote: > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.4.pdf > > > CAs are permitted to treat a record lookup failure as permission to issue > > if: > > - the failure is outside the CA's infrastructure; > > - the

Re: [DNSOP] Error handling in CAA

On Mon, Nov 20, 2017 at 01:10:43PM +, Tony Finch wrote: > Viktor's message has lots of sound advice, though I have one correction: > > > This language really should have been much more clear. In particular, > > the last item warrants clarification. It is critical that the CA > > determine

[DNSOP] NSEC3PARAM iteration count update

[ I'm also posting a separate copy to dns-operati...@dns-oarc.net ] In light of the observations in: https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-05#section-2.3.1 I thought it would be useful to take another look at current practice. To that end, I gathered

Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

> On Apr 27, 2018, at 3:23 PM, Matthew Pounsett wrote: > >> If the registry operator is going to automatically upgrade previously >> insecure delegations to DNSSEC, then due diligence to make sure that this is >> not going to cause outages is advisable. Once a domain is

Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

> On Apr 28, 2018, at 1:28 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > So at this point I think we understand each other, and the issue comes down > to whether it is appropriate for the registry to automatically turn on DS > records for the first ti

Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

> On May 16, 2018, at 2:38 PM, Jacques Latour wrote: > > The intent of the document at bootstrap is for the parent to perform > sufficient tests to ensure they are conformable in bootstrapping the chain of > trust, I agree with you that these tests and other could be

Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

> On May 15, 2018, at 3:57 PM, John Levine wrote: > > I think it's a swell idea to offer people DNSSEC testing services but > it's hopeless to conflate it with key rotation. I completely agree with you on key rotation, once the zone has already been operating signed. But the

Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

> On May 15, 2018, at 2:29 PM, John Levine wrote: > > I think you will find that attempts to legislate against being stupid > do not generally turn out well. It makes sense to check for mistakes > that might screw up the upper level name server like an invalid > algorithm

Re: [DNSOP] DNSOP Digest, Vol 139, Issue 7

> On Jun 7, 2018, at 11:46 AM, dnsop-requ...@ietf.org wrote: > > This particular author believes that the DNSSEC should move to ECC, > so there’s a high cost associated with KSK algorithm rollover. So, if people > are going to change to “stronger” (whatever this means in DNSSEC context) >

Re: [DNSOP] New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt

> On Jun 7, 2018, at 11:30 AM, Ondřej Surý wrote: > > Oh, looking at the text just before the table it says: > > > Implemenation recommendations for DNSKEY algorithms > . > > > I am open to suggestions go to improve this text to emphasize that > it is

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt

On Thu, Jun 07, 2018 at 02:02:23PM -0400, Paul Wouters wrote: > >And furthermore, on 64-bit systems SHA512 tends > >to be somewhat faster (more with larger input sizes), because > >it processes input in 64-bit blocks. On my x86_64 laptop, > >running OpenSSL 1.1.1 beta 'speed

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt

On Tue, Jun 05, 2018 at 09:02:07PM +0200, Ondřej Surý wrote: > Could I ask for more reviews, so we can progress this document forward? > A couple of quick comments: 1. Perhaps it might not be clear to all readers whether the table in Section 3.1 is *software* implementation advice or

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Sat, Jun 23, 2018 at 07:43:19PM -0700, Joe Abley wrote: > > Yes, but if they have the NSEC bitmap, they can follow the XNAME > > without asking again. > > [...] > > That's already handled by NSEC/NSEC3. > > I think a pragmatic solution needs to work in unsigned zones. For unsigned zones a

Re: [DNSOP] SIG(0) useful (and used?)

On Wed, Jun 20, 2018 at 07:47:16AM +1000, Mark Andrews wrote: > SIG(0) has miles of potential. Active Directory shows that hosts updating > their own addresses is useful. And not just their own addresses. On my TODO list is making DANE more manageable by (optionally) allowing the holder of a

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Tue, Jun 19, 2018 at 07:59:34AM -0700, Joe Abley wrote: > > Petr Špaček wrote: > >> > >> Given that resolver side somehow works already ... > >> could we standardize this obvious violation of RFC 1035? > > > > The feature I would like is CNAME and other data (typically CNAME + MX + > > TXT),

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Tue, Jan 23, 2018 at 08:03:25PM +, Jeff Hodges wrote: > This is great! I can't wait for it to ship. I am not nearly so enthusiastic about an important component of the draft. Specifically, I'd like to suggest that while the requirement for recursive resolvers to return NXDOMAIN for

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Thu, Jan 25, 2018 at 08:17:17PM -0500, Ted Lemon wrote: > On Jan 25, 2018, at 7:48 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > See my other upstream message quoted below. There are deployed > > uses of local "localhost" zones, and a mandate to break

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Thu, Jan 25, 2018 at 10:18:01PM -0500, Ted Lemon wrote: > On Jan 25, 2018, at 8:37 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > I showed examples, of uses of "localhost". Some use the TLD itself > > for the usual local IPs, others employ subdomains o

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Fri, Jan 26, 2018 at 08:22:18AM -0800, 神明達哉 wrote: > Hmm, that's different from my interpretation of the draft. According > to my usual interpretation of IETF docs, I would interpret these from > Section 3: > >3. Name resolution APIs and libraries MUST recognize localhost names >

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Fri, Jan 26, 2018 at 12:19:00AM +1100, Mark Andrews wrote: > > RFC 6303 says that we should have empty domain for it, but this part is > > confusing: > > The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not an > > attempt to discourage any practice to provide a PTR RR for > >

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Wed, Jan 24, 2018 at 05:50:26PM -0800, Paul Vixie wrote: > Mark Andrews wrote: > > > On 25 Jan 2018, at 8:38 am, Paul Vixie wrote: > > > > > > viktor, i don't disagree with your goals, but i have a proposal as to > > > method. > > > > > > no resolver should be sending

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Thu, Jan 25, 2018 at 04:03:08PM +, Tony Finch wrote: > > I am not nearly so enthusiastic about an important component of > > the draft. Specifically, I'd like to suggest that while the > > requirement for recursive resolvers to return NXDOMAIN for "localhost." > > is well-intentioned, it

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Thu, Jan 25, 2018 at 01:02:27PM -0500, Ted Lemon wrote: > On Jan 25, 2018, at 12:54 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > I'm fine with recursive resolvers not *forwarding* > > "localhost.", but forbidding local answers is I think taking it >

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Fri, Jan 26, 2018 at 02:24:26PM -0600, Ted Lemon wrote: > > Disagreed, with respect to recursive resolvers, because the > > requirement is neither necessary nor sufficient to achieve the > > stated security goals, is not required for interoperability, and > > is in conflict with existing uses

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Fri, Jan 26, 2018 at 02:40:43PM -0500, Ted Lemon wrote: > On Jan 26, 2018, at 2:27 PM, 神明達哉 wrote: > > It's not clear to me, and either way I believe the draft should be > > clearer on these points (see also my latest response to Petr. If the > > intent of the draft is to

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Fri, Jan 26, 2018 at 06:02:00PM -0600, Ted Lemon wrote: > On Jan 26, 2018, at 5:03 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > Multiple participants in this discussion have pointed out that such > > queries are rare. > > Sigh. Yes, such queries are r

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Jan 29, 2018, at 10:53 AM, dnsop-requ...@ietf.org wrote: > To add more to this, Unbound by default returns 127.0.0.1, and so does > Knot Resolver, because both decided to respect > https://tools.ietf.org/html/rfc6761#section-6.3 > > This is a security hole, and again, purpose of NXDOMAIN is

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Wed, Jan 31, 2018 at 10:04:03AM +, Ray Bellis wrote: > On 30/01/2018 18:59, Andrew Sullivan wrote: > > > Because of that same section, also, signing the answer should also not > > be controversial because the answer is static. My preference, > > however, would be for the root servers to

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Sat, Feb 10, 2018 at 08:21:14PM +, Warren Kumari wrote: > > Interestingly enough, Steve Sheng and I wrote just such a document a > number of years ago (around the time of the initial name-collisions > drama). Even though I'm 95% sure it included the phrase "tilting at > windmills" my

[DNSOP] Review of draft-ietf-dnsop-rfc5011-security-considerations-11

1. Introduction Because of this lack of guidance, zone publishers may derive incorrect assumptions about safe usage of the RFC5011 DNSKEY s/derive/arrive at/ and is intended to complement the guidance offered in RFC5011 (which is written to provide timing guidance solely to a

Re: [DNSOP] Last Call: (DNS Terminology) to Best Current Practice

> On Aug 13, 2018, at 6:26 PM, John C Klensin wrote: > > the string 128.0.0.1, is a domain name Yes, it is the presentation form of the domain name whose list of labels is: "128", "0", "0", "1". There is of course no TLD named "1", so this domain is not registered, and it would also not be a

Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

> On Apr 14, 2018, at 4:26 PM, Matthew Pounsett wrote: > > These are getting into name server quality checks, and not security checks, > which is the point of the acceptance testing. I don't agree that these > should be part of this document. If the registry operator is

[DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

A number of checks are listed in: https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-to-rrr-protocol-04#section-3.4 that are intended to make sure a domain is ready for DNSSEC. As I've been the DNSSEC and DANE implementations at now ~5.8 million domains, I'd like to suggest some

Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

On Sat, Mar 24, 2018 at 02:58:55PM +, Jim Reid wrote: > IMO there's no need to do this in the protocol unless there is convincing > proof that nobody anywhere is using a now-obsolete RRtype. An RFC saying > a server could return FORMERR (or whatever) when it gets a query for one > of these

Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

On Mon, Mar 19, 2018 at 02:12:38PM -0400, Bob Harold wrote: > > > We have just submitted a draft aimed at increasing the security of > > > the DNSSEC with respect to the power that parental zones have over > > > their children. > > > > I'm opposed to this idea. > > If the parent simply pointed

Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC

On Thu, Mar 22, 2018 at 01:27:38PM -0400, Paul Wouters wrote: > I think this text also needs an update: > > RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones > deploying it are recommended to switch to ECDSAP256SHA256 as there is > an industry-wide trend to

Re: [DNSOP] Clarification question: compression pointers always to names earlier in the packet?

On Oct 24, 2018, at 5:57 AM, dnsop-requ...@ietf.org wrote: > Surely any sequence of labels that terminates with a pointer to any > label within that same sequence is an existence proof of such a loop. > The degenerate case is a single label terminated by a pointer to > itself. So I gather

[DNSOP] Clarification question: compression pointers always to names earlier in the packet?

My reading of RFC 1035 is that DNS name "compression" via "pointers" is restricted to name strictly earlier in the DNS message: 4.1.4. Message compression In order to reduce the size of messages, the domain system utilizes a compression scheme which eliminates the repetition of domain

[DNSOP] Waiting for DNSSEC...

[ Was: Fundamental ANAME problems Dropped In-Reply-To:, to ensure a new thread. ] On Fri, Nov 02, 2018 at 06:28:52PM +0100, Måns Nilsson wrote: > > I'll defer to other people, but it seems to me that anything that depends on > > recursive DNS servers being updated isn't a realistic solution.

Re: [DNSOP] Time to update RSAMD5 and perhaps DSA (algs 1 and 3) to MUST NOT?

On Wed, Dec 05, 2018 at 12:38:31AM +0100, Ondřej Surý wrote: > apart from the I-D in the LC, the upcoming BIND 9.14 release will have: > > * GOST removed (as it was deprecated by Russian “upstream”) > * Both DSA algorithms removed (insecure) > * RSAMD5 algorithm to be removed (I just finished

Re: [DNSOP] Time to update RSAMD5 and perhaps DSA (algs 1 and 3) to MUST NOT?

On Wed, Dec 05, 2018 at 05:14:17PM -0500, Viktor Dukhovni wrote: > I don't think this counts as a "production" RSAMD5 deployment. Speaking of "production", some of the DS RRs, don't look like they were ever intended to work. The odds against a hex-encoded digest

Re: [DNSOP] Time to update RSAMD5 and perhaps DSA (algs 1 and 3) to MUST NOT?

On Thu, Dec 06, 2018 at 10:26:55AM -0300, Hugo Salgado-Hernández wrote: > On 18:54 05/12, Viktor Dukhovni wrote: > > No idea why people would just "make up" (non-)random DS records for > > their domains, but for some reason some do. These made-up DS RRs > > Co

[DNSOP] Time to update RSAMD5 and perhaps DSA (algs 1 and 3) to MUST NOT?

The IANA DNSSEC parameter registry lists RSAMD5 (algorithm 1) as deprecated, and refers to [RFC3110], [RFC4034] which state that RSAMD5 is "NOT RECOMMENDED". https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 "Survey says" that RSAMD5 is not

Re: [DNSOP] Specification of DNSKEY "Private-key-format"

On Thu, Aug 29, 2019 at 06:25:02PM +0530, Mukund Sivaraman wrote: > A tool such as BIND's dnssec-keygen generates the following formatted > private keys: > > [muks@naina ~]$ cat Kexample.org.+008+10638.private > Private-key-format: v1.3 > Algorithm: 8 (RSASHA256) > Modulus: [...] >

Re: [DNSOP] Why would a v4 client send AAAA query?

On Wed, Aug 28, 2019 at 05:53:26AM +0530, Naveen Kottapalli wrote: > Can one of you tell why would a v4 client send query or a by client > send a A query when the resolved address cannot be used? One answer I did not see, but seems to me to be the most likely, is that the library interface

Re: [DNSOP] Last Call: (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard

On Wed, Sep 11, 2019 at 08:22:37PM +0100, Tony Finch wrote: > 3.2.1. Format > > All RRs have the same top level format shown below: > > [ snip ] > > TTL a 32 bit signed integer that specifies the time interval > that the resource record may be cached before the

Re: [DNSOP] Last Call: (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard

> On Sep 11, 2019, at 12:13 PM, The IESG wrote: > > 'Serving Stale Data to Improve DNS Resiliency' > It looks to me like the list of resolvers that implement "Serve Stale" in Section 3 contains a typo. Should "Know" be "Knot"? A number of

Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs

> On Sep 12, 2019, at 12:42 PM, Vittorio Bertola > wrote: > > But isn't the foremost motivation of this document to allow the client to > tell between SERVFAIL due to DNSSEC validation failure and SERVFAIL due to > resolver issues, and try another resolver in the latter case but not in the >

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

On Thu, Sep 12, 2019 at 09:51:25AM -0400, Tim Wicinski wrote: > - Viktor's comments from 11 September will be rolled into the WGLC > comments, which means I'll be tracking them with the authors. Much appreciated, thanks! FWIW, on the hot topic of conflict between RCODE and extended RCODE,

Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs

> On Sep 13, 2019, at 9:38 AM, Paul Hoffman wrote: > >> "There are many reasons that a DNS query may fail, some of them >> transient, some permanent; some can be resolved by querying another >> server, some are likely best handled by stopping resolution. >> Unfortunately, the error signals that

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-09.txt

On Tue, Sep 10, 2019 at 08:45:36PM -0700, internet-dra...@ietf.org wrote: > Filename: draft-ietf-dnsop-extended-error-09.txt Introduction 3rd paragraph (missing verb, extra period): [...] These extended DNS error codes [are?] described in this document and can be

Re: [DNSOP] Last Call: (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard

On Sat, Sep 14, 2019 at 02:31:14PM +0200, Stephane Bortzmeyer wrote: > On Wed, Sep 11, 2019 at 02:32:35PM -0400, > Viktor Dukhovni wrote > a message of 37 lines which said: > > > Finally, in security considerations, there's no mention of > > the potential security

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-10.txt

> On Sep 27, 2019, at 7:32 PM, internet-dra...@ietf.org wrote: > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-extended-error-10 Perhaps at my instigation the descriptions for: 3.8. Extended DNS Error Code 7 - Signature Expired

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-10.txt

> On Sep 30, 2019, at 7:06 PM, Wes Hardaker wrote: > >> Which raises another question: Can an OPT RR legitimately carry more >> than one EDE option, and thereby communicate multiple errors? Such as >> perhaps the above hypothetical with some RRSIGs expired, and some not >> yet vlid. > > Yes,

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

> On Sep 20, 2019, at 5:17 PM, Puneet Sood wrote: > > Since the consensus is that the EDEs are purely diagnostic, it would > be good to reiterate that at the end of this paragraph. For the record, while that was "diagnostic" was my take on the purpose of these codes, reading other responses, I

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-10.txt

On Tue, Oct 01, 2019 at 04:36:02PM -0700, Wes Hardaker wrote: > > I appears that text discussing the possibility of multiple EDE values > > present in earlier drafts may have been inadvertently removed in -07. > > I think such text should be restored, making it clear that the OPT > > record may

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-12.txt

> On Oct 2, 2019, at 8:01 AM, Tony Finch wrote: > > Re. EDE 5 indeterminate, RFC 4035 says: > > Indeterminate: An RRset for which the resolver is not able to > determine whether the RRset should be signed, as the resolver is > not able to obtain the necessary DNSSEC RRs. This

Re: [DNSOP] Proposal: Whois over DNS

On Mon, Jul 08, 2019 at 02:42:25PM -0700, Bill Woodcock wrote: > > In response to ICANN essentially removing most of the fields in WHOIS > > for domain records, Richard Porter and myself created a draft of an > > implementation putting these records into DNS TXT records. It would require > >

Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-14.txt

> On Nov 4, 2019, at 3:32 PM, internet-dra...@ietf.org wrote: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-no-response-issue-14 Two comments: --- Section 3.1.2 discusses non-response to unexpected qtypes, but there is a closely related case that I think warrants a mention.

  1   2   3   >