[DNSOP] Re: [EDE] Registering a few more error codes

On Wed, Sep 11, 2024 at 03:22:58PM +0200, Stephane Bortzmeyer wrote a message of 14 lines which said: > In the current registry for Extended DNS Error Codes (RFC 8914), there > are codes that may be interesting to add: Following the discussion, a small I-D (not necessary, process-wis

[DNSOP] Re: RFC for web3 wallet mapping using DNS

On Tue, Sep 17, 2024 at 11:51:11PM -0700, Shay C wrote a message of 59 lines which said: > Forgive me, but I'm not clear if the WALLET RRtype is a proposal or if it > has been ratified. I see references to it in the IANA registry so I'm > assuming it has been assigned and is currently usable?

[DNSOP] Re: RFC for web3 wallet mapping using DNS

On Tue, Sep 17, 2024 at 11:09:12PM -0700, Shay C wrote a message of 53 lines which said: > I was hoping to get feedback on an RFC draft I have been working on for > web3 wallet mapping using DNSSEC and the DNS system. It would be interesting to discuss the relationship with the existing WALLE

[DNSOP] Re: DNSOP[EDE] Registering a few more error codes

On Tue, Sep 17, 2024 at 03:16:43PM +0200, Petr Špaček wrote a message of 30 lines which said: > I think EDE 29 (Synthesized) with text note "RFC 8482" is perfectly > appropriate for the made-up HINFO answer to ANY (or RRSIG or ...) query. I tend to disagree since RFC 8482 is about removing da

[DNSOP] Re: DNSOP[EDE] Registering a few more error codes

On Mon, Sep 16, 2024 at 08:23:43AM -0700, Wes Hardaker wrote a message of 38 lines which said: > > * One to say that the response was deliberately minimal (RFC 8482) > For #1 - a more exact definition would be helpful. Minimal how? > One thing we discovered writing the EDE draft is that it w

[DNSOP] Re: [Ext] [RESINFO] Registering a "DNSSEC validation" resolver information key?

On Wed, Sep 11, 2024 at 03:00:52PM +, Paul Hoffman wrote a message of 31 lines which said: > This is an interesting proposal, but it should instead be sent to > the ADD WG, given that RFC 9606 and friends came from there, not > DNSOP. Done. And I also made an I-D, draft-bortzmeyer-resinfo

[DNSOP] [EDE] Registering a few more error codes

In the current registry for Extended DNS Error Codes (RFC 8914), there are codes that may be interesting to add: * One to say that the response was deliberately minimal (RFC 8482) * One to say that the response comes from a local root (RFC 8806) * One to say that the response has been tailored bec

[DNSOP] [RESINFO] Registering a "DNSSEC validation" resolver information key?

In the current registry for DNS Resolver Information Keys (RFC 9606), there is no key to indicate that the resolver validates with DNSSEC. For me, it is an important criterion to evaluate a resolver. I am thinking about asking for a registration. Policy for this registry is "specification required

[DNSOP] Re: [Ext] Revised the application for the WALLET RRTYPE

On Mon, Jul 01, 2024 at 07:20:19PM +, Paul Hoffman wrote a message of 8 lines which said: > Thanks again for the input on the new RRTYPE. I submitted it to the RRTYPE > expert reviewers, and the new definition is posted at >

[DNSOP] Re: [Ext] Revised the application for the WALLET RRTYPE

On Mon, Jul 01, 2024 at 07:20:19PM +, Paul Hoffman wrote a message of 8 lines which said: > I submitted it to the RRTYPE expert reviewers, and the new > definition is posted at > . Are there examples in the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

On Sat, Mar 16, 2024 at 01:27:00PM -0700, Shumon Huque wrote a message of 236 lines which said: > > * is there an EDE which is recommended when replying to an > > explicit request for a meta-type (like QTYPE=NXNAME)? > > It doesn't, but could. I don't see an obviously applicable EDE code tha

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

On Mon, Mar 04, 2024 at 02:15:55PM -0800, internet-dra...@ietf.org wrote a message of 48 lines which said: > Internet-Draft draft-ietf-dnsop-compact-denial-of-existence-03.txt is now > available. It is a work item of the Domain Name System Operations (DNSOP) WG > of the IETF. I just implement

Re: [DNSOP] QNAME minimization is bad

On Fri, Nov 10, 2023 at 02:45:08PM +, Denny Watson wrote a message of 50 lines which said: > One thing that is of interest to me; There appears to be no way for > the owner of the dataset being queried (they should understand what > exists in their zones better than anyone else) to signal

Re: [DNSOP] QNAME minimization is bad

On Fri, Nov 10, 2023 at 01:26:36PM +0100, John R Levine wrote a message of 39 lines which said: > asking if anyone has > thought about this problem: The dnsop working group, may be :-) This issue is mentioned in RFC 9156, section 2.3, which documents ways to address it. > I'd like to write

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

On Mon, Aug 01, 2022 at 02:31:48PM +0200, Independent Submissions Editor (Eliot Lear) wrote a message of 89 lines which said: > Whether that means using TLD labels that begin with _ or whether > that means suffixing them with ".ALT", I leave to you experts to > sort.  I do agree with Martin th

Re: [DNSOP] Testing SVCB/HTTPS records

On Wed, Jan 19, 2022 at 10:08:48AM +, Stephen Farrell wrote a message of 231 lines which said: > I made a test setup for my TLS/ECH work. [1] Happy to > take PRs or tweak if it's useful to others. It seems it does not address the same thing. I was thinking of testing *actual* published SV

[DNSOP] Testing SVCB/HTTPS records

Does anyone know a service/software to check the consistency between SVCB/HTTPS DNS records and the Web site? Such as testing the various alpn, the various IP addresses hints, the aliases, etc. (It seems ssllabs.com don't do it yet.) I suspect that many people will put wrong SVCB/HTTPS records...

Re: [DNSOP] Deprecating infrastructure .INT domains

On Fri, Nov 12, 2021 at 08:46:35AM -0500, Joe Abley wrote a message of 25 lines which said: > The operational decisions relating to these things have already been > made, as I understand it -- the delegations no longer exist. nsap.int and tpc.int still exist.

Re: [DNSOP] updated to draft-wing-dnsop-structured-dns-error-page-01

On Fri, Nov 12, 2021 at 03:26:04PM +0100, Stephane Bortzmeyer wrote a message of 27 lines which said: > Moreover, I have serious doubts that DNS configuration errors could be > meaningfully reported to end users. It would be very difficult to make > them understandable and, since we

Re: [DNSOP] updated to draft-wing-dnsop-structured-dns-error-page-01

On Thu, Nov 11, 2021 at 12:59:42PM +0100, Vittorio Bertola wrote a message of 24 lines which said: > I don't want to speak for them (I don't know if they are on this > list, but they definitely are on ADD) but in past discussions around > this concept they recognized its potential usefulness (

Re: [DNSOP] draft-moura-dnsop-negative-cache-loop

On Mon, Nov 08, 2021 at 08:49:03AM +0100, Giovane C. M. Moura wrote a message of 58 lines which said: > We wrote a new draft that adds a new requirement to existing solutions: > recursive resolvers must detect and negative cache problematic (loop) > records. I basically agree with Petr Špaček

Re: [DNSOP] Fwd: I-D Action: draft-ietf-dnsop-rfc5933-bis-06.txt

On Fri, Nov 12, 2021 at 01:59:52PM +0100, Dmitry Belyavsky wrote a message of 153 lines which said: > New version of the draft is uploaded. I would like to have to additions, if you have time: * a section summarizing the changes since RFC 5933. It seems it is just GOST R 34.10-2001 replaced

Re: [DNSOP] IPR Disclosure VeriSign, Inc.'s Statement about IPR related to draft-ietf-dnsop-qname-minimisation and RFC 7816

On Thu, Oct 14, 2021 at 09:17:43AM -0700, IETF Secretariat wrote a message of 11 lines which said: > An IPR disclosure that pertains to your RFC entitled "DNS Query Name > Minimisation to Improve Privacy" (RFC7816) was submitted to the IETF > Secretariat on 2021-10-14 and has been posted on th

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

On Mon, Jun 14, 2021 at 10:03:22AM -0400, Hugo Salgado wrote a message of 55 lines which said: > In the case of NXDOMAIN, the reason for not adding RRSERIAL is > because the response already has the SOA in the AUTHORITY, which > would make it redundant. OK, I see. Here are two implementations

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

On Thu, Jun 10, 2021 at 04:26:44PM -0700, Shivan Kaul Sahib wrote a message of 164 lines which said: > Hi all, Shumon and I have been working on an early draft that > surveys current DNS domain verification techniques. Depending on how > it goes, we hope to eventually explore if we can come up

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

On Fri, Jun 11, 2021 at 07:36:00AM -0700, internet-dra...@ietf.org wrote a message of 39 lines which said: > Title : The "RRSERIAL" EDNS option for the SOA serial of a > RR's zone > Authors : Hugo Salgado > Mauricio Vergara Ereche >

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-rfc7816bis-09

On Sun, Jun 06, 2021 at 11:13:23PM -0700, Suhas Nandakumar via Datatracker wrote a message of 72 lines which said: > I am the assigned Gen-ART reviewer for this draft Thanks for the review. > Section 2.3 > 1. MAX_MINIMISE_COUNT and MINIMISE_ONE_LAB - are the values for these > constants > n

Re: [DNSOP] A draft about the Name:Wreck problem draft-dashevskyi-dnsrr-antipatterns

On Wed, Apr 14, 2021 at 11:01:42AM +0200, Stephane Bortzmeyer wrote a message of 10 lines which said: > The Name:Wreck compression pointer issue Also <https://www.scmagazine.com/home/security-news/vulnerabilities/namewreck-is-the-latest-collision-between-tcp-ip-and-the-standards-p

Re: [DNSOP] A draft about the Name:Wreck problem draft-dashevskyi-dnsrr-antipatterns

On Wed, Apr 14, 2021 at 11:01:42AM +0200, Stephane Bortzmeyer wrote a message of 10 lines which said: > The Name:Wreck compression pointer issue > <https://www.forescout.com/company/resources/namewreck-breaking-and-fixing-dns-implementations> Regarding dnsop work, the same report

[DNSOP] A draft about the Name:Wreck problem draft-dashevskyi-dnsrr-antipatterns

The Name:Wreck compression pointer issue illustrates the implementation problems of DNS. I just find that there is an Internet-Draft, draft-dashevskyi-dnsrr-antipatterns, discussing these problems. Seems

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

On Mon, Jan 18, 2021 at 04:27:20PM -0500, John Levine wrote a message of 18 lines which said: > They think DoH is swell, but not when it bypasses security controls > and leaks info to random outside people I will certainly do as the NSA says, since they are experts in privacy-related issues

Re: [DNSOP] Tell me about tree walks

On Sun, Nov 22, 2020 at 10:56:58AM -0500, John R Levine wrote a message of 17 lines which said: > I don't see why, since it only acts as a default. Any registrant > that cares which CA they use can publish their own CAA. Yes but many registrants don't know about CAA or did not pay attention

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-06.txt

On Wed, May 06, 2020 at 03:19:36PM +, Wessels, Duane wrote a message of 153 lines which said: > The changes from -05 to -06 of this document include: The draft just expired. Any news? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/m

Re: [DNSOP] private-use in-meeting chat comments

On Tue, Nov 17, 2020 at 10:51:45PM +, Tony Finch wrote a message of 32 lines which said: > if the domain points at AS112 then almost anyone might receive the > QNAME leakage; if the domain is unregistered and the resolver does > qmin then there's less leakage. > > This is really a general

Re: [DNSOP] Tell me about tree walks

On Wed, Nov 11, 2020 at 09:39:38PM +, Tony Finch wrote a message of 34 lines which said: > Well, the other Very Prominent example is CAA records, which also > involve walking up the tree to discover policy. It would be nice if > things like CAA and DMARC could agree with each other about h

Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call

On Wed, Oct 14, 2020 at 07:15:10PM +0100, Tony Finch wrote a message of 53 lines which said: > Section 3, algorithm step 5: what is a "hidden QTYPE"? The original QTYPE, which may be "hidden" by a substitution to another QTYPE (see section 2 "a QTYPE selected by the resolver to hide the origi

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.txt

On Fri, Aug 23, 2019 at 05:08:59PM -0700, Erik Kline wrote a message of 237 lines which said: > +1 from me, fwiw. No discussion since, and the draft is expired. Any news? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/d

Re: [DNSOP] Last Call: (Message Digest for DNS Zones) to Proposed Standard

On Thu, Sep 10, 2020 at 03:03:45PM -0400, Warren Kumari wrote a message of 62 lines which said: > Do you have any suggested text? If so, could you send it to the IETF > LC so it gets captured? Done

Re: [DNSOP] Last Call: (Message Digest for DNS Zones) to Proposed Standard

On Mon, Aug 31, 2020 at 09:05:41AM -0700, The IESG wrote a message of 51 lines which said: > The IESG has received a request from the Domain Name System Operations WG > (dnsop) to consider the following document: - 'Message Digest for DNS Zones' >as Proposed Standard This is not really pa

Re: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-information-01.txt

On Tue, Feb 11, 2020 at 06:23:56PM -0800, internet-dra...@ietf.org wrote a message of 50 lines which said: > Title : DNS Resolver Information Self-publication > Filename: draft-ietf-dnsop-resolver-information-01.txt > The IANA registry (Section 5.2) will never

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-ns-revalidation

On Sun, May 24, 2020 at 05:51:24AM -0400, Tim Wicinski wrote a message of 61 lines which said: > This starts a Call for Adoption for draft-huque-dnsop-ns-revalidation > > The draft is available here: > https://datatracker.ietf.org/doc/draft-huque-dnsop-ns-revalidation/ I think it addresses a

Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements

On Mon, May 04, 2020 at 03:08:20PM -0400, Tim Wicinski wrote a message of 64 lines which said: > This starts a Call for Adoption for > draft-mglt-dnsop-dnssec-validator-requirements I think it is important to have such a document, because DNSSEC failures may seriously endanger the deployment

Re: [DNSOP] On Powerbind

On Tue, Apr 14, 2020 at 08:24:20PM -0400, Paul Wouters wrote a message of 108 lines which said: > > I'm still not able to understand this.  Suppose nic.footld puts a > > statement for humans on their website that says ".footld promises > > to be delegation-only". > > First, this approach does

Re: [DNSOP] New draft on delegation revalidation

On Sat, Apr 11, 2020 at 09:22:42AM -0400, Shumon Huque wrote a message of 138 lines which said: > I've heard proposals in the past that TLDs should routinely scan all > their delegations to identify such problems, but I gather this is a > challenging requirement to impose on them for various r

Re: [DNSOP] New draft on delegation revalidation

On Sat, Apr 11, 2020 at 09:22:42AM -0400, Shumon Huque wrote a message of 138 lines which said: > > The delegation (re)validation might be a reasonable place to > > implement something to detect this and adjust the choice of NS on > > the resolver's cache. > > I think most resolvers do a bit

[DNSOP] DNS stamps

Could be useful specially for secure and public resolvers, may be worth of some IETF work? https://github.com/DNSCrypt/dnscrypt-proxy/wiki/stamps ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

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

On Thu, Dec 05, 2019 at 06:00:39PM -0800, The IESG wrote a message of 53 lines which said: > The IESG has received a request from the Domain Name System Operations WG > (dnsop) to consider the following document: - 'A Common Operational Problem > in DNS Servers - Failure To Communicate.' >

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 a message of 90 lines which said: > We had such great comments the first time we did a Working Group > Last Call for draft-ietf-dnsop-extended-error, that the chairs > decided a second one would be even better. IMHO, the document is

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

On Mon, Feb 19, 2018 at 10:00:39AM -0500, Suzanne Woolf wrote a message of 17 lines which said: > We’ve let the discussion continue because it’s been so active, but > we also haven’t forgotten we need to review and determine next steps > on this draft. I don't find anything about the decision

Re: [DNSOP] AD review of draft-ietf-dnsop-serve-stale-07

On Wed, Sep 11, 2019 at 12:06:23PM -0400, Barry Leiba wrote a message of 75 lines which said: > I wonder if it makes sense to be more explicit here that one isn’t > meant to keep using expired data forever, but is expected to keep > trying to refresh it. So, maybe?: > > NEW > If the da

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

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 impact of stale negative responses. It's not true, the last two paragraphs of section 10 do it. May be, as re

Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

On Mon, Apr 29, 2019 at 05:00:38PM -0700, internet-dra...@ietf.org wrote a message of 41 lines which said: > Title : Terminology for DNS Transports and Location > Author : Paul Hoffman > Filename: draft-hoffman-dns-terminology-ter-01.txt Seen o

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On Mon, Jul 08, 2019 at 05:27:21PM +, Michael J. Sheldon wrote a message of 23 lines which said: > And it still leaves the issue that recursives should not just keep > hammering the lame delegations when they've gotten a REFUSED > response. Sorry for being late in the discussion but draft

Re: [DNSOP] I-D Action: draft-livingood-dnsop-dont-switch-resolvers-04.txt

On Mon, Feb 18, 2019 at 02:06:59PM -0800, internet-dra...@ietf.org wrote a message of 48 lines which said: > Title : In Case of DNSSEC Validation Failures, Do Not > Change Resolvers > Author : Jason Livingood > Filename: draft-livingood-dnsop-d

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

On Mon, Mar 11, 2019 at 03:08:10PM -0700, internet-dra...@ietf.org wrote a message of 46 lines which said: > Title : Extended DNS Errors > Authors : Warren Kumari > Evan Hunt > Roy Arends >

Re: [DNSOP] [hrpc] Proposal for a side-meeting on services centralization at IETF 104 Prague

On Mon, Mar 11, 2019 at 05:58:13PM +0100, Stephane Bortzmeyer wrote a message of 19 lines which said: > [Sorry for the long list of working groups but the discussion already > started in different places.] > It was suggested to have a side meeting in Prague at IETF 104. I

Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients

On Tue, Mar 12, 2019 at 04:55:11PM +0100, Neil Cook wrote a message of 22 lines which said: > Actually many enterprises (particularly banks etc.) do not allow DNS > resolution directly from employee endpoints. They block UDP/53, which is not the same thing. Malware or non-cooperating applica

Re: [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients

On Sun, Mar 10, 2019 at 11:17:43PM -0700, Paul Vixie wrote a message of 36 lines which said: > > You claim the right to impose your rules, because it is "your network". > > Yet you have to define ownership. > my network, my rules. your provider's network, their rules. I clearly disagree. If

Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients

On Mon, Mar 11, 2019 at 09:59:11AM +0530, nalini elkins wrote a message of 231 lines which said: > Companies also (validly, in my opinion) wish to know if their > employees are going to fantasyfootballgame.com while they are > supposedly doing work and of course, other sites which people shoul

Re: [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients

On Sun, Mar 10, 2019 at 10:24:56PM -0700, Paul Vixie wrote a message of 82 lines which said: > set up a war between end users and network operators, Well, the tussle already exists. It does not depend on whether you like it or not, on whether the IETF approves it or not. When people have diff

Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients

On Mon, Mar 11, 2019 at 08:55:18AM +0530, nalini elkins wrote a message of 202 lines which said: > The questions that the Fortune 50 company architect asked were something > like this: > > 1. You mean that DNS could be resolved outside my enterprise? I suggest to explain to this person that

Re: [DNSOP] [Doh] Proposal for a side-meeting on services centralization at IETF 104 Prague

On Tue, Mar 12, 2019 at 08:14:49PM +1100, Mark Nottingham wrote a message of 32 lines which said: > I'm also very conscious that we had a side meeting about similar > issues in Singapore (IIRC), and didn't make much progress at all in > that time. This time, we have drafts (poor ones, IMHO, b

Re: [DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague

On Mon, Mar 11, 2019 at 06:57:03PM +0100, Vittorio Bertola wrote a message of 18 lines which said: > Moreover, centralization is not the only Do*-related problem > category that has been raised (my draft alone lists eight others). IMHO, this is precisely the biggest problem with these three d

Re: [DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague

On Mon, Mar 11, 2019 at 01:59:25PM -0400, Allison Mankin wrote a message of 94 lines which said: > Perfect idea, very good use of the Wednesday slot. New date and place registered at , wednesday, Karlin 1/2, 1500 to 1700. (Note the

Re: [DNSOP] [Doh] Proposal for a side-meeting on services centralization at IETF 104 Prague

On Mon, Mar 11, 2019 at 10:06:21AM -0700, Ted Hardie wrote a message of 76 lines which said: > This conflicts with SECDISPATCH, which will have a pretty serious impact on > who might attend. Scheduling these things is very hard, obviously. Given > this topic, you may have to move outside the

[DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Resent with the correct list of working groups.] [Sorry for the long list of working groups but the discussion already started in different places.] There are been some discussion about DoH (DNS-over-HTTPS, RFC 8484) deployment and the risk of centralization of Internet services. (See for instan

[DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Sorry for the long list of working groups but the discussion already started in different places.] There are been some discussion about DoH (DNS-over-HTTPS, RFC 8484) deployment and the risk of centralization of Internet services. (See for instance drafts [this is not an endorsement] draft-bertol

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

On Sat, Mar 09, 2019 at 11:01:33PM -0800, Paul Vixie wrote a message of 32 lines which said: > i have been away as long as possible, which means i was surprised > that the IESG was willing to allow a document to standardize I'm not surprised, since, in the last years, there have been a strong

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

On Sun, Mar 10, 2019 at 03:48:52PM +0900, Warren Kumari wrote a message of 281 lines which said: > I think it would be very valuable to not conflate DNS-over-HTTPS > (the protocol) with the "applications might choose to use their own > resolvers" concerns. I fully agree. Applications using t

[DNSOP] Making domains work even when connectivity fails (Was: the root is not special, everybody please stop obsessing over it

On Fri, Feb 15, 2019 at 09:29:29AM -0500, Bob Harold wrote a message of 73 lines which said: > I think in most solutions, if the name servers for " > malware-c-and-c-as-a-service.com" and "com" are both unreachable, > the domain should continue to resolve. But if "com" is reachable, > and say

Re: [DNSOP] the root is not special, everybody please stop obsessing over it

On Thu, Feb 14, 2019 at 01:57:14PM -0800, Paul Vixie wrote a message of 42 lines which said: > the fact that i have to hotwire my RDNS cache with local zone glue > in order to reach my own servers when my comcast circuit is down or > i can't currently reach the .SU authorities to learn where V

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

On Fri, Feb 15, 2019 at 09:34:16AM +, Jim Reid wrote a message of 19 lines which said: > Why? From the client's perspective, there's no effective difference > between these. In the first case, you can talk with someone which you have some relationship with (the ISP, typically). > Their r

Re: [DNSOP] Fwd: New Version Notification for draft-mayrhofer-did-dns-01.txt

On Fri, Feb 08, 2019 at 02:58:38PM +0100, Alexander Mayrhofer wrote a message of 59 lines which said: > Feedback highly appreciated, I think that it is an important work because it brings the power of the DNS to many other identifier systems. So, I support it. May be more examples could help

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

On Thu, Feb 14, 2019 at 08:51:25PM +0100, Stephane Bortzmeyer wrote a message of 101 lines which said: > Otherwise, I suggest to add an error code: Ooops, I forgot one: SERVFAIL Extended DNS Error Code 8 - No reachable authority The resolver could not reach any of the authoritat

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

On Thu, Feb 14, 2019 at 03:33:23PM -0500, Warren Kumari wrote a message of 388 lines which said: > but how about: > "The majority of these extended error codes are primarily useful for > resolvers, to return to stub resolvers or to downstream > resolvers. Authoritative servers may also use thi

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

On Mon, Jan 07, 2019 at 12:30:10PM -0800, internet-dra...@ietf.org wrote a message of 44 lines which said: > Title : Extended DNS Errors > Authors : Warren Kumari > Evan Hunt > Roy Arends >

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

On Thu, Feb 07, 2019 at 04:47:01PM +0100, Petr Špaček wrote a message of 129 lines which said: > > 4.1.1. NOERROR Extended DNS Error Code 1 - Unsupported DNSKEY Algorithm > > > >The resolver attempted to perform DNSSEC validation, but a DNSKEY > >RRSET contained only unknown algorith

Re: [DNSOP] extension of DoH to authoritative servers

On Thu, Feb 14, 2019 at 04:58:38PM +0800, zuop...@cnnic.cn wrote a message of 126 lines which said: > if an DNSSEC_enabled authotative server(no matter it is Alice or > Bob) is evil and modifies DNS records, it will succeed because it > has private key It is completely false. (You seem to th

Re: [DNSOP] extension of DoH to authoritative servers

On Thu, Feb 14, 2019 at 04:31:35PM +0800, zuop...@cnnic.cn wrote a message of 74 lines which said: > > for instance a DoH or DoT server that intentionally or > > accidentally returns false data. DNSSEC can counter that. > > I dont understand why. > If a server intentionally returns false d

Re: [DNSOP] extension of DoH to authoritative servers

On Thu, Feb 14, 2019 at 04:11:20PM +0800, zuop...@cnnic.cn wrote a message of 102 lines which said: > No. i might did not explain it clearly. It was clear but you repeat the same stuff, without taking into account the remarks (or the existing documents, such as draft-bortzmeyer-dprive-resolve

Re: [DNSOP] extension of DoH to authoritative servers

On Thu, Feb 14, 2019 at 02:36:14PM +0800, zuop...@cnnic.cn wrote a message of 86 lines which said: > i think both DNSSEC and DoH(or DoT) can protect DNS data, "Protect" is like "security", a word so vague, which includes so many different (and sometimes contradictory) services that it is not

Re: [DNSOP] extension of DoH to authoritative servers

On Wed, Feb 13, 2019 at 10:51:00PM +0100, Vladimír Čunát wrote a message of 118 lines which said: > 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 pr

Re: [DNSOP] I-D Action: draft-schaller-dnsop-lnp-00.txt

On Wed, Feb 13, 2019 at 02:26:40AM -0800, internet-dra...@ietf.org wrote a message of 47 lines which said: > Title : Local Naming Protocol -- LNP (v.1.0) > Author : Christian Schaller > Filename: draft-schaller-dnsop-lnp-00.txt You do not expla

Re: [DNSOP] extension of DoH to authoritative servers

On Tue, Feb 12, 2019 at 03:32:37PM -0800, Paul Vixie wrote a message of 75 lines which said: > by putting that text in and leaving it in, this becomes a political > project not a technical one. Everything we do is political, the Internet itself is a political project. Thinking that communicat

Re: [DNSOP] extension of DoH to authoritative servers

On Tue, Feb 12, 2019 at 02:45:54PM -0800, Paul Vixie wrote a message of 21 lines which said: > i remember a time when the IAB would have said "no" to an internet > standard which mandated deliberate loss of control by network > operators. Giving the many attacks against network neutrality, it

Re: [DNSOP] extension of DoH to authoritative servers

On Tue, Feb 12, 2019 at 02:18:39PM -0800, Paul Vixie wrote a message of 20 lines which said: > > Right.   So what’s to stop other malicious traffic from doing the > > same thing? > > lack of an IETF-approved standard with planned implementation by a > half dozen tech giants, means that other

Re: [DNSOP] extension of DoH to authoritative servers

On Tue, Feb 12, 2019 at 01:48:36PM -0800, Paul Vixie wrote a message of 46 lines which said: > increased for political reasons. There is nothing wrong with political reasons. Mass surveillance is a political problem (privacy). DNS lies by ISPs is a political problem (network neutrality). It i

Re: [DNSOP] extension of DoH to authoritative servers

On Tue, Feb 12, 2019 at 10:34:19AM -0800, Paul Vixie wrote a message of 15 lines which said: > > How can you be sure folks on your network aren’t already tunneling > > their evil deeds through HTTPS? > > netflow. such traffic _looks_ abnormal. > > the deliberate design premise of DoH is that

Re: [DNSOP] extension of DoH to authoritative servers

On Tue, Feb 12, 2019 at 10:14:19AM -0800, David Conrad wrote a message of 100 lines which said: > Why don’t you force folks on your network to install a certificate > that would allow you to inspect TCP/443 outbound traffic? There are probably many connected things where this is not possible.

Re: [DNSOP] extension of DoH to authoritative servers

On Wed, Feb 13, 2019 at 02:03:26PM +0800, zuop...@cnnic.cn wrote a message of 103 lines which said: > that's ture. but in my view, if the trust chain is built, we can > ensure a resolver(or a cache) is always talking to a identified > server and the channel is always secure, then the content c

Re: [DNSOP] extension of DoH to authoritative servers

On Wed, Feb 13, 2019 at 02:08:19PM +0800, zuop...@cnnic.cn wrote a message of 58 lines which said: > i prefer DoH because it can identify a server we are talking to and the > content is encrypted. To learn about DoT, I suggest you read RFC 7858. _

Re: [DNSOP] extension of DoH to authoritative servers

On Tue, Feb 12, 2019 at 08:32:28AM -0800, Paul Vixie wrote a message of 39 lines which said: > i require all visitors, family members, employees, and apps to use > the control plane i have constructed, which includes DNS > surveillance and control. Reminds me of a sentence which is awfully tr

Re: [DNSOP] extension of DoH to authoritative servers

On Tue, Feb 12, 2019 at 09:07:43AM -0500, Paul Wouters wrote a message of 23 lines which said: > This idea is similar to DNScurve. The problem is that channel > security does not help when you have an infrastructure of DNS > caches, Or when secondary name servers are not under the same organi

Re: [DNSOP] extension of DoH to authoritative servers

On Tue, Feb 12, 2019 at 03:56:04PM +0800, zuop...@cnnic.cn wrote a message of 546 lines which said: > the child zone publishes a TLSA record instead of a DS record in the > parent zone [RFC 6698 may need update]. The TLSA record contains the > certificate that identifies the child zone. The p

Re: [DNSOP] extension of DoH to authoritative servers

On Tue, Feb 12, 2019 at 03:56:04PM +0800, zuop...@cnnic.cn wrote a message of 546 lines which said: > I am considering extending the DoH protocal to authoritative > servers. Why DoH and not DoT? DoH is useful because 1) port 853 may be blocked at the edge of the network 2) applications runnin

Re: [DNSOP] extension of DoH to authoritative servers

On Tue, Feb 12, 2019 at 03:56:04PM +0800, zuop...@cnnic.cn wrote a message of 546 lines which said: > DNSSEC is not necessary anymore This is clearly false. DoH provides _channel security_ DNSSEC provides _content security_ (or object security). This is a very important difference in security

[DNSOP] "The Forgotten Object Lesson Of The Dyn DDoS Attack"

https://www.forbes.com/sites/forbestechcouncil/2018/12/19/the-forgotten-object-lesson-of-the-dyn-ddos-attack/ This article talks about "There have been discussions within the Internet Engineering Task Force, the organization responsible for developing and enhancing internet protocols, to come up w

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

On Wed, Sep 19, 2018 at 07:24:25AM +1000, Mark Andrews wrote a message of 38 lines which said: > As for scripts, you upgrade the tools those scripts use: > curl(libcurl), wget, fetch for SH. File::Fetch for perl. Similar > for the other scripting languages. Very few applications actually > ma

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

On Sun, Sep 16, 2018 at 03:26:56PM +0530, Mukund Sivaraman wrote a message of 66 lines which said: > Adding resolver support (to resolvers that don't have it, i.e., > vs. RFC 1035) does not appear to break current DNS, i.e., it can be > proposed now. [Algorithm deleted] The difficult thing i

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

On Mon, Sep 17, 2018 at 03:51:34AM +, Evan Hunt wrote a message of 124 lines which said: > I don't see how we can responsibly declare a new standard which, if > followed, will break every prior implementation. Apex CNAME is the > sort of solution that's clear, simple, and wrong. +1 > We'

  1   2   3   4   5   6   7   8   >