Re: DNSSEC/DANE: TLSA records looked up for parent domain
Dear Postfix folks, Am 17.02.22 um 10:57 schrieb Paul Menzel: Using Postfix 3.6.0-rc1, for an email sent to x.y.molgen.mpg.de it looks up the TLSA records for y.molgen.mpg.de instead of x.y.molgen.mpg.de: 2022-02-12T12:02:21+01:00 tldr postfix/smtp[25656]: warning: TLS policy lookup for github.molgen.mpg.de/github.molgen.mpg.de: no TLSA records found 2022-02-12T12:02:21+01:00 tldr postfix/smtp[25656]: 6D99D61E6478B: to=, relay=none, delay=0.3, delays=0.28/0.02/0/0, dsn=4.7.5, status=deferred (no TLSA records found) I forgot to mention, that this is all handled internally. I haven’t tried from another domain. Not that we have dane-only TLS policy configured for our domains, as we use DNSSEC and the MTAs all have TLSA records published. (And dane TLS policy unfortunately falls back to encrypt and not secure.) Indeed for github.molgen.mpg.de no MX record exists, but there shouldn’t as the message goes to reply.github.molgen.mpg.de: $ dig mx reply.github.molgen.mpg.de +dnssec +short 5 mx3.molgen.mpg.de. MX 7 5 7200 20220318110038 20220216110038 14960 molgen.mpg.de. kTDvX9PKXC9sk96QViR09wUATN3m96sz6Ha6FrMRBrjxUa1OU1AdhvVj cJbRyetiHy3v+uOPdrng4NLVAow/omnF7Ph0twfz9p9EXUfOBBC/6QJJ Ym5JfxgjDWReHVFw5Y+duQSXtvSOjJR0KwHECtcAClWxO0e98/EtvEmP TQajwIkw5sA8wOmcIMu6BKIjaEZvEVB6NQxT72HrEpNbsKWnbBWfj71k qYag1hsmuVWzjLtN8E2AtPYic13x55t8tV1hEnlHcgFAp2Fya1y+o6hA okDMrg9JUf3/qSjjox3hY78IKAcw8KDz8DEwvjBnr76/6ut9zQ2oIc+P XA7N+w== $ dig _25._tcp.mx3.molgen.mpg.de IN TLSA +short 3 1 2 7AAD43A0FDFF34452CA695A2B510F613A2997077E4C2EDFF2B32DE36 26552C2832EF72F5DC12B5FE3984BAFE1B87406207EDAD34A4F3E11F 49CD4A23DB83374C The DANE SMTP Validator verifies, that it should work for reply.github.molgen.mpg.de [1]. Any idea, why github.molgen.mpg.de is looked at? Kind regards, Paul [1]: https://dane.sys4.de/smtp/reply.github.molgen.mpg.de
Re: dnssec DS set, but no RRSIG
On Mon, Nov 15, 2021 at 11:58:02AM +0800, Philip Paeps wrote: > On 2021-11-15 11:36:00 (+0800), Benny Pedersen wrote: > > plantmarknaden.com > > > > https://dane.sys4.de/smtp/plantmarknaden.com > > https://dnsviz.net/d/plantmarknaden.com/dnssec/ > > > > why diffrent results ? > > I don't see 'different' results. That domain is broken. Broken for over 1.5 years: https://stats.dnssec-tools.org/explore/?plantmarknaden.com -- Viktor.
Re: dnssec DS set, but no RRSIG
On 2021-11-15 11:36:00 (+0800), Benny Pedersen wrote: plantmarknaden.com https://dane.sys4.de/smtp/plantmarknaden.com https://dnsviz.net/d/plantmarknaden.com/dnssec/ why diffrent results ? I don't see 'different' results. That domain is broken. Neither of the listed DNS servers are returning DNSKEYs. Even if they returned RRSIGs with their responses (which they don't), nobody could validate them. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Re: DNSSEC Howto?
thanks Viktor El 28/03/2021 a las 1:21, Viktor Dukhovni escribió: On Sun, Mar 28, 2021 at 01:08:44AM +0100, Francesc Peñalvez wrote: Right now dnssec is activated in the external manager zoneedit.com, in which I cannot modify the type of encryption or the length of the key. If there are no key size or algorithm settings in zoneedit.com, then indeed you're set. The largish ZSK is typically OK, just risks some trouble with UDP fragmentation for a small fraction of clients on networks that doesn't work well. And if I am looking to activate inbound and outbound dnssec with my postfix There is no such thing as inbound DNSSEC specifically for Postfix. If your domain is signed, then validating resolvers will check the signatures as a routine part of MX and A/ lookups. For outbound DNSSEC, just turn on DNSSEC validation in your local resolver. There again nothing Postfix-specific to be done. DNSSEC only comes into play if you're looking to do DANE. http://www.postfix.org/TLS_README.html#client_tls_dane See also the resource links at: https://stats.dnssec-tools.org/explore/?. smime.p7s Description: Firma criptográfica S/MIME
Re: DNSSEC Howto?
On Sun, Mar 28, 2021 at 01:08:44AM +0100, Francesc Peñalvez wrote: > Right now dnssec is activated in the external manager zoneedit.com, in > which I cannot modify the type of encryption or the length of the key. If there are no key size or algorithm settings in zoneedit.com, then indeed you're set. The largish ZSK is typically OK, just risks some trouble with UDP fragmentation for a small fraction of clients on networks that doesn't work well. > And if I am looking to activate inbound and outbound dnssec with my postfix There is no such thing as inbound DNSSEC specifically for Postfix. If your domain is signed, then validating resolvers will check the signatures as a routine part of MX and A/ lookups. For outbound DNSSEC, just turn on DNSSEC validation in your local resolver. There again nothing Postfix-specific to be done. DNSSEC only comes into play if you're looking to do DANE. http://www.postfix.org/TLS_README.html#client_tls_dane See also the resource links at: https://stats.dnssec-tools.org/explore/?. -- Viktor.
Re: DNSSEC Howto?
Right now dnssec is activated in the external manager zoneedit.com, in which I cannot modify the type of encryption or the length of the key. And if I am looking to activate inbound and outbound dnssec with my postfix El 28/03/2021 a las 1:03, Viktor Dukhovni escribió: On Sat, Mar 27, 2021 at 01:59:56PM +0100, Francesc Peñalvez wrote: I have a connection of the domestic type, with 7 computers in an internal network, in which I do not have access to make any changes to the ip. I use external dns service to manage the bind9 service, although I have another installed and running locally. OK, so you have an outsourced public authoritative server for your DNSSEC signed domain Both in the external and internal services of bind I have the same configuration of dmarc and dkim and of course I would like to know, I am really a novice in system administration, if the external dnssec configuration that manages the domain, zoneedit, is enough to use dnssec correctly? You still have not explained what "use DNSSEC" means. Your DNS works. The RSA ZSK is larger than I'd recommend, but otherwise no issues. Are you looking to enable inbound or outbound DANE on your Postfix server? What is the concrete Postfix-related goal for which you're seeking advice? smime.p7s Description: Firma criptográfica S/MIME
Re: DNSSEC Howto?
On Sat, Mar 27, 2021 at 01:59:56PM +0100, Francesc Peñalvez wrote: > I have a connection of the domestic type, with 7 computers in an > internal network, in which I do not have access to make any changes to > the ip. I use external dns service to manage the bind9 service, > although I have another installed and running locally. OK, so you have an outsourced public authoritative server for your DNSSEC signed domain > Both in the external and internal services of bind I have the same > configuration of dmarc and dkim and of course I would like to know, I > am really a novice in system administration, if the external dnssec > configuration that manages the domain, zoneedit, is enough to use > dnssec correctly? You still have not explained what "use DNSSEC" means. Your DNS works. The RSA ZSK is larger than I'd recommend, but otherwise no issues. Are you looking to enable inbound or outbound DANE on your Postfix server? What is the concrete Postfix-related goal for which you're seeking advice? -- Viktor.
Re: DNSSEC Howto?
I have a connection of the domestic type, with 7 computers in an internal network, in which I do not have access to make any changes to the ip. I use external dns service to manage the bind9 service, although I have another installed and running locally. Both in the external and internal services of bind I have the same configuration of dmarc and dkim and of course I would like to know, I am really a novice in system administration, if the external dnssec configuration that manages the domain, zoneedit, is enough to use dnssec correctly? El 27/03/2021 a las 13:34, Viktor Dukhovni escribió: On Sat, Mar 27, 2021 at 12:51:36PM +0100, Francesc Peñalvez wrote: I have the dns of the domain managed externally, configured with dnssec, and another host running postfix. How could I integrate that postfix use the dnssec configuration? Would it be enough to add the dns of the external service to the postfix resolv.conf? As written, the question makes no sense. You'll need to explain your goals in more detail. - If your domain is already signed, then clients resolving data about your domain are able (when suitably configured) to validate the integrity of that data. - If you're looking to use DNSSEC as a client, to validate DNS records of remote domains, all you need is a local (running on the Postfix server itself, listening on 127.0.0.1:53) validating resolver, such as unbound, Knot, BIND, ... * The DNSSEC status of your own domain is irrelevant for validating remote domains. * Validating remote domains does not directly do anything to ensure data integrity for your own domains when queried by others. See: https://stats.dnssec-tools.org/explore/?almogavers.net https://dnsviz.net/d/almogavers.net/YFjc3g/dnssec/ I would perhaps recommed either switching to algorithm 13 (ECDSA P256), which has better security at a lower key size, or use a ZSK that is shorter than 2048 bits (1280 bits is what .COM uses), which tends to be a bit too large for unfragmented UDP when responses carry multiple signatures (e.g. NSEC3 negative answers). Fragmented UDP is not reliable these days over wide-area networks. For small zones with no names to hide, just use NSEC. smime.p7s Description: Firma criptográfica S/MIME
Re: DNSSEC Howto?
On Sat, Mar 27, 2021 at 12:51:36PM +0100, Francesc Peñalvez wrote: > I have the dns of the domain managed externally, configured with > dnssec, and another host running postfix. How could I integrate that > postfix use the dnssec configuration? Would it be enough to add the > dns of the external service to the postfix resolv.conf? As written, the question makes no sense. You'll need to explain your goals in more detail. - If your domain is already signed, then clients resolving data about your domain are able (when suitably configured) to validate the integrity of that data. - If you're looking to use DNSSEC as a client, to validate DNS records of remote domains, all you need is a local (running on the Postfix server itself, listening on 127.0.0.1:53) validating resolver, such as unbound, Knot, BIND, ... * The DNSSEC status of your own domain is irrelevant for validating remote domains. * Validating remote domains does not directly do anything to ensure data integrity for your own domains when queried by others. See: https://stats.dnssec-tools.org/explore/?almogavers.net https://dnsviz.net/d/almogavers.net/YFjc3g/dnssec/ I would perhaps recommed either switching to algorithm 13 (ECDSA P256), which has better security at a lower key size, or use a ZSK that is shorter than 2048 bits (1280 bits is what .COM uses), which tends to be a bit too large for unfragmented UDP when responses carry multiple signatures (e.g. NSEC3 negative answers). Fragmented UDP is not reliable these days over wide-area networks. For small zones with no names to hide, just use NSEC. -- Viktor.
Re: DNSSEC, DANE, Postfix for new-to-it admins?
On 4/17/20 4:29 PM, Viktor Dukhovni wrote: > More at: all links appreciated. the summary's particularly nicely readable by those of among the minion masses of normal humans ;-) > Postfix documentation covers the client side still among the best, most-exhaustively detailed s/docs/reference man/ out there. and still capable of causing fainting spells among said-same minion-masses. > Writing all of this down in detail is a non-trivial project, and would > perhaps be a small book. a cradle-2-grave, human-speak ebook would certainly sell! i'd have love to have one when I 1st got this running; still quite a tedious slog piecing it all together. the good news is that the info _is_ there to find. if you work at it. a lot. > I've not had the cycles... :-( hear ya. > I've started work on some text for this to add to the Postfix > TLS_README, but it won't cover all the topics, and will only sketch out > the requirements, the reader will need to fill in various details from > other sources (or prior experience). even 'just' that^, with links curated as being reliable, and a crude step-by-step will be useful. ty o/
Re: DNSSEC, DANE, Postfix for new-to-it admins?
On Fri, Apr 17, 2020 at 03:59:49PM -0700, PGNet Dev wrote: > Real World DANE Inter-domain email transport > > https://static.ptbl.co/static/attachments/169319/1520904692.pdf More at: https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources Specific issues: https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022/17 https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html > Any favorites/recommendations for current "what/why" & "how to" DNSSEC/DANE > with Postfix docs/tutorials/posts/etc? Postfix documentation covers the client side, but the DANE for servers HOTWO has not yet been written. This is partly because there's little that's Postfix-specific there. What's required is general operational discipline around monitoring, DNSSEC and certificate management taking cached TLSA records into account. > Particularly for completely-new-to-DNSSEC/DANE, but mostly > self-sufficient with Postfix otherwise, admins? The client side is easy: * Postfix >= 2.11, but at this point 3.2 is the oldest still supported. * Loopback validating resolver, e.g. BIND or unbound. * Only 127.0.0.1 in /etc/resolv.conf * smtp_dns_support_level = dnssec * smtp_tls_security_level = dane The server side is where the operational discipline is needed: * To manage and monitor DNS (tools improving, BIND 9.16 highly recommended with much better support for automatic signing and ZSK, and KSK rollover). - Monitor slave replication - Monitor signature expiration - Monitor consistency of glue NS records with zone apex - Monitor DS RRset vs. KSK consistency * To manage and monitor TLSA records: - pre-publish new TLSA RRs multiple TTLs before making the corresponding certificate chain changes. - make sure that TLSA RRs cover every support SNI name, and as appropriate the cert chain for each algorithm (RSA, ECDSA, ...) for which you have certificates. - monitor the correctness of the TLSA records by running frequent (say hourly) tests of all applicable certificate chains (SNI and/or algorithm-specific). - monitor STARTTLS support to make sure that STARTTLS is consistently available, certificates are not expired (when publishing "2 1 1", or similar DANE-TA(2) records), that all expected TLS protocol versions work (TLSv1.2 required, TLSv1.3 recommended). - ... Writing all of this down in detail is a non-trivial project, and would perhaps be a small book. I've not had the cycles... :-( I've started work on some text for this to add to the Postfix TLS_README, but it won't cover all the topics, and will only sketch out the requirements, the reader will need to fill in various details from other sources (or prior experience). -- Viktor.
Re: dnssec fails for domain with dnssec disabled
On Sat, Feb 23, 2019 at 06:20:02PM +0100, Benny Pedersen wrote: > sorry for OT but > > named[29088]: validating ebokssmtp.e-boks.dk/A: no valid signature found > named[29088]: validating advisering.e-boks.dk/MX: no valid signature found > named[29088]: validating e-boks.dk/SOA: no valid signature found > named[29088]: validating 9HUFO4E59MN3J8OUO77E3P7B5T38AIAN.e-boks.dk/NSEC3: no > valid signature found > named[29088]: validating advisering.e-boks.dk/TXT: no valid signature found > named[29088]: validating advisering.e-boks.dk/A: no valid signature found > named[29088]: validating smtp-in.e-boks.dk/A: no valid signature found > named[29088]: validating e-boks.dk/NS: no valid signature found > named[29088]: validating www.e-boks.dk/CNAME: no valid signature found > named[29088]: validating exc2001._domainkey.advisering.e-boks.dk/TXT: no > valid signature found I don't know why your BIND resolver is attempting to validate signatures for this domain, though it has DNSKEY records, and signatures, there are no associated DS records in the parent .dk zone. It resolves fine here. Perhaps the DS records were present previously, and since deleted? In any case, it should be possible to configure named to not validate any given domain. With "unbound" (my choice of validating resolver), this can be done via: server: domain-insecure: "e-boks.dk" -- Viktor.
Re: DNSSEC - DANE
On Wed, Dec 31, 2014 at 12:45:20AM -0500, John wrote: https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.1 https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.4 Sorry, https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1 https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.4 Both of the above return object not found I assume that as they are both draft docs they come and go as the editors update them. Well, no, IETF documents are retained indefinitely. -- Viktor.
Re: DNSSEC - DANE
On Wed, Dec 31, 2014 at 12:23:16AM -0500, John wrote: smtpd_use_tls = yes smtpd_tls_security_level = may Just so I get this right /smtpd_tls_security_level = dane/ is acceptable, No, DANE TLS is for the sending (verifying) MTA only. -- Viktor.
Re: DNSSEC - DANE
On December 31, 2014 12:37:52 PM Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Wed, Dec 31, 2014 at 12:45:20AM -0500, John wrote: https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.1 https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.4 Sorry, Don't worry about it. https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1 https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.4 Both of the above return object not found I assume that as they are both draft docs they come and go as the editors update them. Well, no, IETF documents are retained indefinitely. -- Viktor.
Re: DNSSEC - DANE
John: *Dec 30 19:16:35 bilbo postfix/smtp[3376]: warning: [127.0.0.1]:10024: dane configured with dnssec lookups disabled* Have you noticed the unused parameter warning for smtp_dns_supporta_level? Wietse
Re: DNSSEC - DANE
Wietse Venema: John: *Dec 30 19:16:35 bilbo postfix/smtp[3376]: warning: [127.0.0.1]:10024: dane configured with dnssec lookups disabled* Have you noticed the unused parameter warning for smtp_dns_supporta_level? That is, when you use the postconf command to show the configuration that Postfix actually uses. Wietse
Re: DNSSEC - DANE
On 12/30/2014 7:58 PM, wie...@porcupine.org (Wietse Venema) wrote: Wietse Venema: John: *Dec 30 19:16:35 bilbo postfix/smtp[3376]: warning: [127.0.0.1]:10024: dane configured with dnssec lookups disabled* Have you noticed the unused parameter warning for smtp_dns_supporta_level? That is, when you use the postconf command to show the configuration that Postfix actually uses. Wietse That is what comes of making last minute changes. the a was part of another document that I was editing, I failed to shift focus. -- John Allen KLaM -- You are off the edge of the map, mate. Here there be monsters!
Re: DNSSEC - DANE
On Tue, Dec 30, 2014 at 07:47:24PM -0500, John wrote: I have setup my DNS server for DNSSEC + DANE. I am using inline signing on Bind9 and it appears to be working for HTTPS access. I have a minor problem with key rolling, it seems to be a rather cumbersome process at the moment, but I suspect that it is me rather than the process. Having got it working for HTTPS, I felt that I could move on to implementing it for SMTP (Postfix). For inbound DANE TLS you're all set. My work-in-progress danecli shows: $ danecli -mg klam.ca klam.ca. IN MX 10 smtp.klam.ca. ; NOERROR AD=1 1/0 1/0/1 smtp.klam.ca. IN A 74.116.186.178 ; passed _25._tcp.smtp.klam.ca. IN TLSA 3 0 1 5bf12300255d1475ae43677b7062ab8964ca097ee6096cd005115b8c974e83ab ; passed at depth=0 smtp.klam.ca. IN 2001:470:b183:10:0:0:0:178 ; connerr: Connection timed out Which means that smtp.klam.ca has a working TLSA RRset, but perhaps has IPv6 connectivity issues. As for key rotation, see: https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.1 https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.4 smtp_use_tls = yes This is obsolete, superseded by smtp_tls_security_level below: smtp_tls_security_level = dane And likewise: smtpd_use_tls = yes smtpd_tls_security_level = may -- Viktor.
Re: DNSSEC - DANE
On 12/30/2014 11:19 PM, Viktor Dukhovni wrote: On Tue, Dec 30, 2014 at 07:47:24PM -0500, John wrote: I have setup my DNS server for DNSSEC + DANE. I am using inline signing on Bind9 and it appears to be working for HTTPS access. I have a minor problem with key rolling, it seems to be a rather cumbersome process at the moment, but I suspect that it is me rather than the process. Having got it working for HTTPS, I felt that I could move on to implementing it for SMTP (Postfix). For inbound DANE TLS you're all set. My work-in-progress danecli shows: $ danecli -mg klam.ca klam.ca. IN MX 10 smtp.klam.ca. ; NOERROR AD=1 1/0 1/0/1 smtp.klam.ca. IN A 74.116.186.178 ; passed _25._tcp.smtp.klam.ca. IN TLSA 3 0 1 5bf12300255d1475ae43677b7062ab8964ca097ee6096cd005115b8c974e83ab ; passed at depth=0 smtp.klam.ca. IN 2001:470:b183:10:0:0:0:178 ; connerr: Connection timed out Which means that smtp.klam.ca has a working TLSA RRset, but perhaps has IPv6 connectivity issues. As for key rotation, see: https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.1 https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.4 smtp_use_tls = yes This is obsolete, superseded by smtp_tls_security_level below: smtp_tls_security_level = dane And likewise: smtpd_use_tls = yes smtpd_tls_security_level = may Just so I get this right /smtpd_tls_security_level = dane/ is acceptable, I ask because I did not find this in the postfix docs. Do I also need smtpd_dns_support_level = dnssec answered my own ? postconf tosses out smtpd...= dnssec and accepts smtpd...= dane. Are there any other gotchas that I should be aware of. Thank you very much for the the test. Yes I have a intermittent IPv6 problem - my ISP. To get IPv6 connectivity I have to use HE.net tunnel broker as my ISP is/thinking/ about IPv6. I suspect that as they are resellers for Bell Canada he is waiting for them to get off their butts. 98% of the time there is no problem but every so often IPv6 just stop working. This appears to be one of them. -- John Allen KLaM -- In the world of the internet if you're not paying for something, you're not the customer; you are the product being sold /from the blue_beetle/
Re: DNSSEC - DANE
https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.1 https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.4 Both of the above return object not found I assume that as they are both draft docs they come and go as the editors update them. I will keep an eye on the site, hopefully catch them next time they are available. -- John Allen KLaM -- OK, so what is the speed of dark?
Re: DNSSEC - DANE
/smtpd_tls_security_level = dane/. postconf does not show any error for the above, but postfix itself does fatal: invalid TLS level dane - I have switched back to may -- John Allen KLaM -- You are off the edge of the map, mate. Here there be monsters!
Re: DNSSEC
On 2/25/2014 10:32 AM, Viktor Dukhovni postfix-us...@dukhovni.org wrote: My domains are (or will be when the transfer completes) signed with NSEC3. RFC 5155 (NSEC3) was published in 2008. The root zone was signed around 2010. DNSSEC is up and running. Well, I sent them the two responses I got here (from rob0 and Victor), and, in addition to what I think is the real reason, here is what they came back with: domains are more likely to go down do to poor DNSSEC administration than any domain will be down due to cache poisoning or the other hacks that DNSSEC is designed to prevent. Have you actually heard of DNSSEC successfully stopping a hack yet? You probably haven not because it hasn't. Have you heard of DNSSEC causing downtime for domains? I am sure you have... because it happens often. This is way most of the largest domains do not support DNSSEC, nor will they. sigh Oh well, not an immediate problem, and their normal DNS service is excellent (and really cheap - $29/yr for up to 10 domains)... -- Best regards, Charles
Re: DNSSEC
On Wed, Feb 26, 2014 at 01:32:09PM -0500, Charles Marcus wrote: Well, I sent them the two responses I got here (from rob0 and Victor), and, in addition to what I think is the real reason, here is what they came back with: domains are more likely to go down do to poor DNSSEC administration than any domain will be down due to cache poisoning or the other hacks that DNSSEC is designed to prevent. I hate to admit it, but this is true. :) BIND 9.8 and 9.9 have nice maintain features which prevent the poor administration problems. But with 9.7 and earlier people were using semi-manual signing. Upgrade to a supported BIND version and you will have no problem; if you don't mind leaving your keys on the master server, that is. Have you actually heard of DNSSEC successfully stopping a hack yet? You probably haven not because it hasn't. It's also mostly true that serving bogus DNS data is not a common attack, NXDOMAIN hijacking being the exception. So anyway, you can counter that, Yes, DNSSEC detects NXDOMAIN hijacking. Have you heard of DNSSEC causing downtime for domains? I am sure you have... because it happens often. As with anything, if you know what you're doing, it does not. I might also add that the terminology used, downtime for domains et c., is indicative of a non-professional. For what that's worth. This is way most of the largest domains do not support DNSSEC, nor will they. Funny if that is true, because the big guys are the most likely targets for DNS spoofing or hijacking attacks. sigh Oh well, not an immediate problem, and their normal DNS service is excellent (and really cheap - $29/yr for up to 10 domains)... I do still believe that DNSSEC adoption will increase, and with it the demand for clueful and capable DNS providers will rise. But I have to admit that these threads have shown a glimpse into other worlds. :) For me, when the root zone was signed, DNSSEC was something I had to do. I found that my Zoneedit nameservers didn't support it, so I removed them and went for self-hosting. It never occurred to me that no DNSSEC was an option. :) -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: DNSSEC, was Re: TLS client logging PATCH
On 2/24/2014 3:52 PM, /dev/rob0 r...@gmx.co.uk wrote: On Mon, Feb 24, 2014 at 01:16:39AM +0100, Dirk Stöcker wrote: On Sun, 23 Feb 2014, Viktor Dukhovni wrote: If you want scalable security for SMTP, become an early adopter of DANE TLS, available in Postfix 2.11. Today, you'll be able to opportunistically authenticate the handful of DNSSEC signed domains that publish TLSA records for SMTP. Over time, I hope that handful will grow to a decent fraction of SMTP sites. Oh yes - DNSSEC. When will it come? In hundred years? Dirk, do you mind explaining this? Are you having trouble finding DNSSEC-enabled DNS hosting? Well, here is what mine (DNSMadeEasy) says on the subject: After seeing others in the Managed DNS space fail to properly maintain these processes for customers and the headaches (and nightmares) that come from not properly implementing these processes, we have been very careful in approaching this difficult task. and DNS Made Easy is monitoring the DNSSEC RFCs and their progress on the standards track. We will not consider implementing DNSSEC until NSEC3 becomes widely implemented as NSEC allows domain enumeration (which we are firmly against). The root (.) domain is not signed and will not be signed for some time (if ever). There are currently some very real issues with DNSSEC key authentication, distribution, management, and revocation. DNS Made Easy will continue to evaluate DNSSEC implementation as these issues with the RFCs are resolved. Until the issues with DNS sec are resolved we will not consider implementing it with our primary service. I don't see this happening for a few years. Curious what others (especially Victor) think of this response. Why are they 'firmly against' NSEC's 'enumeration of domains' feature, and the comment about 'very real issues...'... Anyone have any recommendations for decent DNS Service Providers that don't cost an arm and another arm (DNSMadeEasy is really inexpensive, and their service has been awesome for the 3+ years we've been using them), and that are known to 'do DNSSEC' right? -- Best regards, Charles
Re: DNSSEC
On Tue, Feb 25, 2014 at 08:21:14AM -0500, Charles Marcus wrote: On 2/24/2014 3:52 PM, /dev/rob0 r...@gmx.co.uk wrote: On Mon, Feb 24, 2014 at 01:16:39AM +0100, Dirk Stöcker wrote: Oh yes - DNSSEC. When will it come? In hundred years? Dirk, do you mind explaining this? Are you having trouble finding DNSSEC-enabled DNS hosting? Well, here is what mine (DNSMadeEasy) says on the subject: After seeing others in the Managed DNS space fail to properly maintain these processes for customers and the headaches (and nightmares) that come from not properly implementing these processes, we have been very careful in approaching this difficult task. That sounds very reasonable. and DNS Made Easy is monitoring the DNSSEC RFCs and their progress on the standards track. That progress was completed for RFC 4035 in March 2005, nine years ago! Credibility begins to slip away. We will not consider implementing DNSSEC until NSEC3 becomes widely implemented as NSEC allows domain enumeration (which we are firmly against). This is absurd. NSEC3 is available now, of course, and it has been for many years. The absurdity is that the choice of NSEC3 or not belongs to the domain owner, no one else. Zone enumeration (or walking) is only a problem if the domain owner thinks it is. Are they saying that they want to see a certain percentage of domain owners adopt NSEC3? How would they determine this? And what is the point? The root (.) domain is not signed and will not be signed for some time (if ever). Plans to sign the root were announced in mid 2009, five years ago! Discussions leading to that announcement go back even further. At this, your provider admits to having been out of touch in excess of five years. There are currently some very real issues with DNSSEC key authentication, distribution, management, and revocation. DNS Made Easy will continue to evaluate DNSSEC implementation as these issues with the RFCs are resolved. And these issues are ... ? And I should listen to someone who has been out of touch with the DNS world over five years because ... ? Until the issues with DNS sec are resolved we will not consider implementing it with our primary service. I don't see this happening for a few years. Curious what others (especially Victor) think of this response. Why are they 'firmly against' NSEC's 'enumeration of domains' feature, and the comment about 'very real issues...'... Good questions. I don't know. I don't care. They shot their own credibility down. Anyone have any recommendations for decent DNS Service Providers that don't cost an arm and another arm (DNSMadeEasy is really inexpensive, and their service has been awesome for the 3+ years we've been using them), and that are known to 'do DNSSEC' right? Beyond what I said upthread, I am not sure. One thing worth mentioning: the New Way in the DNSSEC Age expects domain owners to run their own signing (probably stealth) master nameservers. As I told Dirk, those who can run Postfix won't have a problem with this. DNSSEC-enabled providers are likely to do it the way GKG and Linode do: offering DNSSEC as slave/secondary servers only. This way your keys are yours: they have real meaning, and you have real control. But that's still too geeky for some. When someone comes along who will do it all: register a domain, host it, sign it when the user clicks a checkbox: that will be hot. Maybe there are such providers now, but I haven't heard of them yet. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: DNSSEC
On Tue, Feb 25, 2014 at 09:07:13AM -0600, /dev/rob0 wrote: Curious what others (especially Victor) think of this response. Why are they 'firmly against' NSEC's 'enumeration of domains' feature, and the comment about 'very real issues...'... Good questions. I don't know. I don't care. They shot their own credibility down. My domains are (or will be when the transfer completes) signed with NSEC3. RFC 5155 (NSEC3) was published in 2008. The root zone was signed around 2010. DNSSEC is up and running. - Not all registries support DNSSEC, if your ccTLD or other parent domain is not signed, then you have to wait. The root, .com and .org domains are signed, as are some ccTLDs (.se, .nl, ...) - Not all registrars support publication of DS records, enough do, so moving to a competent registrar is generally not a problem. - All deployed DNSSEC validors support NSEC3. Many domains publish NSEC3 only with no ill-effects. - There is a last mile problem for DNSSEC. Mobile devices at airports, hotels, public wifi hotspots may encounter various difficulties for now. These are being worked on, but don't affect MTAs very much. Most MTAs don't move around. - I don't think I should be recommending specific registrars. There is an official list of .org registrars with a column that indicates DNSSEC support. Pick one of those, if it supports DNSSEC for your TLD or parent domain. -- Viktor.
Re: DNSSEC
On Mon, 24 Feb 2014, /dev/rob0 wrote: Oh yes - DNSSEC. When will it come? In hundred years? Dirk, do you mind explaining this? Are you having trouble finding DNSSEC-enabled DNS hosting? Reading about it for years - always with Delayed as main information (same like for IPv6). But OTOH during my current tests I detected that my mobile phone dialin provider offered me a nameserver supporting DNSSEC (whether I'll trust them to verify the entries for me is another matter, but at least they do). Maybe there really is progress. I'll again ask my DNS provider for their time-frame. Let's see if there will be movement this year. Self-hosting of DNS is not that difficult; in fact I think to set up and maintain a Postfix MTA is much more challenging than BIND named. But as with self-hosting mail, you get exposure to attacks and the need to watch for security issues and patches. I also run bind, but only for Dyn-DNS service. I'm not ready to risk all my services with my own DNS server installation - Only non-critical infrastructure (i.e. NOT the mail servers). Yep, I think DNSSEC and DANE will cheer you up quite well. :) Yes, it sounds fine. I'm waiting for it. But since the first time I heard about DNS based certificate some time is gone and I'm still waiting... Ciao -- http://www.dstoecker.eu/ (PGP key available)
