Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

>On the other hand, if it issued annoying warning messages every time it >used a SHA1 key, I'd eventually notice and probably rotate the keys. > >I'm with Peter, I do not see a MUST NOT as requiring vendors or operators >to do stupid stuff. For my understanding, do you mean to say that if we

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

In your letter dated Thu, 2 May 2024 10:27:17 +0200 you wrote: >I'm not following what breaks based on the wording I suggested, and I'm not su >re why you keep bringing that up. :-) Let's say I sign my zones using some scripts and ldns-signzone. This has been working for years so is now on

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

In your letter dated Thu, 2 May 2024 09:58:43 +0200 you wrote: >Right. Their policy may be "it's compliant and it works, so why roll?". It'll >be easier to push those SHA-1 signers to switch if one can tell them "look, no >w you're not compliant anymore". So basically we need a BCP: operators of

Re: [DNSOP] Questions before adopting must-not-sha1

> e.g. as other OS vendors follow suit and SHA-1 support > disappears from crypto libraries. As described by Mark Andrews, one thing that made the Redhat situation more complex is that they didn't just remove SHA1 signing support, they modified openssl to return bogus RSA valdation results at

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

In your letter dated Thu, 2 May 2024 09:21:29 +0200 you wrote: >In my view, it's fine to disallow signing with SHA-1-based algorithms to help >push signers towards other algorithms. I appreciate the effort, but I'm curious what that means. As far as I know, just about all zones that start

Re: [DNSOP] Questions before adopting must-not-sha1

>Their zone is already made insecure by a number of OS/DNS implementation >combos. Perhaps someone with RIPE Atlas credits can run a check like the >equivalent of "dig dnskey nic.kpn +dnssec" to see how many endusers >already get insecure answers for this? This reads as Redhat strong-arming the

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

>- FIPS >- PCI-DSS >- BSI >- OWASP >- SOC2 >- PKI-industry & CAB/Forum >- TLS, IPsec/IKE, OpenPGP, SMIME, et all at IETF. >- All the cryptographers including CFRG The problem is that none if them did an impact analysis for this draft. Yes of course, in isolation it is good to move away from

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

>It will also prevent ServFails when the system crypto SHA1 for >authentication and signature purposes is blocked, and the DNS software >sees this as a failure and returns BOGUS. I am not sure how many DNS >implementations are now probing SHA1 and on failure put it in the >"unsupported algorithm"

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

>The advise is split between producing SHA1 signatures and consuming SHA1 >signatures, and those timings do not have to be identical. > >That said, a number of OSes have already forced the issue by failing >SHA1 as cryptographic operation (RHEL, CentOS, Fedora, maybe more). So >right now, if you

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

>I also don't think that simple, procedural documents that are straightforwardl >y-written and uncontentious ought to present a big drain on the resources of t >he working group. I think if we all tried really hard not to nitpick or to pla >y amateur copy-editors we could probably last-call simple

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

In your letter dated Mon, 18 Mar 2024 08:01:38 +0100 you wrote: >On 2024-03-17 20:12 -07, internet-dra...@ietf.org wrote: >> Internet-Draft draft-ietf-dnsop-ns-revalidation-06.txt is now available. It >is > >| 7. Security Considerations >| [...] >| In case of non DNSSEC validating >| resolvers,

Re: [DNSOP] [Ext] About key tags

>Note that RFC 8901 is an IETF consensus document that was produced in the >DNS Operations working group. So, we can't just dismiss it and propose >protocol changes without considering effects on that (and other documents). >As I also noted earlier, its status will likely be upgraded when we

Re: [DNSOP] [Ext] Nothing more useful to say About key tags

>Not at all. This would be an incompatible change that breaks existing >working DNS configurations, for at most a trivial simplification in >load limiting code many years from now, even assuming people were to >implement it. Opinions difference how much this change will help. The point I wanted

Re: [DNSOP] [Ext] About key tags

In your letter dated Sat, 2 Mar 2024 16:55:59 -0400 you wrote: >The core DNSSEC protocol includes multi-signer. RFC 8901 just spells out expli >citly how it is covered by the protocol; that's why its status is Informationa >l. > >> The first step to conclude is that for the core DNSSEC protocol,

Re: [DNSOP] [Ext] About key tags

In your letter dated Fri, 1 Mar 2024 15:42:49 -0500 you wrote: >Offlist because I don=E2=80=99t want to feed the flames, but: > >>=20 >> 2) Operators of validators don't want customer facing errors due resource >> limit constraits. So they set them generous enough that it works for >> real

Re: [DNSOP] [Ext] About key tags

> If a validator chooses to discard all signatures for which there > are multiple DNSKEY resource records matching the key tab in the > RRSIG resource record, there'll be SERVFAILs across the population > that cares about the data involved. From past observations, when > there's a widespread "I

Re: [DNSOP] [Ext] About key tags

> For about the hundredth time, the woy you deal with any of this is > resource limits, not trying to invent new rules about stuff we > might have forbidden if we'd thought of it 20 years ago. There are a number of problems with resource limits: 1) We haven't written it down (in an RFC). So we

Re: [DNSOP] [Ext] About key tags

>Remember that the keytags are just a hint to limit the number of keys >you need to check for each signature. If I have a zone with 300 >signatures per key, it's still going to take a while to check them all >even with no duplicate tags. It won't be as bad as the quadratic >keytrap but it'll still

Re: [DNSOP] [Ext] About key tags

> I removed a lot of logic, as it seems dead on. But... > > >This would allow validators to reject any DS or DNSKEY RR set that has a > >duplicate key tag. > > "This" refers to barring keys from having duplicate key tags. My > knee-jerk response is that validators are already permitted

Re: [DNSOP] [Ext] About key tags

> So really what you're suggesting is that we change the keytag > algorithm to something that has a lower chance of collisions. > > It's a shame that the design of keytags didn't anticipate a need > for algorithm agility. Even if key tags would have been MD5 it would have been enough for

Re: [DNSOP] [Ext] About key tags

>First, forbidding key tag collisions is not controversial, the >trouble is that forbidding them is not feasible and, more >importantly, does not prevent them from happening. Validators >still need to guard themselves. Forbidding is what I'm objecting >to - discouraging them,

Re: [DNSOP] [Ext] About key tags

>The full key is not there. There is only a key tag. Are you proposing a wire f >ormat change to DNSSEC that puts the full key there? That would be hard and sl >ow to deploy and use up value bytes of the limited +/- 1400 bytes. > >> Wouldn't that limit the risk of collision? > >At a price, yes.

Re: [DNSOP] [Ext] About key tags

> Hmmm, key tags were intended to simplify computation, somehow it > seems that they've gone the other way. It seems that key tags set a trap for signers. A signer needs a way to identify keys to do key management. This mechanism needs to be robust such that the signer cannot get confused about

Re: [DNSOP] Encourage by the operator ... Re: [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

> One of the misconceptions in DNSSEC is that the zone administrator > is in control of the situation, dictating the state of signing, > the cryptography in use, and so on. DNSSEC is for the benefit of > the querier, not the responder. A zone administrator can't force > a querier to validate the

Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

>Agreed, I don't think that the protocol should prescribe what >to do in case of "operational error". Differentiating an >"operational error" from an actual malicious interference is >very likely going to be a slippery slope. That being said, I >think it will be useful for

Re: [DNSOP] DELEG and parent only resolution

In your letter dated Thu, 01 Feb 2024 10:17:33 +0100 (CET) you wrote: >Stupid question time: > >> The target of a DELEG alias cannot be stored in the child >> zone. It would not resolve if you do. > >Doesn't this mean that we can never get to an environment where >there only exists DELEG records

Re: [DNSOP] Documenting DELEG design trade-offs

>When DNSSEC came out, I admit I was kind of surprised to see how long >it took to be used. I thought it would be adopted faster. There was >insufficient motivation when the system worked well enough and the >problem being addressed was, to many people, largely theoretical. > >When DoH was

[DNSOP] Documenting DELEG design trade-offs

Something I wonder about, certainly after the interim, is how do we discuess with the wider DNS community the trade-offs that are available in de design of DELEG such that we get good feedback about priorities. For example, the current design used two contraints: 1) no creative (ab)use of DS

Re: [DNSOP] DELEG and parent only resolution

>Let me just point out a key distinction: the typical use case >of DELEG should be kind-of child centric. Most people will only use a simple alias-mode DELEG at the parent, pointing somewhere >into their DNS hoster's namespace. That's practically important, >because all the

Re: [DNSOP] New Version Notification for draft-homburg-dnsop-igadp-00.txt

>An important thing we really should define is safeguards for loop prevention (eg, an EDNS0 hop-count limit or something like >rfc8586 which defines CDN-Loop). Doing this without Loop Prevention >is dangerous, at least based on experience with similar patterns >in the CDN world.

[DNSOP] New Version Notification for draft-homburg-dnsop-igadp-00.txt

Based on some feedback we received, I created a draft that describes what to do if you want to build a proxy that acts as an authoritative server in an anycast setup. The draft just describes the basics, if there is interest we can add the details. Name: draft-homburg-dnsop-igadp Revision: 00

Re: [DNSOP] [v6ops] WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01

> I agree with you that 464XLAT is a better solution and the world > should use it as much as possible. > > But for those already deployed DNS64 and can't move to 464XLAT soon > (possibly due to lack of CLAT support, e.g. in some residential > gateways), wouldn't Momoka's draft help? If Momoka

[DNSOP] DNS54 Was: Re: [v6ops] WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01

>I believe Mark is referring to a validating stub (not a full >service resolver) behind a NAT64/DNS64. If such a stub uses the >DNS64 as its upstream resolver, it will encounter a variety of >potential failures with responses that can't be validated because >the DNS64 passed

Re: [DNSOP] [v6ops] WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01

> Hi all, The goal to > improve DNSSEC adoption is good. The goal to improve IPv6 adoptions > is good too. It looks like here goals contradict (for technical > reasons). But if you would pay attention that DNS64 is already > massively adopted by *ALL* carriers, Then the harm for DNSSEC is >

Re: [DNSOP] I-D Action: draft-homburg-dnsop-codcp-00.txt

In your letter dated 13 Jan 2023 12:02:18 -0500 you wrote: >This isn't exactly the same thing, but over in e-mail land we see lots of >small sysems with silly configurations that are so locked down that they >don't work. Someone said they are "more secure." Same idea. Well, it >works for me,

Re: [DNSOP] I-D Action: draft-homburg-dnsop-codcp-00.txt

In your letter dated 12 Jan 2023 17:25:25 -0500 you wrote: >> Who benefits from a fake implementation? > >Some application demands, I dunno, DoQUIC or something, and refuses to run >otherwise. So I install a resolver library that makes the complaints go >away. I don't understand. An

Re: [DNSOP] I-D Action: draft-homburg-dnsop-codcp-00.txt

>It occurs to me that it introduces knobs that might not work, since the >easiest way to implement it is to accept the EDNS0 options, ignore them, >and do whatever you were doing anyway. (This isn't a new issue; see RFC >8689, the SMTP require TLS option, which I've implemented the same way.)

Re: [DNSOP] I-D Action: draft-homburg-dnsop-codcp-00.txt

> Or DNSSEC is is use. Fortunately, DNSSEC has the CD flag. I believe that at least one NTP client retries with the CD flag is DNS resolution fails. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-homburg-dnsop-codcp-00.txt

In your letter dated Tue, 10 Jan 2023 11:33:57 -0500 (EST) you wrote: >>However, such a setup leaves the application with no control over >>which transport the proxy uses. > >Why should the application have control over this? The following is just a thought, I didn't implement it. With

Re: [DNSOP] I-D Action: draft-homburg-dnsop-codcp-00.txt

In your letter dated Tue, 10 Jan 2023 17:27:12 -0500 (EST) you wrote: >if applications think it is THAT important, they shouldn't be trusting >the EDNS options of a stub proxy, which also might go through an OS >proxy on top. It also cannot trust or know whether the proxy's upstream >forwardering

Re: [DNSOP] I-D Action: draft-homburg-dnsop-codcp-00.txt

In your letter dated 10 Jan 2023 16:25:14 -0500 you wrote: >I'm with Paul here. If you don't like the way my resolver works, use >another one. > >Experience also tells us that if you give users knobs like this, they >will use them even when (especially when) they have no idea what they >are doing.

Re: [DNSOP] I-D Action: draft-homburg-dnsop-codcp-00.txt

In your letter dated Tue, 10 Jan 2023 11:33:57 -0500 (EST) you wrote: >Why should the application have control over this? If you want to give >control to the application, what should they control? What if two >applications disagree? What if they look up the same thing, but the >first application

[DNSOP] I-D Action: draft-homburg-dnsop-codcp-00.txt

--- Forwarded Message Subject: I-D Action: draft-homburg-dnsop-codcp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Control Options For DNS Client Proxies Author : Philip Homburg Filename

Re: [DNSOP] draft-homburg-add-codcp potential new work for WG?

>That aim doesn't seem consistent with the statement that the >proxy won't be trusted with DNSSEC validation. That way you >still need a rather complex DNS code, ideally in a library. >And you'll need to query to stub for extra records to form the >whole chain, so that you

Re: [DNSOP] draft-homburg-add-codcp potential new work for WG?

>OK. I suppose I'm stuck in the model of (at least) machine-wide >policies, thinking that it would be really messy if each app >chooses properties of their DNS separately. (Which sounds more >like a job for a library API anyway.) The goal is to move the implementation of the

Re: [DNSOP] draft-homburg-add-codcp potential new work for WG?

> The DNSOP WG chairs welcome feedback on the draft > draft-homburg-add-codcp, Control Options For DNS Client Proxies > ([1]https://datatracker.ietf.org/doc/draft-homburg-add-codcp/). > >I find it a bit weird for a client to *choose* how the proxy/resolver >might connect to

Re: [DNSOP] New Version Notification for draft-rebs-dnsop-svcb-dane-00.txt

>> There is something I don't understand about this draft. > >The main thing to understand is that complex applications like browsers >allow data retrieved from one endpoint to script interaction with a >*different* endpoint, and possibly see the retrieved content, subject to >various CORS

Re: [DNSOP] New Version Notification for draft-rebs-dnsop-svcb-dane-00.txt

> 1. While DANE certificate validation as described in RFCs 7671,7672 > and 7673 > is fine in SMTP, IMAP, XMPP, ... for HTTP (and perhaps some > other applications) skipping validation of the target name with > DANE-EE(3) records introduces a "UKS" (i.e. "Unknown Key Share") >

Re: [DNSOP] How Slack didn't turn on DNSSEC

> Also stop hiding this > breakage. Knot and unbound ignore the NSEC records which trigger > this when synthesising. All it does is push the problem down the > road and makes it harder for others to do proper synthesis based > on the records returned. I did some tests with unbound (version

Re: [DNSOP] How Slack didn't turn on DNSSEC

> Also stop hiding this > breakage. Knot and unbound ignore the NSEC records which trigger > this when synthesising. All it does is push the problem down the > road and makes it harder for others to do proper synthesis based > on the records returned. I'm confused what this means. In the report

Re: [DNSOP] How Slack didn't turn on DNSSEC

>It is clear from the blog post that this is a fairly sophisticated >group of ops people, who had a reasonable test plan, a bunch of test >points set up in dnsviz and so forth. Neither of these bugs seem >very exotic, and could have been caught by routine tests. It not clear to whether or not

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

> The root zone and private-use internal zones that anchor private > namespaces might all benefit from a robust trust anchor distribution > strategy. If validators have the ability to be configured elegantly > with all the trust anchors they need without the attention of a > knowledgeable

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

>But that problem is independent of the domain names used. If the CPE >sends queries to the ISP, the deed has already been done, regardless of >what the ISP does with the query (send it to the root, to telus.com or >drops it) Sending a query to the root, which is considered a collection of

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

> basically all the domains you list here could have used one of > their own domains (eg local.telus.com instead of .telus, etc) I wonder how that would interact with EU privacy regulations. In the common case of an ISP providing the customer with a CPE, the ISP is resposible for anything that

Re: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-01.txt

>Philip Homburg pointed out that, although impractical to determine the >Client IP before Client Cookie construction, it is feasible for a Client >to detect it when it learns a Server Cookie from a specific Server. It >can subsequently be tried to be reused for the same Server whic

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

I wrote: >In Section 4.4, the client IP is added to the hash in the creation of the >server cookie. Ah, never mind, that is already in RFC 7873. So a client that wants to (re-)use a server cookie needs to know the source address it previously used to communicate with the server. So if the client

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

>When implementing DNS Cookies, several DNS vendors found that >impractical as the Client Cookie is typically computed before the Client >IP address is known. Therefore, the requirement to put Client IP address >as input to was removed, In Section 4.4, the client IP is added to the hash in the

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

>This is true. Including the Client IP in constructing the Client Cookie >was intended to deal with this, but this operation is impractical with >UDP; expensive at best and not suitable for high volume recursive to >authoritative traffic. > >We could recommend it for stub to recursive traffic,

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

In your letter dated Mon, 9 Sep 2019 14:13:01 +0200 you wrote: >When implementing DNS Cookies, several DNS vendors found that >impractical as the Client Cookie is typically computed before the Client >IP address is known. Therefore, the requirement to put Client IP address >as input to was

Re: [DNSOP] Proposal: Whois over DNS

> The technical issue with > whois is that its dark in many places and getting darker with > minimal to no prospect of coming back (in a usable form). > > While GDPR applies only to EU natural persons because there is no > way to distinguish between natural persons and legal persons and > no way

Re: [DNSOP] Proposal: Whois over DNS

> > As far as I know, there is no issue with whois and the GDRP when it comes > > to voluntarily publishing information in whois. > > Nope. Its OK for you to publish your Personal Data. For anything > else, you need to get informed consent first. And be able to prove > that. And give the Data

Re: [DNSOP] Proposal: Whois over DNS

> Im not sure the point > aside of illustrating if there is no response for the domain records > by the auth server that there would also be no response for a _whois > record. Thats true. > > 1) Using _whois is completely optional, like SPF or any other > record. 2) I cant envision much

Re: [DNSOP] [v6ops] New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

In your letter dated Wed, 26 Sep 2018 12:58:30 +1000 you wrote: >I have said before, but don't know if I still adhere to it, but >anyways, here's a question: How *long* do people think a biassing >mechanism like HE is a good idea? > >I used to love HE. I now have a sense, I'm more neutral. Maybe,

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

> > Well, if the OS resolver is validating, it will SERVFAIL with such a > > query. > > The protocol requires special handling of those specific queries, > so a resolver that understands the protocol will give the desired > answer. A resolver that doesn't understand the answer will give >

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

In your letter dated Tue, 21 Aug 2018 18:19:39 +0200 you wrote: >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 There are still plenty of use cases. An

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

>In fact, roaming wi-fi >connections, while still relevant (especially for international tourists), are > getting less and less used, since everyone now gets several gigabytes of EU-w >ide mobile data per month included with their base mobile fee. I assume that you are aware that with HD video,

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

>Then you have a problem that's not solvable in DNS itself (yet).  That's >what people usually forget to consider. > >The hostnames are clear-text in https hanshakes (so far), and it seems >relatively easy to collect those.  So, by tunneling *only* DNS you don't >make it much more difficult for

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

> 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 reason to trust an ISP. If you take a mobile device,

Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest

In your letter dated Tue, 31 Jul 2018 06:49:04 -0700 you wrote: >> I think there is a big difference between distributing the root zone and >> distributing a few 'local' zones. >> >> In the first case you need something that is massively scalable. > >I'm afraid I don't see those as different

Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest

> Are you suggesting that web servers can't be massively scaleable > ? > I'm not sure I understand your examples. Yes, you can build massively scaleable web servers, but at what price? What if some popular IoT device starts to fetch the root zone. And at a high rate? > You cite

Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest

> > The draft states in the Motivation section: > > > > "The motivation and design of this protocol enhancement is tied to the > DNS root zone [InterNIC]." > > That may be a motivation, but as a prospective user I want to use > it for much more. My LocalRoot server is already going to be >

Re: [DNSOP] [Driu] [Doh] Resolverless DNS Side Meeting in Montreal

>The ip= modifier would be a great way to arrange for something to look like >it came from a different source than its actual source. I'm sure there's >an attack surface in there somewhere. That's a rather fundamental issue. In the context of TLS, and a DNSSEC insecure zone, there are two

Re: [DNSOP] Resolverless DNS Side Meeting in Montreal

>For example www.example.com pushes you a record for img1.example.com. >Should you use it? What if it is for img1.img-example.com ? Do the >relationship between these domains matter? What kind of relationship (i.e. >it could be a domain relationship, or in the context of a browser it might

Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa

> I think deprecating > RFC7050 will be a bad idea, there are too many implementations that > really need that, while updating APIs/libraries to make sure they > comply with this seems easier. > > For example, we could have a DHCPv6 option, but in the cellular > world DHCPv6 is not used ... and

Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa

In your letter dated Fri, 6 Jul 2018 18:50:44 +1000 you wrote: >All it does is ensure that the DNS queries get to the DNS64 server. The way RFC 7050 works that you send queries to your local recursive resolver. The problem there is that if the user manually configured a public recursive resolver

Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa

> Most of the special > handling could be avoided if IANA was instructed to run the servers > for ipv4only.arpa on dedicated addresses. Hosts routes could then > be installed for those address that redirect traffic for ipv4only.arpa > to the ISPs DNS64/ipv4only.arpa server. > > Perhaps 2 address

Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa

>draft-cheshire-sudn-ipv4only-dot-arpa document Section 7.1: "Name resolution APIs and libraries MUST recognize 'ipv4only.arpa' as "special and MUST give it special treatment. It seems to me that it is going way to far to require all DNS software to implement support for a hack that abuses DNS

Re: [DNSOP] DoH interaction, sortlist Re: BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)

>At that lunch, we could not figure out who originally required such a >detailed ordering configuration in BIND, and it might be interesting to find >out. What I remember from a very long time ago is the following network setup: - a collection of NFS servers each with multiple ethernet interface

Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa's delegation should be insecure.

>https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa > >From Section 6.2: 3. Name resolution APIs and libraries MUST recognize 'ipv4only.arpa' as special and MUST give it special treatment. Regardless of

Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors

>Are there cases of "corrupted" registries make the threat of "stolen zones" a >real thing? I think the most well known example is the US government taking the .org domain of Rojadirecta. https://torrentfreak.com/u-s-returns-seized-domains-to-streaming-links-site-after-18-months-120830/ There

Re: [DNSOP] Resolver behaviour with multiple trust anchors

>It sounds like clarification is needed if even one (much less three) >systems treat such a signature as Bogus. My reading of RFC 4035 is that >any chain that successfully leads to a trust anchor should return >Secure, even if a different chain returns Bogus. If extra trust anchors are

Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt

>>we will never know, because every v6 end system will have a ptr, either >>naturally, or machine-generated for it, because v6 providers will not >>want their rank-and-file v6 endsystems to be excluded from important >>activities such as transmitting e-mail. > >If =B3v6 provider=B2 includes

Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt

In your letter dated Tue, 02 May 2017 15:03:15 -0400 you wrote: >I agree that people reject mail if there=B9s no PTR; I think this is used in >fighting spam, based on an inference that if there=B9s no PTR, you=B9re a s= >pam >bot rather than a legitimate mail server. >The first case listed in 4.

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

In your letter dated Tue, 28 Mar 2017 19:23:16 +0200 you wrote: >On 28 Mar 2017, at 12:37, Philip Homburg wrote: > >> So if would be best if a validator that implements MD5 would still >> return >> NXDOMAIN is validation fails, but would keep the AD-bit clear even if

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

In your letter dated Tue, 28 Mar 2017 11:01:01 +0100 you wrote: >Evan Hunt wrote: >> >> MD5 is known to be breakable, but it's not *as* breakable that hasn't been >> signed, or a resolver that hasn't turned on validation. > >It features Postscript, PDF/JPEG, and GIF MD5 quines

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

> This .home / .homenet issue has already been going on for a very > long time. The longer we wait with resolving this issue, the worse > the deployment situation will be of software mixing .home vs > >homenet. Do we really expect homenet to be only ever used in a 'home'? It seems to me that

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

> FWIW, when adding DANE support to Postfix, it was plainly obvious > that DNSSEC validation belongs in the local resolver, and Postfix > just needs to trust its "AD" bit. The only thing missing from the > traditional libresolv API is some way for the application to specify > the resolver address

Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt

>1. I do not think there is consensus that having PTRs is or is not a best >practice, so emphasizing the lack of consensus lets us move on to what an >ISP can do, if they care to do anything. >The first paragraph has been overhauled to say "While the need for a PTR >record and for it to match >

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

>> 1) If the traver's laptop/phone uses Heathrow Airport resolvers then Heathro >w > >>4) DNS is not really private so Google may offer their DNS services over HTTP >S >> 5) Governments may force Google to block popular sites, so users switch to >>other DNS resolvers, again over HTTPS. > >See

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

>See the recent discovery that Heathrow Airport runs a >MITM TLS server on torproject.org. Do we want them to run RPZ where they >can disappear torproject.org alltogether? No. Do we want them to run RPZ >to prevent travelers from getting malware installed? Yes. Just my crystal ball: 1) If the

Re: [DNSOP] "let-localhost-be-localhost".

In your letter dated 23 Nov 2016 11:49:28 -0500 you wrote: >> What if localhost is just inserted in the root as the equivalent of >> localhost. IN A 127.0.0.1 >> localhost. IN ::1 > >Most systems I know special case a plain localhost name in the resolver or >cache. The more interesting bits

Re: [DNSOP] "let-localhost-be-localhost".

>The problem is that the DNSSEC solution here is kind of complicated. >What you'd want is an opt-out signature in the root, showing that there >might be an insecure delegation to .localhost, but the root is signed with >NSEC and there's only opt-out in NSEC3. Technically it's not complicated

Re: [DNSOP] [OT][rant-ish] Electronics & business models (was DNSSEC operational issues long term)

>For most electronics equipment (pre-IoT) once you sold it your job as a >manufacturer was basically done. You don't have to issue security >patches for the keyboard or firmware upgrades to the monitor because >the meaning of the wires in the VGA standard has changed out from under >it. > >With

Re: [DNSOP] DNSSEC operational issues long term

>Did you see my original response? Proposals for automatic DNSSEC trust >anchor updating *do* exist. Is there any document that deals with the situation where a device has been in a box for 10 years and then has to bootstrap automatically? I'm not aware of any. But maybe there is. Note that by

Re: [DNSOP] Fwd: New Version Notification for draft-dickinson-dnsop-dns-capture-format-00.txt

>We have just published a new draft on a proposed format for DNS packet >capture - please see below for details. We would very much appreciate >feedback on the overall problem discussed here in addition to the >details of the format proposed. Did you consider not (partially) decoding the DNS

Re: [DNSOP] DNS-in-JSON draft

In your letter dated Mon, 5 Sep 2016 15:47:37 +0800 you wrote: >Finally, I note that the RIPE Atlas system uses a type of DNS JSON >representation when you use their API to query for DNS measurement >results. You can get a sample here: >

Re: [DNSOP] DNS-in-JSON draft

In your letter dated Tue, 6 Sep 2016 06:26:58 + you wrote: > I was more commenting on the fact that it is escaping in a format > that already support escaping. The JSON output would be double > escaped and implementations would need to unescape it themselves > rather then let JSON handle it.

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

In your letter dated Fri, 29 Apr 2016 13:33:29 +0100 you wrote: >"needed" is rather a strong word historically reverse DNS was a de >facto requirement for access to some anonymous FTP servers (a use case >that is now rather long in the tooth) and it was seized on by mail >systems that were

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

In your letter dated Fri, 29 Apr 2016 14:26:27 +0200 you wrote: >I see two simple solutions for that. You mention one (ip6.arpa DNS >delegation), since, as you said, people who want to manage a mail >server probably can manage a DNS zone. > >There is another one, apparently not mentioned by the

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

In your letter dated Fri, 29 Apr 2016 13:54:44 +0200 you wrote: >Disclaimer: Personally I think that the whole notion of reverse IP is >ridiculous, especially in IPv6. I proposed that we skip the whole >notion in IPv6, possibly providing some alternate, non-DNS, method to >get hostname from IPv6

  1   2   >