Re: [DNSOP] opportunistic refresh and Happy Eyeballs

On 08/15/2017 01:27 PM, Jared Mauch wrote: >> On Aug 15, 2017, at 3:25 AM, Mikael Abrahamsson wrote: >> >> What is the opinion of this wg on that topic? > There has been much discussion about doing away with any/255 and I seem to > recall some discussion of a ANYA type which

Re: [DNSOP] 答复: DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

On 09/08/2017 11:15 AM, Davey Song(宋林健) wrote: > I just notice it asks for "Standards Track" document. If it aims to > introduce a special use of resolver to achieve some features for their > users' benefit, I think informational document may be more appropriate ? I > guess, like what RFC7706

Re: [DNSOP] opportunistic semi-authoritative caching (Re: DNSOP Call for Adoption - draft-tale-dnsop-serve-stale)

On 09/09/2017 09:22 PM, Paul Vixie wrote: > [...] > the content owner may have good and specific reasons for the TTL they > chose, and using that data for longer than that period may be harmful, > and must be presumed to be harmful unless explicit signaling is added > to let the content owner

Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

On 09/07/2017 08:25 PM, Joe Abley wrote: > I also think if a standard specification can be obtained it ought to include > appropriate instrumentation to allow a response to indicate whether data is > stale or not. This seems to me just one example of a set of additional > components we might

Re: [DNSOP] RFC2317 Question: Resolving cname delegation

Hello. On 08/24/2017 05:46 PM, Hector Santos wrote: > [...] Not expecting this in my DNS resolver code, I modified the > resolver to take the CNAMEs into account and return the host names > instead. Was this the correct thing to do, thus providing the same > results regardless of the query

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

Thanks Paul! I'm very happy with all the proposed formulation changes (your commit 0fqxn1k41). --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

Greetings! I really like the draft, and I'm sorry to be so late.  I see one minor issue just below and then a few nitpicks that I don't feel strongly about. > NXDOMAIN: >     "Name Error - Meaningful only for responses from an authoritative > name server, this code signifies that the domain

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

On 06/20/2018 04:59 PM, Tom Pusateri wrote: > DNSSEC will tell you the answer you get is correct but it could be a > to a > different question or be incomplete. Can you elaborate on that point.  I believe in signed zones you are able to verify almost everything, in particular existence of the

Re: [DNSOP] A conversational description of sentinel.

On 02/02/2018 04:45 PM, Warren Kumari wrote: > were **NOT** able to fetch the "underscore" record > were able to fetch the "dashdash" record Current Firefox 58.0.1 and old Chromium 61.0.3163.79, Linux, same result.  The system resolver does fetch _www.ksk-test.net. OK.  (I can't say I understand

Re: [DNSOP] Risk of using underscores for sentinel (Was: A conversational description of sentinel.

On 02/12/2018 12:28 PM, Stephane Bortzmeyer wrote: >> Current Firefox 58.0.1 and old Chromium 61.0.3163.79, Linux, same >> result.  The system resolver does fetch _www.ksk-test.net. OK.  (I >> can't say I understand what happens.) > Isn't is simply because some browsers rely on the standard

Re: [DNSOP] Updated KSK Sentinel document

On 02/13/2018 06:10 PM, Bob Harold wrote: > [...] If an entry could be put in the root zone, that is signed only > with the new key, then could users query that and always get a yes/no > answer to whether they will be affected?  I don't think that's possible.  This is about the _single_ root

Re: [DNSOP] Updated KSK Sentinel document

On 02/21/2018 02:53 PM, Warren Kumari wrote: > Hmmm... Good point. I personally actually preferred having these as > "decimal" keys. > RFC1034, Sec 5.3: The DS RR Presentation Format sayeth: >" The Key Tag field MUST be represented as an unsigned decimal > integer.", things like dig +multiline

Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

On 01/03/2018 07:31 PM, Peter van Dijk wrote: > What does dnsop think? I also prefer referral in this case, as it seems to make more sense for resolvers.  (For public reference, as we've discussed more directly.)  And thank you for bringing this problem to attention. How to best formulate a

Re: [DNSOP] Global DNS architecture changes, "the camel", and so on

On 08/20/2018 07:22 PM, Andrew Sullivan wrote: > • Does TCP need to become the norm (particularly for the above use > case)? TCP support is mandatory now, if that's what you mean (or wasn't clear). https://tools.ietf.org/html/rfc7766#section-5 In particular, for forwarding it actually

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 08/21/2018 04:47 PM, Philip Homburg wrote: >> If I got it well, what you are trying to bypass is your ISP's >> security filter that prevents you from connecting to malware or to >> illegal content (e.g. intellectual property violations and the >> likes). > As a user, I think there is little

Re: [DNSOP] New draft for helping browsers use the DoH server associated with a resolver

On 08/24/2018 02:01 AM, Paul Hoffman wrote: > Thoughts? Well, if the OS resolver is validating, it will SERVFAIL with such a query.  Furthermore, if it uses aggressive caching, it may even give a negative reply without asking upstream that would answer positively.  That is, unless the RFC

Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver

On 08/24/2018 04:25 PM, Paul Hoffman wrote: > Forwarding resolvers do not need special casing, I believe. If the forwarding > resolver understands the protocol, it will reply. If it doesn't understand > the protocol, it will forward and give back whatever the upstream resolver > tells it. Oh,

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Ehm, we somehow forgot that this thread is supposed to be about DHCP, so that's only the "uninteresting" case where you do trust the ISP and want to use their DNS over a secure channel :-D On 08/21/2018 05:34 PM, Philip Homburg wrote: >> Then you have a problem that's not solvable in DNS itself

Re: [DNSOP] IETF 102 Hackathon: prototype implementation of draft-wessels-dns-zone-digest-02

On 07/22/2018 12:12 AM, Peter van Dijk wrote: >> Someone pointed out to me that since ZONEMD is meta-data we don't really >> expect it to be queried normally, and a TTL of 0 is a reasonable default. > I recall a story about some resolver (Google Public DNS perhaps?) applying > the lowest TTL per

Re: [DNSOP] dnssec-kskroll-sentinel-06 clarifications

On 03/18/2018 09:44 PM, Petr Špaček wrote: > The current text in section 5 is written with an assumption that query > with +CD bit cannot result in "Secure" status and thus cannot trigger > sentinel processing, but this depends on implementation. I just want to note that this situation of

Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt

On 03/06/2018 01:30 AM, Wessels, Duane wrote: > I think its different. The above can tell you whether certain names were > resolvable (maybe even validatable?) but kskroll sentinel tells you that > specific key tags are or are not present in the TA store even if those keys > don't have

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

On 06/22/2018 12:27 AM, Ted Lemon wrote: > Thanks. In the case where a zone isn’t signed but the authoritative > server supports SIG(0), the response could be verified that it > includes exactly what the server sent. But the KEY would need to be > DNSSEC validated or it probably can’t be trusted

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-algorithm-update

On 10/17/18 11:18 PM, fujiw...@jprs.co.jp wrote: > 4. In my opinion, Ed25519 is best algorithm some yars later. >If the document describes both current RECOMMENDATIONS and >RECOMMENDATIONS some years later, we can plan. I agree, but the last paragraph of 3.1 seems to express that

Re: [DNSOP] Any website publishers who use CDNs on the list?

On 11/2/18 10:41 PM, Evan Hunt wrote: > Speaking as a co-author of ANAME, I agree about this. URI, SRV, a proposed > new HTTP RRtype, whatever - service lookup is absolutely the correct way to > accomplish this goal. > > However, browser vendors are *not doing that*, and I've given up hope that >

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

Hello! Unsupported algorithms (4.1.5 + 4.1.6): I'm a bit confused why these conditions are meant for SERVFAIL.  Has something changed? https://tools.ietf.org/html/rfc4035#section-5.2 (paragraph "If the validator does not support...") --Vladimir (knot-resolver)

[DNSOP] Adding more example configurations to draft-ietf-dnsop-7706bis

Hello. On 9/12/18 7:57 PM, Paul Hoffman wrote: > One of the things that people said they wanted in 7706bis is more > example > configurations for different systems. In Knot-resolver we decided to support an alternative approach: aggressive caching with a module that keeps the root zone fresh in

Re: [DNSOP] ANAME discussion

On 4/2/19 7:31 PM, Olli Vanhoja wrote: > On Tue, Apr 2, 2019 at 6:03 PM Tony Finch wrote: >> WRT loop detection, it is much easier if the additional section in the >> response from the resolver contains the chain(s). The draft doesn't >> specify that at the moment; maybe it should. > Why is it

Re: [DNSOP] Minimum viable ANAME

On 3/26/19 6:01 PM, Olli Vanhoja wrote: I think it's totally wrong to*choose* here what we think is the best method to solve the issue. I think it goes the direction you'll like.  My understanding of the current plan (of open-source implementors) is to have an RFC specifying *as little* as

Re: [DNSOP] Minimum viable ANAME

On 3/26/19 5:10 PM, Tony Finch wrote: I haven't seen any objections to support for ANAME in recursive servers so I'm surprised you think that is problematic enough to be removed. I'm not convinced that the resolver parts will be important, regardless of what exact mechanism will be chosen. 

Re: [DNSOP] extension of DoH to authoritative servers

On 2/13/19 7:08 AM, zuop...@cnnic.cn wrote: > i prefer DoH because it can identify a server we are talking to and > the content is encrypted. These two points are the same with DoT.  (encryption and SNI) ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] extension of DoH to authoritative servers

On 2/13/19 10:45 PM, Henderson, Karl wrote: > > Couldn’t DoT also run over port 443 just like DOH -– similar to what’s > been proposed in this > draft?: https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/ > Technically you can run DoT on whatever port you like.  I believe the port

Re: [DNSOP] extension of DoH to authoritative servers

On 2/14/19 9:05 AM, Stephane Bortzmeyer wrote: >> Technically you can run DoT on whatever port you like. >> >> Example: with knot-resolver it's easy - you just add @443, either on >> side of server and/or on the side of forwarding over TLS. > The problem is that you cannot then share this port

Re: [DNSOP] TA signal - suggestion to enhance signal

On 5/13/19 5:17 AM, Brian Dickson wrote: > Thoughts? There's the hiding problem due to aggressive caching, especially when forwarding to a resolver that does aggressive caching (1.1.1.1 is well-known but there are more). https://tools.ietf.org/html/rfc8145#section-5.3.1 If the label was extended

Re: [DNSOP] Verifying TLD operator authorisation

On 6/14/19 3:13 PM, Dr Eberhard W Lisse wrote: > Would (GPG encrypted) email to the registered address to the authority > not be sufficient? That would make sure the recipient is authorized and > must then cause the token to be 'delegated' as the second factor. What GPG key?  Sounds OK to me,

Re: [DNSOP] ANAME high-level benefit question

On 5/10/19 9:12 AM, Brian Dickson wrote: > Have any "closed system" implementations of non-standard apex-CNAME > hacks, committed publicly to neutral ANAME operations, presuming ANAME > as currently envisioned? The #41 thread is what you'd like, I guess?  But so far there's only a single

Re: [DNSOP] New draft, seeking comments: draft-sah-resolver-information

On 5/3/19 5:51 PM, John R Levine wrote: >>> server.  I suppose you could find your DoH server by name, but if you >>> can do that, you could equally well find your DoT or .well-known >>> server by name and define the problem out of existence. >> >> I think it's best to verify by name, even if the

Re: [DNSOP] New draft, seeking comments: draft-sah-resolver-information

On 5/2/19 10:59 PM, John Levine wrote: > I believe that DoT and DoH have the same certificate issues as the web > server. I suppose you could find your DoH server by name, but if you > can do that, you could equally well find your DoT or .well-known > server by name and define the problem out of

Re: [DNSOP] ANAME discussion

On 4/9/19 6:44 PM, Richard Gibson wrote: > If an implementation has a resolver, then that component is the > logical place for deduplication (e.g., the second inbound query for a > given ANAME target does not result in a second outbound query, but > rather waits on completion of the first). Oh,

Re: [DNSOP] ANAME discussion

On 4/9/19 3:38 PM, Richard Gibson wrote: > This loop is one reason of several to eliminate inline resolution for > ANAME if possible and minimize it otherwise, but is not quite as bad > as it seems because all involved servers can—and should—avoid issuing > queries that are redundant with an

Re: [DNSOP] Call for Adoption: draft-hoffman-dns-terminology-ter

On 8/1/19 6:08 PM, Tim Wicinski wrote: > 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. I'm in favor of adoption. I'm not sure if it's a good idea to suggest content changes in this same thread already,

Re: [DNSOP] Special-use TLDs in resolvers

On 8/16/19 3:10 PM, Ted Lemon wrote: > If you look up “onion”, you have revealed that the user is trying to > use tOR, even if you haven’t revealed where they are going. Well, in this particular case the tOR client would probably better not send onion queries to DNS resolver, but generally there

[DNSOP] Special-use TLDs in resolvers

Hello, I've been wondering what's best to do around these TLDs: invalid, local, onion, test.  The RFCs say that resolvers SHOULD recognize them as special and answer NXDOMAIN without any interaction with nameservers (by default).  What do you think about NOT following this "advice", subject to

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

Hello, authentication of blocking decisions is an interesting idea to consider, though it's probably beyond the scope of this RFC draft.  Most interesting cases can be already covered by securing the channels between the first resolver that does blocking and the final stub. On 9/4/19 2:31 PM,

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

On 9/12/19 8:10 PM, Viktor Dukhovni wrote: > SERVFAIL means, and will continue to mean, I can't help you, better luck next > time (or elsewhere). > > The new EDEs are *diagnostic* detail to aid in troubleshoots, but do not > override RCODEs. They are not a more fine-grained RCODE one might "act

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

The following comments are only loosely related to multiple threads here, so let me post them in a single bunch. On 9/11/19 8:05 AM, Viktor Dukhovni wrote: > Section 3.2 (code 2), may warrant more guidance on when this is > appropriate. AFAIK, there is nothing wrong with all DNSKEY algorithms >

Re: [DNSOP] some 2015-era thoughts about RFC 7706 -bis

On 7/25/19 7:44 AM, Evan Hunt wrote: > [... TLD XFR] However, admittedly, one probably > wouldn't want to do it for large zones, and I don't know of any TLD's that > allow transfer in the first place, so for the purposes of the current > discussion, you're right enough. I know about .se (and .nu)

Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

On 9/26/19 12:30 PM, Jan Včelák wrote: The current draft attempts to minimize complexity for implementers by offering a fully generic encoding for unknown key types. For example, "alpn=h3" can also be expressed as "key1=h3", and "port=8003" can also be expressed as "key2=\031\067". This

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

On 9/24/19 12:36 PM, Tony Finch wrote: > Petr Špaček wrote: >> IMHO the most useful information is dichotomy: >> >> a) the problem is local (= call network admin/ISP/telco) >> >> b) the problem is remote (= call your bank because their internetbanking >> broke and _do not your bother ISP_). > I

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

On 9/30/19 11:47 PM, Warren Kumari wrote: > On Mon, Sep 30, 2019 at 7:54 AM Tony Finch wrote: >> Difficult. In general there will be multiple upstream servers, even in >> the simplest case of a stub talking to a recursive server talking directly >> to authoritative servers. So there can be an

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-02.txt

Hello! On 10/28/19 10:32 PM, Wessels, Duane wrote: > The one defined hash algorithm SHA384 has been renamed to SHA384-STABLE to > reflect that it designed for use on stable (or small) zones where it is not > burdensome to recalculate the digest over the entire zone data each time. Tiny

Re: [DNSOP] [Ext] Re: Working Group Last Call for draft-ietf-dnsop-7706bis

On 11/1/19 1:26 AM, Paul Hoffman wrote: > On 10/31/19 6:10 PM, A. Schulze wrote: >> editorial note: Appendix B2 and B4 are mostly the same. > Mostly, but not exactly. Folks asked us to add B4 because of the new features > in BIND 9.14. Is this still what the WG wants? New features in Unbound

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

On 11/14/19 12:05 AM, Viktor Dukhovni wrote: > It'd be a shame (though admittedly not frequent) to have a resolver > retry over TCP just to get the same answer with additional information > it does not need and perhaps does not even understand. EDE codes themselves take very little space, so

Re: [DNSOP] On .ZZ

On 11/21/19 8:26 AM, Paul Wouters wrote: > for example if ICANN delegates .zzz there will be interesting typo attacks > possible in this weird private space In this respect .zz is at least better than .xx which was among the suggestions. > Finally, I agree. People want something semantic and

Re: [DNSOP] draft-ietf-dnsop-svcb-httpssvc-01 feedback

On 12/6/19 11:43 PM, Eric Orth wrote: > Section 1.3: Compared to previous drafts, not much value anymore in > SvcFieldPriority being a first-class field outside SvcFieldValue. [...] There's still advantage for resolvers implementing the chain-jumping (Sec. 4); it allows them to avoid looking

Re: [DNSOP] Last Call: (A Common Operational Problem in DNS Servers - Failure To Communicate.) to Best Current Practice

On 12/16/19 10:39 AM, Stephane Bortzmeyer wrote: > Do we agree that Knot is wrong and the draft is right? Or is FORMERR > acceptable? The discrepancy should disappear eventually: https://gitlab.labs.nic.cz/knot/knot-dns/commit/2b31ee57a7c I personally do have occasional issues finding out which

Re: [DNSOP] Call for Adoption: draft-nygren-dnsop-svcb-httpssvc

Hello; I do support adoption. On 10/7/19 4:52 PM, Stephen Farrell wrote: The main caveat for me is I don't know if it'd be worth publishing an RFC if this doesn't end up getting deployed in browsers. So getting clarity there as early as poss would be good if we can. I agree, but I wouldn't

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/25/20 8:07 PM, Andrew M. Hettinger wrote: > Frankly, you've got it exactly the wrong way around: even with httpsvc > speced out completely, it will take time for it to be deployed to > browsers. That's assuming you can get enough buying from (mostly) > google to even make it happen at all. I

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/27/20 4:51 AM, Lanlan Pan wrote: > [...] > Just configure ANAME in the zonefile,  authortitative return response > is CNAME, no ANAME. > If enable DNSSEC, this will cause some dynamic signature > calculation（ECDSA will be better). I would (generally) NOT recommend sending CNAME in answer in

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/26/20 11:28 PM, Andrew M. Hettinger wrote: > Is there actually a commitment from browser makers to implement it? > [...] > But let's be clear, the biggest group that we need buy-in from are the > chromium devs. Without them, this isn't worth the bits we've sent down > the wire discussing it.

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-7706bis-07

On 2/28/20 2:02 PM, Ines Robles via Datatracker wrote: > 1- Appendix B.5: it seems that the link is not valid: resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc- >7706> > > This link worked for me: >

Re: [DNSOP] rrserial as a path to fame and fortune (was: Adoption of new EDNS opcode "rrserial")

Hello. On 1/29/20 11:57 AM, Shane Kerr wrote: > One possible application of this might be to allow a resolver to > extend the TTL of an entire zone. Overall I suspect the TTL-extending use case might be sufficiently different (and much more complicated) to consider separately/independently. >

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/21/20 1:04 PM, Klaus Malorny wrote: > according to my colleagues, who are in contact with the customers, the > use case is mostly in the context of CDNs. Some of them maintain a > larger set of domains with alternate spellings of their product names, > with different ccTLDs, some for

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/21/20 3:01 PM, Klaus Malorny wrote: > simply that I want to get rid of it. IMHO one aim of a new technology > should be to make old technology obsolete, esp. such workarounds. If I > have to keep them (forever?), where is the benefit (for me as a company)? I see.  You'd like to deploy

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/21/20 2:23 PM, Klaus Malorny wrote: > I see a major drawback in comparison to the ANAME draft, namely that > there seems to be no fallback for old browsers (and robot software > accessing websites) being defined. Of course, authoritative name > servers could implement a similar mechanism as

Re: [DNSOP] DNS stamps

On 1/9/20 6:37 PM, Ted Lemon wrote: > On Jan 9, 2020, at 9:21 AM, Vladimír Čunát <mailto:vladimir.cunat+i...@nic.cz>> wrote: >> Depends what you'd want from the stamps. > If the stamps make assertions about what service is offered, I’d want > that to be verifiable.  [.

Re: [DNSOP] DNS stamps

These stamps do contain interesting ideas, I believe. On 1/9/20 5:13 PM, Ted Lemon wrote: > In order for this to actually be useful, two things would be required. > > 1. The assertions about resolver behavior (e.g., logging, etc) would > have to be signed > [...] Depends what you'd want from the

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

On 1/7/20 3:15 AM, Michael StJohns wrote: >>> >>> 1) A recommendation for the maximum size of the zone [...] >> I am reluctant to add this.  As John said, I think it won't age well. >> [...] > > As I suggested in one of my messages, giving an idea of how long it > takes to digest various sizes of

Re: [DNSOP] SVCB chain lengths

On 12/23/19 9:22 PM, Eric Orth wrote: > 2) Any chain limiting enforcement only applies to stubs following > chains, not recursives. > > Recursives are already following CNAMEs without a standardized limit. > [...] (I'm a bit late, I'm sorry.)  Recursives *in practice* seem quite limited.  Unbound

Re: [DNSOP] New draft on delegation revalidation

On 4/22/20 9:32 PM, Shumon Huque wrote: > Since delegation records and glue address records are unsigned, they > can be spoofed, and DNSSEC should really allow us to detect such > spoofing once a resolver sees referral data. I wouldn't put much energy into improving this part in *this* draft. 

Re: [DNSOP] Validating responses when following unsigned CNAME chains...

On 4/30/20 2:01 AM, Shumon Huque wrote: > It definitely can't set the AD bit. So, I suppose your argument is why > bother authenticating the target. That's a defensible question. [...] Certainly not defensible.  The AD bit isn't the only part.  What if the CNAME target is spoofed (BOGUS) or

Re: [DNSOP] Privacy and DNSSEC

Original subject: New draft on delegation revalidation On 4/24/20 4:49 PM, Shumon Huque wrote: > > Even DNSSEC-validated NSs and IPs aren't sufficient to ensure privacy, > so I'd rather kill this problem by proper encrypted protocol towards > authoritatives (in current dprive

Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

On 5/12/20 3:24 AM, John Levine wrote: > It doesn't seem like a bad idea but I'm wondering who's likely to > implement it, since that makes it much more interesting. Knot DNS has an implementation already.  It's not merged and can't create catalog zones yet, but we expect to support it in future.

Re: [DNSOP] I-D Action: draft-pwouters-powerbind-04.txt

Hello, I'm still a bit skeptical. 1. Validation without logging. At the end of 3.1 you claim that mode is still useful.  When I focus on intentional attacks, signing a malicious DS seems among the easiest ones, and that can't be detected without the attacked machine doing logging (the DS might be

Re: [DNSOP] I-D Action: draft-pwouters-powerbind-04.txt

On 5/7/20 6:06 AM, Paul Wouters wrote: > On Tue, 5 May 2020, Vladimír Čunát wrote: >> 1. Validation without logging. >> At the end of 3.1 you claim that mode is still useful.  When I focus on >> intentional attacks, signing a malicious DS seems among the easiest >> ones,

Re: [DNSOP] DNSSEC actual failures log where?

On 5/14/20 4:50 PM, Bob Harold wrote: > I am preparing to enable DNSSEC validation, so I am working on alerts > for failed validations, so I can see whether they are user errors > (that might need negative trust anchors or other exceptions) or actual > attacks. > But it seems that the "dnssec"

Re: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses)

Hello. On 5/28/20 10:00 AM, Shane Kerr wrote: > As I have mentioned several times on microphone, I think this draft > has huge potential, potentially cutting the number of queries handled > by recursive resolvers almost in half - since they could ask for A and > records in a single query.

Re: [DNSOP] draft-ietf-dnsop-delegation-only​: exchanging DS set

On 7/31/20 2:34 PM, Paul Wouters wrote: > The process of a rogue parent is not a purely technical one. It can include a > legal system, a payment dispute, and many other things. > > Per definition, it will be a manual process to confirm if a “changed child” > is a legitimate change or not.

Re: [DNSOP] Algorithm implementation recommendations in 8624

On 6/17/20 8:30 AM, Mats Dufberg wrote: >> 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. > > What strikes

Re: [DNSOP] DNS RR Type Allocation Request

On 6/16/20 11:05 PM, Brian Dickson wrote: > Nit: I think this should be "code points" (plural), one for HTTPS and > one for SVCB, right? There's even a new registry to be added.  Whole IANA section should get "executed", I expect. --Vladimir ___ DNSOP

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

On 6/18/20 7:22 PM, Ted Lemon wrote: >> I suspect it will work like every other locally-served domain or >> every other private namespace that exists today, i.e. just fine with >> no configuration changes expected or required on dependent >> (downstream) DNS clients. And if there are new species

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On 6/19/20 6:20 AM, Martin Thomson wrote: > As long as the space of codepoints isn't too small (2^16 is fine), then I see > no reason not to allow external publications request a value as long as they > don't abuse the privilege. The space for DNSKEY and DS algorithms is one octet, so each of

[DNSOP] draft-ietf-dnsop-delegation-only​: exchanging DS set

Hello dnsop. Let me start a simple thought experiment - attacking the planned scheme.  It feels like I'm missing some part of the defense. A .evil registry is using the DELEGATION_ONLY flag.  They additionally sign a different victim.evil DS set, say adding hash of a DNSKEY they generated

Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-00.txt

I'm sorry for the delay. On 11/19/20 8:47 AM, P Vixie wrote: > On Tue, Nov 17, 2020 at 09:32:09AM +0100, Vladim??r ??un??t wrote: >> I think the draft should also mention glue *addresses* [...] > do you mean where the NSDNAME is in-zone and there is a non-authoritative > copy of the or A RRs

Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)

Hello. From resolver point of view... this implies that signed *positive* wildcard answers will now get cached with this shorter "negative TTL", right?  These do need to deny existence of non-wildcard match, so they need to contain NSEC*. Maybe the final text would better explicitly note

Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-00.txt

Hello. I think the draft should also mention glue *addresses*, as that's another closely related piece that often comes from the parent side (and is also unavoidable to use in some situations).  Even if that means not really recommending anything about them, though I'd personally expect these to

[DNSOP] draft-hoffman-dnssec-iana-cons

Hello. I didn't speak but I'd still like to indicate my support.  Requiring "Standards Action" just to allocate algorithm numbers seems quite an overkill.  I'd find it healthy to split that into an easier step, so it's also clearly separable from endorsing or even requiring support for those

Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)

On 1/6/21 9:01 PM, Peter van Dijk wrote: On Sat, 2020-12-12 at 11:46 +0100, Vladimír Čunát wrote: From resolver point of view... this implies that signed *positive* wildcard answers will now get cached with this shorter "negative TTL", right? These do need to deny existence of no

Re: [DNSOP] NSA says don't use public DNS or DoH servers

On 1/22/21 3:10 AM, Tom Pusateri wrote: Would it be ok to allow DNSSEC signed responses from any server? If they’re signed and verified, does it matter how you got them? Another missing part is privacy, i.e. even if you get exactly the same answers, it doesn't imply you get similar (privacy)

Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)

On 1/13/21 10:28 AM, Peter van Dijk wrote: That all said, I now no longer think we need to do a whole update/clarification thing on this, but I will add a note to my document saying that changing the NSEC TTL might affect wildcards, as you requested earlier. Sounds good to me.  Thanks.

Re: [DNSOP] IETF meeting prep and what

On 18/06/2021 19.40, Peter van Dijk wrote: aname can go; I trust the WG feels SVCB will supersede it. Yes, please. I propose replacing rfc5011-security-considerations with a short document deprecating 5011 in its entirety. I am happy to write text for that, if there is an appetite - when

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On 11. 05. 21 1:59, Brian Dickson wrote: IMNSHO, it'll be faster to discard any existing parsing code, and embrace this as the Zone File format (and wire format) going forward. I think that would imply burning the currently allocated RRtype code pair and requesting a new pair from IANA.  Not

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

On 10. 05. 21 10:19, Petr Špaček wrote: I think the proper solution should be a real multi-query option, which incidentally provides a superset of RRSERIAL capabilities. If multi-queries require the records being in sync (if from the same zone), I really dislike the implications of them being

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance

On 11/05/2021 18.17, Wes Hardaker wrote: I'd also expect something on limits accepted by secondaries.  And some details are probably up to further discussion (e.g. particular numbers and SERVFAIL), but I don't think such details would block adoption. That's certainly an interesting thing to

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance

I like the document, but the section on validators recommends not to follow requirements from RFC 5155, so I don't expect that best-practice track is sufficient.  And I do think we need a similar update to 5155, be it in this document or a separate one. I'd also expect something on limits

Re: [DNSOP] New version of draft-ietf-dnsop-rfc7816bis after WG last call

We're looking for comments before Monday April 26th. I'm sorry.  Better slightly late than never, I suppose.  The whole text seems good to me, except for a small issue: In step (6) of the algorithm it might better be noted that in case xNAME is in ANSWER, the RCODE is irrelevant.  Now the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-iana-cons-00.txt

Hello. I'm quite surprised that the IANA section of the draft includes that registering *flags* is also changed from "Standards Action" to "RFC Required".  While the algorithm space is rather large, that certainly doesn't apply to the NSEC3 and NSEC3PARAM flags (only 7 remain free).

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dnssec-iana-cons-00.txt

On 3/11/21 4:38 PM, Paul Hoffman wrote: I'm quite surprised that the IANA section of the draft includes that registering*flags* is also changed from "Standards Action" to "RFC Required". While the algorithm space is rather large, that certainly doesn't apply to the NSEC3 and NSEC3PARAM flags

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-intentionally-temporary-insec-00.txt

Hello. I'm certainly not fond of trying to call this "best practice". I'd rather try persuading people to either improve such tooling or switch production to another one, but I understand that in real life there are cases where the proposed approach may be considered a better choice than a

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

For the limit on total number of connections: "Absent any other information, 150 is a reasonable value for this limit in most cases." [...] Maybe this could use a clarification that 150 is good advice only if you _don't_ have any "TCP-only" clients, like e.g. DoT stubs? I would not be so

Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

On 15/09/2021 16.41, Daniel Migault wrote: Outside experimentation, especially for national algorithms, this will lead to nations having their algorithms qualified as standard while other nations having their algorithms qualified as non standard. I would like to understand why this cannot be a

  1   2   >