Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

On Wed, 15 Feb 2023 13:52:03 -0500 Ted Lemon wrote: > It clearly is, in the sense that someone is using it and it keeps > coming up. :) Hi Ted, I'm just catching up on this conversation and maybe I've missed it, but can you point me at the implementation(s) that are setting QDCOUNT > 1? Thanks

Re: [DNSOP] Meaning of lame delegation

On Mon, 3 Apr 2023 20:02:16 + "Wessels, Duane" wrote: > (1) NS.EXAMPLE.ORG resolves to an IP address. Queries to the IP > address result in a REFUSED, SERVFAIL, upward referral, or some other > indication the name server is not configured to serve the zone. May be lame. I could imagine an

Re: [DNSOP] Meaning of lame delegation

On Mon, 10 Apr 2023 13:39:21 + "Wessels, Duane" wrote: > “A lame delegation is said to exist when one or more authoritative > servers designated by the delegating NS rrset or by the apex NS rrset > answers non-authoritatively for a zone”. Perhaps, say "does not answer authoritatively for a z

Re: [DNSOP] Meaning of lame delegation

On Mon, 10 Apr 2023 14:35:36 + Joe Abley wrote: > I continue to think that if you don't get a response, you can't tell > whether the delegation is lame. Lameness (as I use the term) relates > the configuration of the nameserver, not it's availability. > > So I prefer Duane's formulation to y

Re: [DNSOP] Meaning of lame delegation

On Mon, 10 Apr 2023 11:29:36 -0600 Paul Ebersman wrote: > Perhaps if we inverted the logic? I realize this does broaden the > fundamental definition but what if, instead of saying "gave > non-authoritative response" we define lame as "failed to give an > authoritatve/AA response"? Isn't that wha

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

On Mon, 1 May 2023 16:09:23 + Paul Hoffman wrote: > It would be grand if a bunch more people would speak up on this > thread. I'm not particularly satisfied with the requirement that there must be a response to meet the definition, but that seems to be the consensus even if most seem to agre

Re: [DNSOP] WGLC rfc8499bis one week extension for lame delegation definition

On Mon, 01 May 2023 21:15:29 + Joe Abley wrote: > Yes -- some people (not me) would evidently describe a server that > they didn't receive a response from as lame. Lots of people and organizations tend to talk about "types" or "ways" in which a server or delegation is lame. Here are a few we

[DNSOP] Wrapping up draft-ietf-dnsop-dns-tcp-requirements

Friends, Duane and I pushed out a recent update to this draft. There are at least a couple of small TODO items we have to address (search text for TODO) before it can be published, but I think we've exhausted largely what we set out to do for this document and would like to see this wrapped up.

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

On Mon, 19 Apr 2021 07:31:49 -0400 Joe Abley wrote: > NEW: > >The specification of the DNS allows both UDP and TCP to be used >as transport protocols for exchanging unencrypted DNS messages. >However, for various reasons, the availability of TCP transport >has sometimes been int

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

On Thu, 22 Apr 2021 20:23:19 +0100 Tony Finch wrote: > I needed minimal-any when my auth servers were being hammered by lots of > recursive servers making ANY requests; the responses were being truncated > because my servers have for a long time been configured to avoid > fragmentation, and the r

Re: [DNSOP] [art] [Last-Call] Artart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

On Mon, 13 Sep 2021 21:24:37 -0400 Warren Kumari wrote: > As Robert Sparks helpfully pointed out on last-call list, I was only > talking about this "particular potential BCP updating a particular > Informational RFC both in the IETF stream.". Hi Warren et al., I have this in the appendix: T

Re: [DNSOP] Clarifying referrals (#35)

On Mon, 13 Nov 2017 03:26:41 + Andrew Sullivan wrote: > This is quite a helpful response, thanks. I wonder whether more of it > ought to go in discussion (or a new draft), I'd suggest a new draft be produced with which discussion could ensue. The references Paul cites would not be clear to

Re: [DNSOP] Terminology question: split DNS

On Mon, 19 Mar 2018 19:26:42 + "Darcy Kevin (FCA)" wrote: > How about just "disjoint DNS" or "non-synchronized DNS"? Or, to > hijack the Perl motto, TMTOWTRI (There's More Than One Way To Resolve > It :-) Coming up with new names though is less than ideal. The Microsoft community has used s

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

On Thu, 3 May 2018 06:12:42 + Amreesh Phokeer wrote: > We consider "lame" any NS which is either: > - Not responding at all. > - Responding in some way, but not for the specific domain queried. > - Responding for the correct domain, but without the authority bit set. Friends, I've been refe

Re: [DNSOP] are there recent studies of client side/ISP firewalls interfering with EDNS?

On Thu, 12 Nov 2015 08:00:50 -0800 Nicholas Weaver wrote: > We've done some of this in Netalyzr. Captive portals in particular > are a problem, with about 1% of systems measured in Netalyzr unable > to use EDNS0 to get DNSSEC information either from the recursive > resolver OR directly from the

Re: [DNSOP] DNS Delegation Requirements

On Mon, 8 Feb 2016 09:57:15 +0100 Jakob Schlyter wrote: > At this point, we're seeking more public comments - on this mailing > list (unless the chairs disapproves), on the our issue tracker [4] or > via email to the authors. Hello Jakob and Patrik. Some comments as requested. The introduction

[DNSOP] Soliciting feedback for draft-kristoff-dnsop-dns-tcp-requirements

Friends, If I could trouble you to consider reviewing this and provide any comments you might have about it, that would be appreciated. Thank you. DNS Transport over TCP - Operational Requirements Abstract This d

Re: [DNSOP] Preliminary Agenda for

On Thu, 9 Mar 2017 21:29:25 + Tim Wicinski wrote: > * draft-kristoff-dnsop-dns-tcp-requirements > DNS Transport over TCP - Operational Requirements Oh thanks Tim. I wasn't sure if this was going to make it into the WG's plans. I had started a revised version of the draft, which I inte

Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements

On Thu, 11 May 2017 23:25:13 + 神明達哉 wrote: > I've read draft-kristoff-dnsop-dns-tcp-requirements-02. Thank you for taking the time to read, review, and comment on it! > I think RFC7766 already pretty clearly states TCP is a MUST. IETF RFC 7766 does very explicitly declare TCP is a MUST in

Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements

On Tue, 23 May 2017 12:22:34 + Sara Dickinson wrote: > I’ve reviewed this draft and as stated previously support adoption as > a companion document to RFC7766. Thank you for your review. > Section 2.2: I think the argument around DNSSEC can be bolstered by > the fact that recent root ZSK an

Re: [DNSOP] A6 queries

On Wed, 28 Mar 2007 08:47:08 +0200 Roy Arends <[EMAIL PROTECTED]> wrote: > Since this remains unanswered time and time again, and these requests > for A6 types do not seem to diminish, I'm hoping that those that have > access to traffic to a busy resolver are willing to spend some cycli > on

Re: [DNSOP] A6 queries

On Wed, 28 Mar 2007 08:54:09 -0500 John Kristoff <[EMAIL PROTECTED]> wrote: > I have some access to some resolvers that have these. From what I > can see in a cursory look, it is another recursor, probably BIND? er, "another resolve

Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP

On Mon, 1 Oct 2007 10:47:44 -0600 Danny McPherson <[EMAIL PROTECTED]> wrote: > Perhaps expanding in the "Problem Description" section > would be beneficial. Something mentioning that Many > SOHO and broadband access devices provide some flavor > of name resolution services (e.g., there are 4 flav

Re: [DNSOP] Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt (fwd)

On Tue, 2 Oct 2007 21:59:33 -0400 (EDT) Dean Anderson <[EMAIL PROTECTED]> wrote: > In fact, using authority servers is _less_ risk to the abuser, because > to compose the reflector attacks, s/he has to crack into a server, > craft a record, One can create a large record anwhere in the namespace.

[DNSOP] 20,000 open resolvers claim

dnsop, I tried to take it offlist with Dean Anderson, but I cannot seem to get very far. He has not recanted, corrected or otherwise provided any additional, verifiable evidence that would support this statement: 'At great effort, a DNS researcher has compiled a list of about 2 open recu

Re: [DNSOP] Fwd: I-D Action: draft-pappas-dnsop-long-ttl-04.txt

it includes the concern mentioned above. Date: Thu, 22 Mar 2007 17:54:05 -0500 From: John Kristoff To: Lixia Zhang Cc: Daniel Massey , Vasileios Pappas , Steve Crocker Subject: Re: [dns-operations] Seeking input regarding TTL value for infrastructure RRs On Wed, 21 Mar 200

Re: [DNSOP] various approaches to dns channel secrecy

On Fri, 04 Jul 2014 20:04:02 -0700 Paul Vixie wrote: > first, dns data itself is public -- the data is there for anybody to > query for it, if you know what to query for. only the question, > questioner, and time can be kept secret. answers are only worth > keeping secret because they identify th

Re: [DNSOP] Workshop on DNS Future Root Service Architecture, Hong Kong, December 8-9, 2014 (SAVE THE DATE)

On Tue, 28 Oct 2014 01:07:40 -0700 Paul Vixie wrote: > This two day workshop will focus on the DNS root service architecture > issues raised by two current Internet Drafts: > > 1. http://tools.ietf.org/html/draft-wkumari-dnsop-root-loopback-00 >Decreasing Access Time to Root Servers by Runni

Re: [DNSOP] Using PTRs for security validation is stupid

On Tue, 11 Nov 2014 17:48:25 -1000 Lee Howard wrote: > Many SSH servers (by default) reject connections from IP addresses > without PTRs. This is stupid. Which ones? OpenSSH does not. It has a 'UseSSH' option that is often enabled by default, but all this does is log a message if the PTR name

[DNSOP] Feedback: draft-eastlake-dnsext-cookies

I remember a much older version of this mechanism, but I imagine many are not. It isn't until quite a bit into the document where the reader is really given any idea about what DNS cookies are or how they work. This might be annoying to the reader, because especially in section two that describes

Re: [DNSOP] Nudging some reviews

On Tue, 16 Dec 2014 02:25:57 +0530 Mukund Sivaraman wrote: > As part of the DNS fragments drafting, I went through > draft-eastlake-dnsext-cookies-05 yesterday, and want to send some > comments. But it seems the above is a newer version of it, so I'll > read it tomorrow and send the review. It i

Re: [DNSOP] OpenSSH 6.8 will default UseDNS to "no"

On Fri, 20 Feb 2015 14:12:50 -0500 Daniel Kahn Gillmor wrote: > If there are other instances of popular software that does > unreasonable or unsafe things with the DNS by default, I think it is worth noting, again, all OpenSSH does when UseDNS is enabled is a log a message when it detects a conn

Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

On Wed, 18 Mar 2015 01:59:56 -0700 Paul Vixie wrote: > >This document therefore updates the core DNS protocol > > specifications such that support for TCP is henceforth a REQUIRED > > part of a full DNS protocol implementation. > this language is too strong, and breaks working configurations

[DNSOP] Re: DNS traceroute - in-person discussion after dnsop WG on Thursday (today)

On Thu, 7 Nov 2024 17:42:04 + Petr Špaček wrote: > This is a very high-level description of the problem space. Let's > discuss! Preferably in person for initial high bandwidth discussion > and then we can continue on the mailing list once the initial round > of arguing is finished. A very l

[DNSOP] Re: Clarifications to the DNS Ranking Data

On Wed, 5 Mar 2025 20:51:28 -0500 Edward Lewis wrote: > I don’t have first hand involvement, but I believe there are still > name servers that respond authoritatively for some zones and act as > recursive servers for other zones. It is difficult to know the population of dual role servers withou