From ietf-dane at dukhovni.org Sun Jun 2 04:26:47 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 1 Jun 2019 22:26:47 -0400 Subject: Update on stats 2019-05 Message-ID: <20190602022647.GC67459@straasha.imrryr.org> Summary: The DANE domain count is now 1,149,012 The number of domains that return DNSSEC-validated replies in response to MX queries is 9,874,472. Thus DANE TLSA is deployed on 11.63% of domains with DNSSEC. Credits: The coverage of DNSSEC domains continues to improve with ongoing data support from Paul Vixie of Farsight Security. Credits also due to ICANN for gTLD data via CZDS, and to the TLD registries for .CH, .COM, .DK, .FR, .INFO, .IS, .LI, .NL, .NU, .ORG and .SE. More data sources of ccTLD signed delegations welcome. Appeal: The handful of providers with long-term broken DNSSEC denial of existence are sadly making little progress to update their buggy DNS implementations. It would be really great if (at least): mijnhostingpartner.nl (Many broken NSEC3 RRSIGs) epik.com (Wildcards missing from NSEC chain) metaregistrar.nl (Wrong empty non-terminal handling) tiscomhosting.nl (Missing wildcard NSEC for NODATA response) dotserv.com (invalid NSEC chain order) movenext.nl (NSEC replies don't cover wildcard) nrdns.nl (Malformed NSEC3 or ServFail) binero.se (NSEC3 chain names returned as NSEC!) fixed their nameserver and/or zone provisioning code. While the O(10^3) affected domains are a small fraction of the O(10^7) signed domains, they are a much larger fraction of the signed domains for those particular providers. Appeal: The number of domains with neglected outdated TLSA records, has grown to ~500. PLEASE *monitor* your deployment, and implement a cert/key rollover process that does not (even temporarily) disrupt the validity of your certificate chain as compared to the published (cached) TLSA records: https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources If you're willing and able to help reach out to the operators of MX hosts with misconfigured TLSA RRsets, please get in touch. As of today I count 1,149,012 domains with correct SMTP DANE TLSA records at every primary MX host that accepts connections[1]. As expected, the bulk of the DANE domains are hosted by the DNS/email hosting providers who've enabled DANE support for the customer domains they host. The top 20 MX host providers by domain count are: 705488 one.com 125798 transip.nl 97267 domeneshop.no 36238 active24.com 32475 vevida.com 24131 udmedia.de 15856 flexfilter.nl 12993 onebit.cz 12327 zxcs.nl 10961 bhosted.nl 5999 netzone.ch 5644 previder.nl 3795 ips.nl 3401 interconnect.nl 2481 provalue.nl 2287 nederhost.nl 1628 nmugroup.com 1574 yourdomainprovider.net 1320 hi7.de 1293 prolocation.net The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.cz/.de/.eu/.be. Speaking of countries, the IPv4 GeoIP distribution of DANE-enabled MX hosts shows the below top 20 countries (each unique IP address is counted, so multi-homed MX hosts are perhaps somewhat over-represented). 5221 TOTAL 1758 DE, Germany 1065 US, United States 718 NL, Netherlands 383 FR, France 216 GB, United Kingdom 175 CZ, Czechia 116 CA, Canada 88 SG, Singapore 75 CH, Switzerland 71 SE, Sweden 54 DK, Denmark 43 IE, Ireland 43 AT, Austria 41 FI, Finland 36 AU, Australia 34 PL, Poland 34 BR, Brazil 26 RU, Russia 26 JP, Japan 23 IN, India IPv6 is still comparatively rare for MX hosts, and the top 20 countries by DANE MX host IPv6 GeoIP are: 1914 TOTAL 732 DE, Germany 304 NL, Netherlands 238 FR, France 155 US, United States 114 CZ, Czechia 74 GB, United Kingdom 39 SE, Sweden 33 CH, Switzerland 28 RU, Russia 28 CA, Canada 22 AT, Austria 18 IE, Ireland 14 NO, Norway 13 DK, Denmark 12 FI, Finland 10 AU, Australia 9 SI, Slovenia 9 IN, India 7 IT, Italy 6 SK, Slovakia There are 4392 unique zones in which the underlying MX hosts are found, this counts each of the above providers as just one zone, so is a measure of the breadth of adoption in terms of servers deployed. The number of published MX host TLSA RRsets found is 6639. These cover 7077 distinct MX hosts (some MX hosts share the same TLSA records through CNAMEs). The number of domains that at some point were listed in Gmail's email transparency report is 245 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 129 are in recent (last 90 days of) reports: univie.ac.at ruhr-uni-bochum.de mailplus.nl gmx.at tu-darmstadt.de markteffectmail.nl transip.be tum.de minbzk.nl nic.br uni-erlangen.de ouderportaal.nl registro.br uni-muenchen.de overheid.nl gmx.ch unitybox.de pathe.nl open.ch unitymedia.de photofacts.nl anubisnetworks.com web.de photofactsacademy.nl fmc-na.com egmontpublishing.dk politie.nl gmx.com netic.dk previder.nl habr.com sitnet.dk rijksoverheid.nl hotelsinduitsland.com tilburguniversity.edu rotterdam.nl kpn.com zone.eu rvo.nl mail.com dovecot.fi ssonet.nl one.com ac-strasbourg.fr transip.nl solvinity.com insee.fr truetickets.nl t-2.com octopuce.fr utwente.nl telfort.com web200.hu uvt.nl trashmail.com comcast.net xs4all.nl xfinity.com dd24.net domeneshop.no xfinityhomesecurity.com dns-oarc.net handelsbanken.no xfinitymobile.com gmx.net uib.no active24.cz habramail.net webcruitermail.no atlas.cz hr-manager.net atelkamera.nu centrum.cz inexio.net aegee.org cuni.cz mpssec.net debian.org klubpevnehozdravi.cz procurios.net freebsd.org onebit.cz riseup.net gentoo.org smtp.cz t-2.net ietf.org virusfree.cz transip.net isc.org volny.cz transversal.net netbsd.org allsecur.de vevida.net openssl.org bayern.de xs4all.net ozlabs.org bund.de bhosted.nl samba.org elster.de bluerail.nl torproject.org fau.de boekwinkeltjes.nl asf.com.pt freenet.de corpoflow.nl deborla.pt gmx.de denhaag.nl moikrug.ru jpberlin.de dictu.nl handelsbanken.se lrz.de digid.nl minmyndighetspost.se mail.de hierinloggen.nl personligalmanacka.se mensa.de hr.nl skatteverket.se posteo.de intermax.nl govtrack.us Of the ~1.15 million domains, 2514 have "partial" TLSA records, that cover only a subset of the (secondary) MX hosts. While this protects traffic to some of the MX hosts, such domains are still vulnerable to the usual active attacks via the remaining MX hosts. The number of domains with incorrect TLSA records or failure to advertise STARTTLS (even though TLSA records are published) stands today at 560. Some of these have additional MX hosts that don't have broken TLSA records, so mail can still arrive via the remaining MX hosts. A partial list is available at: https://github.com/danefail/list To avoid getting listed, please make sure to monitor the validity of your own TLSA records, and implement a reliable key rotation procedure. See: https://dane.sys4.de/common_mistakes https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 After eliminating parked domains that do not accept email, the number of "real" email domains with bad DNSSEC support stands at 1318. The top 10 name server operators with problem domains are: 537 mijnhostingpartner.nl 109 epik.com 40 metaregistrar.nl 34 tiscomhosting.nl 34 dotserv.com 33 movenext.nl 31 nrdns.nl 30 binero.se 29 domaincontrol.com 27 sylconia.net [ Sadly epik.com is back, after resolving all issues last month, it seems while the reported domains were resolved, the underlying systemic issue was not. ] If anyone has good contacts at some of these providers, please encourage them to remediate not only the broken domains (I can send them a list), but also the root cause that makes the breakage possible. Eleven of the domains all whose nameservers have broken denial of existence appear in the last 120 days of Google transparency reports: coren-sp.gov.br trt01.gov.br trtrio.gov.br trt1.jus.br trtrj.jus.br key.com keybank.com bluehosting.host rackeo.host sauditelecom.com.sa -- Viktor. [1] Some domains deliberately include MX hosts that are always down, presumably as a hurdle to botnet SMTP code that gives up where real MTAs might persist. I am not a fan of this type of defence (it can also impose undue latency on legitimate email). However, provided the dead hosts still have TLSA records, (which don't need to match anything, just need to exist and be well-formed) there's no loss of security. From rob0 at nodns4.us Sat Jun 15 19:11:29 2019 From: rob0 at nodns4.us (Rob McGee) Date: Sat, 15 Jun 2019 12:11:29 -0500 Subject: DANE plus wildcard record Message-ID: <0e71195634e2181d37e4a994ecd21ef4@nodns4.us> Hi all, first post here. Hi Viktor and the sys4.de gang. I host a mailing list for a free software project with DANE enabled both ways. No need for secrecy there, it's Slackbuilds.org. One of my subscribers recently signed his or her zone, and sadly, has a wildcard A in that zone. Unfortunately at this point I do have to keep that zone name private, although offlist I'd tell it to someone I know and consider trustworthy to maintain the user's confidence. Oh, if you consult your dane.sys4.de logs for a bit ago, I suppose I already DID tell you the zone name. :) Starts with "a" and is in com. TLD. The checker reports "DNS lookup error for TLSA records: SERVFAIL", which is what I get on the named recursive resolver that Postfix is using, querying "_25._tcp.smtp.example.com./IN/TLSA". So Postfix is refusing to deliver, believing that there should be a TLSA. But AFAIK this user never published TLSA. The SOA MNAME host has disabled version.bind./CH/TXT lookups so I am not sure what software is in use, but having A for an invalid hostname (underscores not allowed in hostnames) would be a problem for BIND named, which by default would not allow that. But I don't know how that feature interacts with wildcard records. Testing on a dnsmasq from home I don't get SERVFAIL, just NOERROR. -- http://rob0.nodns4.us/ From rob0 at nodns4.us Sat Jun 15 20:48:27 2019 From: rob0 at nodns4.us (Rob McGee) Date: Sat, 15 Jun 2019 13:48:27 -0500 Subject: DANE plus wildcard record In-Reply-To: <0e71195634e2181d37e4a994ecd21ef4@nodns4.us> References: <0e71195634e2181d37e4a994ecd21ef4@nodns4.us> Message-ID: <3a674f6484570165e3d6efd1a5e006c4@nodns4.us> On 2019-06-15 12:11, I wrote: > One of my subscribers recently signed his or her zone, and sadly, has a > wildcard A in that zone. Unfortunately at this point I do have to keep > that zone name private, although offlist I'd tell it to someone I know > and consider trustworthy to maintain the user's confidence. The immediate problem has been solved with a bandaid, smtp_tls_policy_maps, with an entry: example.com may This overrides the global "smtp_tls_security_level = dane" setting, and I've confirmed that I can send mail to the subscriber now. > Oh, if you consult your dane.sys4.de logs for a bit ago, I suppose I > already DID tell you the zone name. :) Starts with "a" and is in com. > TLD. The checker reports "DNS lookup error for TLSA records: > SERVFAIL", > which is what I get on the named recursive resolver that Postfix is > using, querying "_25._tcp.smtp.example.com./IN/TLSA". > > So Postfix is refusing to deliver, believing that there should be a > TLSA. But AFAIK this user never published TLSA. > > The SOA MNAME host has disabled version.bind./CH/TXT lookups so I am > not sure what software is in use, but having A for an invalid hostname > (underscores not allowed in hostnames) would be a problem for BIND > named, which by default would not allow that. But I don't know how > that feature interacts with wildcard records. > > Testing on a dnsmasq from home I don't get SERVFAIL, just NOERROR. I still think this is an interesting problem, perhaps a BIND problem. The user didn't set a TLSA and might have had no idea about DANE ("isn't that what Hamlet was?") and yet was unable to get mail from my DANE- enabled host. -- http://rob0.nodns4.us/ From rob0 at nodns4.us Sat Jun 15 21:41:15 2019 From: rob0 at nodns4.us (Rob McGee) Date: Sat, 15 Jun 2019 14:41:15 -0500 Subject: DANE plus wildcard record In-Reply-To: <3a674f6484570165e3d6efd1a5e006c4@nodns4.us> References: <0e71195634e2181d37e4a994ecd21ef4@nodns4.us> <3a674f6484570165e3d6efd1a5e006c4@nodns4.us> Message-ID: On 2019-06-15 13:48, I wrote: > On 2019-06-15 12:11, I wrote: >> Testing on a dnsmasq from home I don't get SERVFAIL, just NOERROR. > > I still think this is an interesting problem, perhaps a BIND problem. > The user didn't set a TLSA and might have had no idea about DANE > ("isn't > that what Hamlet was?") and yet was unable to get mail from my DANE- > enabled host. Logs (from named) of the SERVFAIL: 15-Jun-2019 18:49:00.419 lame-servers: info: no valid RRSIG resolving 'smtp.example.com/DS/IN': 176.56.237.121#53 15-Jun-2019 18:49:00.468 lame-servers: info: no valid RRSIG resolving 'smtp.example.com/DS/IN': 45.119.209.45#53 15-Jun-2019 18:49:00.468 lame-servers: info: no valid DS resolving '_25._tcp.smtp.example.com/TLSA/IN': 45.119.209.45#53 15-Jun-2019 18:49:00.567 dnssec: info: validating _25._tcp.smtp.example.com/TLSA: bad cache hit (smtp.example.com/DS) 15-Jun-2019 18:49:00.567 lame-servers: info: broken trust chain resolving '_25._tcp.smtp.example.com/TLSA/IN': 176.56.237.121#53 This was after "rndc flushtree example.com", so I am still not sure what the error means. Hmm, why is it wanting DS for smtp.example.com? That's not a zone, it is only an A record in example.com. -- http://rob0.nodns4.us/ From ietf-dane at dukhovni.org Sat Jun 15 23:44:59 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 15 Jun 2019 17:44:59 -0400 Subject: DANE plus wildcard record In-Reply-To: <3a674f6484570165e3d6efd1a5e006c4@nodns4.us> <0e71195634e2181d37e4a994ecd21ef4@nodns4.us> Message-ID: <20190615214459.GA84864@straasha.imrryr.org> On Sat, Jun 15, 2019 at 12:11:29PM -0500, Rob McGee wrote: > One of my subscribers recently signed his or her zone, and sadly, has a > wildcard A in that zone. Wildcard A records are not in themselves a problem for DANE, lots of domains have them with no issues. What can be a problem is having a nameserver that omits the wildcard name from the NSEC/NSEC3 chain, and therefore returns "bogus" denial of existence when asked for the TLSA records. Consider a zone containing only the zone apex (with SOA, DNSKEY, NS, MX records and associated RRSIGs) and a signed wildcard A record (with RRSIG): ; Zone apex NS/SOA/DNSKEY/... elided example.com. IN MX 0 smtp.example.com. example.com. IN A 192.0.2.1 ; Wildcard A record only other node in the zone *.example.com. IN A 192.0.2.1 Its NSEC chain *should* be: example.com. IN NSEC *.example.com. A NS SOA MX RRSIG NSEC DNSKEY *.example.com. IN NSEC example.com. A RRSIG NSEC The address of the MX host "smtp.example.com" is wildcard-synthesised, and the correct response for the TLSA query would be: $ dig +norecur +dnssec -t tlsa _25.tcp.smtp.example.com. @ns1.example.com. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ; _25._tcp.smtp.example.com IN TLSA ? ;; OPT PSEUDOSECTION: ; ... ;; QUESTION SECTION: ;_25._tcp.smtp.example.com. IN TLSA example.com. IN SOA ... example.com. IN RRSIG SOA ... example.com. IN NSEC example.com. A NS SOA MX RRSIG NSEC DNSKEY example.com. IN RRSIG NSEC ... The NOERROR rather than NXDOMAIN is due to the wildcard, but since it only has A records, and no TLSA records, the answer count is zero. The authority records provide the authenticated denial of existence proof. The signed NSEC record establishes the existence of the wildcard, and non-existence of "smtp.example.com" as an explicit name in the zone. Now, consider what happens if the nameserver software or zone data is broken and omits the wildcard from NSEC chain, which now contains only the zone apex (This is a circular reference in otherwise empty zones): $ dig +norecur +dnssec -t tlsa _25.tcp.smtp.example.com. @ns1.example.com. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ; _25._tcp.smtp.example.com IN TLSA ? ;; OPT PSEUDOSECTION: ; ... ;; QUESTION SECTION: ;_25._tcp.smtp.example.com. IN TLSA example.com. IN SOA ... example.com. IN RRSIG SOA ... example.com. IN NSEC example.com. A RRSIG NSEC example.com. IN RRSIG NSEC ... We now have a contradiction. The header says "NOERROR", implying the name exists or is wildcard-synthesised, but the NSEC chain proves that only the zone apex exists, so a consistent answer would be NXDOMAIN. In this situation (and others similar in spirit if not every detail), the validating resolver returns "SERVFAIL". This problem is somewhat more frequent with PowerDNS servers backed by a database, when the SQL database with the zone data is incorrectly populated, or the software is substantially outdated. > The checker reports "DNS lookup error for TLSA records: SERVFAIL", > which is what I get on the named recursive resolver that Postfix is > using, querying "_25._tcp.smtp.example.com./IN/TLSA". > > So Postfix is refusing to deliver, believing that there should be a > TLSA. But AFAIK this user never published TLSA. Yes, but that fact has to have a valid denial of existence proof, or else absence of TLSA records could be trivially spoofed, introducing MiTM attacks that DNSSEC is designed to prevent. > The SOA MNAME host has disabled version.bind./CH/TXT lookups so I am > not sure what software is in use, but having A for an invalid hostname > (underscores not allowed in hostnames) would be a problem for BIND > named, which by default would not allow that. The "_" is allowed in TLSA records, this is not relevant here. > But I don't know how that feature interacts with wildcard records. Wildcard A records work as one would expect. Indeed you should be able to resolve "_25._tcp.smtp.example.com IN A ?" and get the wildcard address. > Testing on a dnsmasq from home I don't get SERVFAIL, just NOERROR. That's because dnsmasq is not doing DNSSEC validation. On Sat, Jun 15, 2019 at 01:48:27PM -0500, Rob McGee wrote: > The immediate problem has been solved with a bandaid, > smtp_tls_policy_maps, with an entry: > > example.com may Or, alternatively, in e.g. unbound: server: domain-insecure: "example.com." > I still think this is an interesting problem, perhaps a BIND problem. No, the issue is broken DNS for example.com. On Sat, Jun 15, 2019 at 02:41:15PM -0500, Rob McGee wrote: > Logs (from named) of the SERVFAIL: > > 15-Jun-2019 18:49:00.567 lame-servers: info: broken trust chain > resolving '_25._tcp.smtp.example.com/TLSA/IN': 176.56.237.121#53 Finally, a data leak! :-) That IP address, 176.56.237.121, is dynu.com. They have multiple domains that have broken DoE (Denial of Existence), e.g. jerryscomputing.com SOA ns1.dynu.com administrator at dynu.com When I ask the domain's nameservers for TLSA records, they all just return empty NOERROR replies (EDNS OPT record only, no SOA, no RRSIG, ...): @ns1.dynu.com.[207.38.70.2] @ns2.dynu.com.[104.247.193.125] @ns3.dynu.com.[45.79.219.7] @ns4.dynu.com.[45.119.209.45] @ns5.dynu.com.[74.121.191.194] @ns6.dynu.com.[168.235.71.124] ; <<>> DiG 9.14.2 <<>> +noidnout +nosearch +dnssec +noall +cmd +comment +qu +ans +auth +nocl +nottl +nosplit +norecur -t tlsa _25._tcp.jerryscomputing.com @... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31304 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;_25._tcp.jerryscomputing.com. IN TLSA While asking for an A record for the same name returns: @ns1.dynu.com.[207.38.70.2] @ns2.dynu.com.[104.247.193.125] @ns3.dynu.com.[45.79.219.7] @ns4.dynu.com.[45.119.209.45] @ns5.dynu.com.[74.121.191.194] @ns6.dynu.com.[168.235.71.124] ; <<>> DiG 9.14.2 <<>> +noidnout +nosearch +dnssec +noall +cmd +comment +qu +ans +auth +nocl +nottl +nosplit +norecur -t a _25._tcp.jerryscomputing.com @... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63350 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;_25._tcp.jerryscomputing.com. IN A _25._tcp.jerryscomputing.com. RRSIG A 13 4 90 20190617213727 20190613213727 5126 jerryscomputing.com. _25._tcp.jerryscomputing.com. A 3.13.189.185 which appears to be signed "on the fly" (ECDSA P-256, algorithm 13, is fast enough to make that practical) rather than wildcard-synthesised, because the RRSIG label count is 4 and no NSEC records were sent to justify the use of a wildcard. So this server lies about wildcards and returns synethetic records on the fly, avoiding NSEC as much as possible, but does not know how to handle non-existent RR types. This is a case of all-too-clever broken software, that fails to correctly implement DNSSEC denial of existence. Your subscriber needs to find a more competent DNS provider. -- Viktor. From rob0 at nodns4.us Sun Jun 16 01:47:59 2019 From: rob0 at nodns4.us (Rob McGee) Date: Sat, 15 Jun 2019 18:47:59 -0500 Subject: DANE plus wildcard record In-Reply-To: <20190615214459.GA84864@straasha.imrryr.org> References: <20190615214459.GA84864@straasha.imrryr.org> Message-ID: On 2019-06-15 16:44, Viktor Dukhovni wrote: > On Sat, Jun 15, 2019 at 12:11:29PM -0500, Rob McGee wrote: > >> One of my subscribers recently signed his or her zone, and sadly, has >> a >> wildcard A in that zone. > > Wildcard A records are not in themselves a problem for DANE, lots > of domains have them with no issues. What can be a problem is Okay, blaming this on the wildcard was my first impulse, but as I began to dig (no pun intended, or maybe it was) deeper, I doubted it. The dane.sys4.de tool got a SERVFAIL, and when I checked my own named logs I saw that the SERVFAIL was a query for DS for smtp.example.com. Had nothing to do with the existence of the _25.tcp.smtp.example.com. name. > having a nameserver that omits the wildcard name from the NSEC/NSEC3 > chain, and therefore returns "bogus" denial of existence when asked > for the TLSA records. ... and this is why named wanted to check for DS, I guess. ... >> So Postfix is refusing to deliver, believing that there should be a >> TLSA. But AFAIK this user never published TLSA. > > Yes, but that fact has to have a valid denial of existence proof, > or else absence of TLSA records could be trivially spoofed, introducing > MiTM attacks that DNSSEC is designed to prevent. Oh, yes. At first I wondered if there was a Postfix DANE bug here, but indeed, refusing to deliver when getting SERVFAIL on the way to the TLSA is the only reasonable thing to do. Similarly, named is doing the right thing in the face of the broken NSEC chain. > On Sat, Jun 15, 2019 at 02:41:15PM -0500, Rob McGee wrote: > >> Logs (from named) of the SERVFAIL: >> >> 15-Jun-2019 18:49:00.567 lame-servers: info: broken trust chain >> resolving '_25._tcp.smtp.example.com/TLSA/IN': 176.56.237.121#53 > > Finally, a data leak! :-) That IP address, 176.56.237.121, is > dynu.com. They have multiple domains that have broken DoE (Denial > of Existence), e.g. Haha, indeed it is, glad I was able to accidentally help you to get to the bottom of this. :) I'm not a very good redactor. ... > This is a case of all-too-clever broken software, that fails to > correctly implement DNSSEC denial of existence. Your subscriber > needs to find a more competent DNS provider. Gotcha. I will pass the word along. Thank you for the sharp eye and the detailed explanations. -- http://rob0.nodns4.us/ From ietf-dane at dukhovni.org Sun Jun 16 07:41:10 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 16 Jun 2019 01:41:10 -0400 Subject: DANE plus wildcard record In-Reply-To: <20190615214459.GA84864@straasha.imrryr.org> References: <3a674f6484570165e3d6efd1a5e006c4@nodns4.us> <0e71195634e2181d37e4a994ecd21ef4@nodns4.us> <20190615214459.GA84864@straasha.imrryr.org> Message-ID: <20190616054110.GB84864@straasha.imrryr.org> On Sat, Jun 15, 2019 at 05:44:59PM -0400, Viktor Dukhovni wrote: > The address of the MX host "smtp.example.com" is wildcard-synthesised, > and the correct response for the TLSA query would be: > > $ dig +norecur +dnssec -t tlsa _25.tcp.smtp.example.com. @ns1.example.com. > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345 > ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 > ; _25._tcp.smtp.example.com IN TLSA ? > > ;; OPT PSEUDOSECTION: > ; ... > ;; QUESTION SECTION: > ;_25._tcp.smtp.example.com. IN TLSA > > example.com. IN SOA ... > example.com. IN RRSIG SOA ... > example.com. IN NSEC example.com. A NS SOA MX RRSIG NSEC DNSKEY > example.com. IN RRSIG NSEC ... Sorry, when re-reading this, I noticed that I accidentally in part edited the "should be" response while editing the wrong response and vice-versa. The *correct* NSEC record is the wildcard one: *.example.com. IN NSEC example.com. A RRSIG NSEC *.example.com. IN RRSIG NSEC ... The "wrong" record when the NSEC chain is incomplete is: example.com. IN NSEC example.com. A NS SOA MX RRSIG NSEC DNSKEY example.com. IN RRSIG NSEC ... as it turned out, the issue with dynu.com is somewhat different, in that they simply don't appear to do NSEC (or NSEC3) records, which means that DNSSEC-signed domains they host that don't have TLSA records, are broken. -- Viktor. From bart.knubben at forumstandaardisatie.nl Tue Jun 25 21:56:09 2019 From: bart.knubben at forumstandaardisatie.nl (Knubben, B.S.J. (Bart) - Forum Standaardisatie) Date: Tue, 25 Jun 2019 19:56:09 +0000 Subject: Proofpoint announces DANE support Message-ID: <6dc6f7d659f7450ca82ddd6b46affccd@SV1601472.frd.shsdir.nl> Hi, See: https://twitter.com/ProofpointJ/status/1143536219126677504 and also https://mobile.twitter.com/internet_nl/status/1143548855075651584 -- Best regards, Bart Knubben Dutch Standardisation Forum https://www.forumstandaardisatie.nl/content/english Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.