Re: [DNSOP] NXDOMAIN and RFC 8020

>>> I think this is another point in favor of doing QNAME minimization. >>> RFC7816 (technically experimental, but recommended.) >>> >>> It kind of makes the query order moot; the resolver looks up the shorter >>> name first even while resolving the longer name. >>> >> >> Is there any data or even

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

> The DoH operators who have made public statements (google and cloudflare > are two I am aware of), have specifically indicated that NO OTHER HTTPS > TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}. I have seen such a public statement from Google. Where have you seen a similar

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

>> I think this is a mischaracterization of the debate, which actually >> started because of a third position that you don't mention: Mozilla's >> public statement that in the future they will force (or, at least, make as >> a default - clarification requests haven't solved the doubt yet) Firefox

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

> The DHCP solution is compatible only with trust relationship two. So if > the IETF were to recommend this way of configuring DoH and DoT, we would > essentially be throwing away the privacy benefits of DoH and DoT (assuming > that such benefits exist). I don't believe people are saying that

Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

> > Speaking only for myself - I have done many BIND upgrades without config > > file changes (and I basically expect this to work). > > i apologize, again, for the config file from last-bind8, not working in > all cases with first-bind9. i don't work at ISC any more, but i think i > can safely

Re: [DNSOP] Why new code/old keys? Re: [Ext] Re: sentinel and timing?

> If just to spread rumors, I heard the following as early as November, 2016. > One of the issues is that operators update code without updating > configuration files. I.e., a BIND upgraded today might be using a > configuration file from the pre-managed-key days. Speaking only for myself -

Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

> Can you provide a technical reason for per-address IPv6 reverse DNS? > > Where I work, we bulk populate reverse v4 DHCP pools just so we know that > they are pools. We aren't going to bother doing that with v6 because > everything is a pool, except for a relatively small number of statically >

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

> > adding complexity in the middle of any system increases the size of an > > attack surface. > > +1 This was described in detail several times (see for instance this > report > ) > and

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

> > No, this draft simply specifies what operators are already doing. Not > > because they are intent on destroying trust in the DNS or the Internet, > > but because they are forced to do this by governments, they need to > > protect their own network, they would like to protect their customers, >

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

Since operator participation was mentioned, > this draft actively destroys trust in the DNS, which reduces trust in the > Internet overall. No, this draft simply specifies what operators are already doing. Not because they are intent on destroying trust in the DNS or the Internet, but because

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

> To be clear and to boil it down: This draft publishes a method to supply > different answers to different users and to hide the truth of those lies to > the same users. So do for instance BIND views. > Unless a registry, court or resource owner authorizes this, it is > lying, cheating,

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

> > So if this is the IP of a phishing site or the IP of an command and > > control host that tells its bot to execute criminal action you still > > valid the accuracy of the answer higher then possible damage this > > could do to your user? > > > yes. > > In your example, ethically, it is a

Re: [DNSOP] warning

> Regarding "Message-ID header" - factually, over 80% of all spam > (I have not bothered to do the actual number check, it is probably closer > to 99.99% but I am erring on the side of caution - as this is science > and not opinion, it is what it is) > > - All contain a Message-ID header.

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-isp-ip6rdns

> > The point of this document is not to make normative requirements. > > But it does: 'Best practice is that "Every Internet-reachable host > should have a name"'. I agree. Especially with IPv6 in mind, "Every Internet-reachable host should have a name" is *not* best practice. Steinar Haug,

Re: [DNSOP] relax the requirement for PTR records?

Absolutely not (recommend ISPs should delegate). While it would be good if an ISP offered this to interested parties, don't expect to saddle the operator with yet another service that expects the customer to reply/provide out-of-band information. The point of delegating is is that in

Re: [DNSOP] Rejecting Practice for Theory

so, my hope is that we could recommend against machine-generated PTR's, and recommend in favour of PTR delegation when a customer requests it, all while understanding that ISP's will do whatever they want after they see whatever recommendations we make. I would vastly prefer to get a

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

Putting my ISP hat on, I'd have to agree with the security/stability reasons (and several others I can think of). As of today, I have zero incentive to let my residential customers create their own PTR records. Putting my customer hat on: I want PTR for my machines (many hosters allow

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

Putting my ISP hat on, I'd have to agree with the security/stability reasons (and several others I can think of). As of today, I have zero incentive to let my residential customers create their own PTR records. Better tools and systems may change this, but it would in any case be *way*

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

marka Or we could stop debating whether we should maintain it and marka assume that if we give people tools that will allow it to be marka automatically maintained they will eventually deploy them. For providers with millions or tens of millions of end customers, any system that just

Re: [DNSOP] new version of IPv6 rDNS for ISPs

One observation is that the delegation to CPE routers (home gateways) is contradictory to RFC6092: REC-8 By DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS resolving server. Not suggesting delegation to CPE

Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document

I can't agree with this statement. As others have said, the practice of using a search list to allow 'ssh foo.bar' to reach 'foo.bar.example.com' isn't going anywhere, and there are a lot of people that make extensive use of the convenience. It needs to die because it's

Re: [DNSOP] m.root-servers.net DNSSEC TCP failures

A small followup: So it looks like the IPv4 instance refuses TCP, while the IPv6 instance handles it okay. No filters in the way at my end. The m.root-servers.net instance looks like it is in Paris or thereabouts - but there is quite a bit of difference between the instances: IPv4 (highly

Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS

I can't comment on that directive in particular (if indeed such a directive with that name exists, per later mail) but in general I find it a feature that a document with operational focus addressed to the whole Internet should steer clear of regional policy requirements. Agreed.

Re: [DNSOP] A different question

it in their products or services. Peter Koch did provide an interesting data point that warrants further investigation (20-35% of queries having DO bit on seems a bit high to me) and someone else responded privately that I think Peter's data point sure warrants further investigation,