Loading ...
Sorry, an error occurred while loading the content.

Re: Running namecache service on postfix server?

Expand Messages
  • Wietse Venema
    ... I think it would be entirely reasonable to share a DNS cache among multiple systems within the same trusted perimeter. One DNS server per host in a farm of
    Message 1 of 25 , Feb 27, 2013
    • 0 Attachment
      Viktor Dukhovni:
      > Perhaps "postfix check" could generate a warning if DANE is enabled
      > and non-local nameservers are found in /etc/resolv.conf (or and/or
      > its chroot-jail version).

      I think it would be entirely reasonable to share a DNS cache among
      multiple systems within the same trusted perimeter. One DNS server
      per host in a farm of mail servers may not be practical.

      Wietse
    • DTNX Postmaster
      ... A local cache on each, forwarding to two or three resolvers that are nearby? Local for DNSSEC verification, nearby cache for performance reasons? Am I
      Message 2 of 25 , Feb 27, 2013
      • 0 Attachment
        On Feb 27, 2013, at 12:58, Wietse Venema <wietse@...> wrote:

        > Viktor Dukhovni:
        >> Perhaps "postfix check" could generate a warning if DANE is enabled
        >> and non-local nameservers are found in /etc/resolv.conf (or and/or
        >> its chroot-jail version).
        >
        > I think it would be entirely reasonable to share a DNS cache among
        > multiple systems within the same trusted perimeter. One DNS server
        > per host in a farm of mail servers may not be practical.

        A local cache on each, forwarding to two or three resolvers that are
        nearby? Local for DNSSEC verification, nearby cache for performance
        reasons? Am I missing something that would make that impractical?

        Cya,
        Jona
      • Robert Moskowitz
        ... In such a case I would run IPsec between them with a policy for only DNS traffic through the tunnel. ESP encapsulation is rather cheap and assures you the
        Message 3 of 25 , Feb 27, 2013
        • 0 Attachment
          On 02/27/2013 06:58 AM, Wietse Venema wrote:
          > Viktor Dukhovni:
          >> Perhaps "postfix check" could generate a warning if DANE is enabled
          >> and non-local nameservers are found in /etc/resolv.conf (or and/or
          >> its chroot-jail version).
          > I think it would be entirely reasonable to share a DNS cache among
          > multiple systems within the same trusted perimeter. One DNS server
          > per host in a farm of mail servers may not be practical.

          In such a case I would run IPsec between them with a policy for only DNS
          traffic through the tunnel. ESP encapsulation is rather cheap and
          assures you the traffic is going where you want it.

          Or if you have very good VLAN control, you could run 802.1AE, but the
          app space cannot tell (typically) if MACsec is working.
        • Robert Moskowitz
          ... Lots of cat skinners out here.
          Message 4 of 25 , Feb 27, 2013
          • 0 Attachment
            On 02/27/2013 09:25 AM, DTNX Postmaster wrote:
            > On Feb 27, 2013, at 12:58, Wietse Venema <wietse@...> wrote:
            >
            >> Viktor Dukhovni:
            >>> Perhaps "postfix check" could generate a warning if DANE is enabled
            >>> and non-local nameservers are found in /etc/resolv.conf (or and/or
            >>> its chroot-jail version).
            >> I think it would be entirely reasonable to share a DNS cache among
            >> multiple systems within the same trusted perimeter. One DNS server
            >> per host in a farm of mail servers may not be practical.
            > A local cache on each, forwarding to two or three resolvers that are
            > nearby? Local for DNSSEC verification, nearby cache for performance
            > reasons? Am I missing something that would make that impractical?

            Lots of cat skinners out here.
          • Viktor Dukhovni
            ... No, and that s pretty much what my original post suggests: ... As you say, one would typically add a couple of additional upstream caches: forward-addr:
            Message 5 of 25 , Feb 27, 2013
            • 0 Attachment
              On Wed, Feb 27, 2013 at 03:25:41PM +0100, DTNX Postmaster wrote:

              > > I think it would be entirely reasonable to share a DNS cache among
              > > multiple systems within the same trusted perimeter. One DNS server
              > > per host in a farm of mail servers may not be practical.
              >
              > A local cache on each, forwarding to two or three resolvers that are
              > nearby? Local for DNSSEC verification, nearby cache for performance
              > reasons? Am I missing something that would make that impractical?

              No, and that's pretty much what my original post suggests:

              On Tue, Feb 26, 2013 at 04:51:22PM +0000, Viktor Dukhovni wrote:

              > On Tue, Feb 26, 2013 at 09:58:54AM -0500, Robert Moskowitz wrote:
              >
              > Setting up DNSSEC on a local unbound cache that forwards all queries
              > to an upstream server boils down to:
              >
              > /etc/unbound/unbound.conf
              > server:
              > ...
              > trust-anchor: ". IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5"
              >
              > # Forward all requests to upstream server at 192.0.2.1
              > forward-zone:
              > name: "."
              > forward-addr: "192.0.2.1"

              As you say, one would typically add a couple of additional upstream caches:

              forward-addr: "192.0.2.2"
              forward-addr: "192.0.2.3"

              --
              Viktor.
            • Wietse Venema
              ... I think it would be helpful to give examples of how secure DNS caches can be shared, instead of outright banning this. On non-trivial deployments, DNS
              Message 6 of 25 , Feb 27, 2013
              • 0 Attachment
                DTNX Postmaster:
                > On Feb 27, 2013, at 12:58, Wietse Venema <wietse@...> wrote:
                >
                > > Viktor Dukhovni:
                > >> Perhaps "postfix check" could generate a warning if DANE is enabled
                > >> and non-local nameservers are found in /etc/resolv.conf (or and/or
                > >> its chroot-jail version).
                > >
                > > I think it would be entirely reasonable to share a DNS cache among
                > > multiple systems within the same trusted perimeter. One DNS server
                > > per host in a farm of mail servers may not be practical.
                >
                > A local cache on each, forwarding to two or three resolvers that are
                > nearby? Local for DNSSEC verification, nearby cache for performance
                > reasons? Am I missing something that would make that impractical?

                I think it would be helpful to give examples of how "secure DNS"
                caches can be shared, instead of outright banning this. On non-trivial
                deployments, DNS and MAIL are managed by different people.

                Wietse
              • Viktor Dukhovni
                ... This was the intent of my original example, I guess I did not draw sufficient attention to the: forward-zone: name: . forward-addr: 192.0.2.1 stanza at
                Message 7 of 25 , Feb 27, 2013
                • 0 Attachment
                  On Wed, Feb 27, 2013 at 10:20:50AM -0500, Wietse Venema wrote:

                  > > > I think it would be entirely reasonable to share a DNS cache among
                  > > > multiple systems within the same trusted perimeter. One DNS server
                  > > > per host in a farm of mail servers may not be practical.
                  > >
                  > > A local cache on each, forwarding to two or three resolvers that are
                  > > nearby? Local for DNSSEC verification, nearby cache for performance
                  > > reasons? Am I missing something that would make that impractical?
                  >
                  > I think it would be helpful to give examples of how "secure DNS"
                  > caches can be shared, instead of outright banning this. On non-trivial
                  > deployments, DNS and MAIL are managed by different people.

                  This was the intent of my original example, I guess I did not draw
                  sufficient attention to the:

                  forward-zone:
                  name: "."
                  forward-addr: 192.0.2.1

                  stanza at the bottom of the unbound.conf example. We'll need to
                  provide a similar configuration example for BIND, and explain the
                  rationale for both, so other local nameservers could also be
                  supported by an MTA administrator who understands the requirements.

                  --
                  Viktor.
                • Robert Moskowitz
                  ... True, but we are talking about a namecaching server here, not your standard fare for DNS support people. Or rather they are old hands at deploying caching
                  Message 8 of 25 , Feb 27, 2013
                  • 0 Attachment
                    On 02/27/2013 10:20 AM, Wietse Venema wrote:
                    > DTNX Postmaster:
                    >> On Feb 27, 2013, at 12:58, Wietse Venema <wietse@...> wrote:
                    >>
                    >>> Viktor Dukhovni:
                    >>>> Perhaps "postfix check" could generate a warning if DANE is enabled
                    >>>> and non-local nameservers are found in /etc/resolv.conf (or and/or
                    >>>> its chroot-jail version).
                    >>> I think it would be entirely reasonable to share a DNS cache among
                    >>> multiple systems within the same trusted perimeter. One DNS server
                    >>> per host in a farm of mail servers may not be practical.
                    >> A local cache on each, forwarding to two or three resolvers that are
                    >> nearby? Local for DNSSEC verification, nearby cache for performance
                    >> reasons? Am I missing something that would make that impractical?
                    > I think it would be helpful to give examples of how "secure DNS"
                    > caches can be shared, instead of outright banning this. On non-trivial
                    > deployments, DNS and MAIL are managed by different people.

                    True, but we are talking about a namecaching server here, not your
                    standard fare for DNS support people. Or rather they are old hands at
                    deploying caching servers where appropriate and could well supply
                    standard templates for them.

                    RHEL/Centos bind installs as a caching server, requiring very little in
                    edits, though as I pointed out in an earlier message I need to add
                    chroot since I have selinux off on the mail server (I don't think it was
                    postfix, but rather dovecot that forced this). Also I think if I change
                    my DNS address in ifcfg-eth0 to 127.0.0.1 and ::1 I can stop bind
                    listening on the local addresses so even less added to named.conf.

                    But to share a single DNS among a number of mail servers, say in a mail
                    farm that probably has lots of other types of servers running with
                    questionable content, I would want secure tunnels from the mail server
                    to the DNS server and that no longer is a non-trivial exercise. Now you
                    can always use my HIP protocol instead of IKEv2 for keying ESP, but
                    people doing this may want distro provided tunneling.

                    How much resources does a local caching server demand? I would think it
                    is mostly memory for the cache. You may have to throw a couple more Gb
                    at loaded server.
                  • Viktor Dukhovni
                    ... Nothing of the sort, just enable validation of outside domains and exempt local domains if unsigned. TSIG configuration is must more complex and is both
                    Message 9 of 25 , Feb 27, 2013
                    • 0 Attachment
                      On Wed, Feb 27, 2013 at 10:53:58AM -0500, Robert Moskowitz wrote:

                      > But to share a single DNS among a number of mail servers, say in a
                      > mail farm that probably has lots of other types of servers running
                      > with questionable content, I would want secure tunnels from the mail
                      > server to the DNS server and that no longer is a non-trivial
                      > exercise.

                      Nothing of the sort, just enable validation of outside domains and
                      exempt local domains if unsigned. TSIG configuration is must more
                      complex and is both beyond our reasonable ability to document with
                      specificity (too many variants between GSSAPI, and other security
                      mechanisms) and the ability of most administrators to configure.

                      The same goes for IPSEC, ...

                      > How much resources does a local caching server demand? I would think
                      > it is mostly memory for the cache. You may have to throw a couple
                      > more Gb at loaded server.

                      GB is the wrong order of magnitude. A megabyte of RAM should be
                      more than enough for local cache on most mail servers. Just need
                      room in the cache for the MX, A, TLSA and RRSIG of the 10 highest
                      volume destination domains and the A and PTR records of the 10
                      highest volume clients.

                      The purpose of the local cache (before DANE support) is to reduce
                      latency for the highest volume requests and to give the MTA
                      administrator the flexibility to craft custom local MX RRsets in
                      suitable local zones:

                      example.net.localhost. IN MX 0 internal-mx1.example.net.
                      example.net.localhost. IN MX 0 internal-mx2.example.net.

                      example.com.localhost. IN MX 0 gw1.localhost.
                      example.com.localhost. IN MX 0 gw2.localhost.

                      gw1.localhost. IN A 192.0.2.1
                      gw2.localhost. IN A 192.0.2.2

                      Then one can add transport table entries:

                      example.net smtp:example.net.localhost
                      example.com smtp:example.com.localhost

                      these won't break DNSSEC zone validation since "localhost" would
                      be a local unsigned zone. With DANE + DNSSEC the local cache also
                      makes it possible to trust the AD-bit without jumping through hoops
                      with TSIG or implementing DNSSEC validation in Postfix.

                      I think we've beaten this thread to death, I'm done for now.

                      --
                      Viktor.
                    • Robert Moskowitz
                      ... And I thank you for all you have said.
                      Message 10 of 25 , Feb 27, 2013
                      • 0 Attachment
                        On 02/27/2013 11:10 AM, Viktor Dukhovni wrote:
                        > I think we've beaten this thread to death, I'm done for now.

                        And I thank you for all you have said.
                      • Robert Moskowitz
                        ... On Centos 6.3 (bind 9.8.2 with security patches) I did: yum install bind bind-chroot In /etc/sysconfig/network-scripts/ifcfg-eth0 set: DNS1=127.0.0.1
                        Message 11 of 25 , Feb 27, 2013
                        • 0 Attachment
                          On 02/27/2013 10:43 AM, Viktor Dukhovni wrote:
                          > On Wed, Feb 27, 2013 at 10:20:50AM -0500, Wietse Venema wrote:
                          >
                          >>>> I think it would be entirely reasonable to share a DNS cache among
                          >>>> multiple systems within the same trusted perimeter. One DNS server
                          >>>> per host in a farm of mail servers may not be practical.
                          >>> A local cache on each, forwarding to two or three resolvers that are
                          >>> nearby? Local for DNSSEC verification, nearby cache for performance
                          >>> reasons? Am I missing something that would make that impractical?
                          >> I think it would be helpful to give examples of how "secure DNS"
                          >> caches can be shared, instead of outright banning this. On non-trivial
                          >> deployments, DNS and MAIL are managed by different people.
                          > This was the intent of my original example, I guess I did not draw
                          > sufficient attention to the:
                          >
                          > forward-zone:
                          > name: "."
                          > forward-addr: 192.0.2.1
                          >
                          > stanza at the bottom of the unbound.conf example. We'll need to
                          > provide a similar configuration example for BIND, and explain the
                          > rationale for both, so other local nameservers could also be
                          > supported by an MTA administrator who understands the requirements.

                          On Centos 6.3 (bind 9.8.2 with security patches) I did:

                          yum install bind bind-chroot

                          In /etc/sysconfig/network-scripts/ifcfg-eth0 set:

                          DNS1=127.0.0.1
                          DNS2=::1

                          ifdown eth0; ifup eth0

                          Add to /var/named/chroot/etc/named.conf options section:

                          forward only;
                          forwarders {
                          'IPv4 addr of forwarded server';
                          'IPv6 addr of forwarded server';
                          'etc.';
                          };


                          service bind start
                          chkconfig bind on

                          You CAN use 'forward first' and then if your forward server is
                          unreachable, your caching server will go out on the net to the '.'
                          servers and walk down from there. Look at 'first' as opportunistic local
                          forwarding and 'only' as forced local forwarding.
                        • Reindl Harald
                          ... hopefully to your own TRSUTABLE forwarders and not to ISP resolvers which all of their mangeling and the problems if you use spamhaus.org and such
                          Message 12 of 25 , Feb 27, 2013
                          • 0 Attachment
                            Am 27.02.2013 17:42, schrieb Robert Moskowitz:
                            > On Centos 6.3 (bind 9.8.2 with security patches) I did:
                            >
                            > yum install bind bind-chroot
                            >
                            > In /etc/sysconfig/network-scripts/ifcfg-eth0 set:
                            >
                            > DNS1=127.0.0.1
                            > DNS2=::1
                            >
                            > ifdown eth0; ifup eth0
                            >
                            > Add to /var/named/chroot/etc/named.conf options section:
                            >
                            > forward only;
                            > forwarders {
                            > 'IPv4 addr of forwarded server';
                            > 'IPv6 addr of forwarded server';
                            > 'etc.';
                            > };

                            hopefully to your own TRSUTABLE forwarders and not
                            to ISP resolvers which all of their mangeling and
                            the problems if you use spamhaus.org and such blacklists
                            that you get blocked
                          • Robert Moskowitz
                            ... Yes, you ONLY forward to servers where there is agreement that you MAY use them as forwarders. This is typically your own main DNS servers. Otherwise, it
                            Message 13 of 25 , Feb 27, 2013
                            • 0 Attachment
                              On 02/27/2013 11:47 AM, Reindl Harald wrote:
                              >
                              > Am 27.02.2013 17:42, schrieb Robert Moskowitz:
                              >> On Centos 6.3 (bind 9.8.2 with security patches) I did:
                              >>
                              >> yum install bind bind-chroot
                              >>
                              >> In /etc/sysconfig/network-scripts/ifcfg-eth0 set:
                              >>
                              >> DNS1=127.0.0.1
                              >> DNS2=::1
                              >>
                              >> ifdown eth0; ifup eth0
                              >>
                              >> Add to /var/named/chroot/etc/named.conf options section:
                              >>
                              >> forward only;
                              >> forwarders {
                              >> 'IPv4 addr of forwarded server';
                              >> 'IPv6 addr of forwarded server';
                              >> 'etc.';
                              >> };
                              > hopefully to your own TRSUTABLE forwarders and not
                              > to ISP resolvers which all of their mangeling and
                              > the problems if you use spamhaus.org and such blacklists
                              > that you get blocked

                              Yes, you ONLY forward to servers where there is agreement that you MAY
                              use them as forwarders. This is typically your own main DNS servers.
                              Otherwise, it runs 'out-of-the-box' as a caching server using the
                              regular '.' hints to find things.

                              Another tidbit is you should firewall access to port 53. Your caching
                              server is only for you. It is listening only on localhost, but why open
                              up a port not needed.
                            • Viktor Dukhovni
                              ... Perhaps Postfix could benefit from a DNS_README.html, with examples tuning a local cache for MX overrides, RBLDNSD integration using an internal RBL zone,
                              Message 14 of 25 , Feb 27, 2013
                              • 0 Attachment
                                On Wed, Feb 27, 2013 at 05:47:28PM +0100, Reindl Harald wrote:

                                > ... more DNS related suggestions ...

                                Perhaps Postfix could benefit from a DNS_README.html, with examples
                                tuning a local cache for MX overrides, RBLDNSD integration using
                                an internal RBL zone, DNSSEC support, and any other DNS-related
                                best-practices for an MTA.

                                Anyone care to volunteer an initial draft? Use one of the existing
                                documents in the "proto/" directory of the Postfix source distribution
                                as a starting point.

                                --
                                Viktor.
                              • DTNX Postmaster
                                ... Review the examples given again, please. Why would you need to firewall a local nameserver that ONLY listens on the localhost interface? Cya, Jona
                                Message 15 of 25 , Feb 27, 2013
                                • 0 Attachment
                                  On Feb 27, 2013, at 18:05, Robert Moskowitz <rgm@...> wrote:

                                  > Another tidbit is you should firewall access to port 53. Your caching server is only for you. It is listening only on localhost, but why open up a port not needed.

                                  Review the examples given again, please. Why would you need to firewall
                                  a local nameserver that ONLY listens on the localhost interface?

                                  Cya,
                                  Jona
                                • Robert Moskowitz
                                  ... I would hope you are running local firewall, and only opening what is needed. Just pointing out that there is no need to open port 53 as it is only used
                                  Message 16 of 25 , Feb 27, 2013
                                  • 0 Attachment
                                    On 02/27/2013 12:26 PM, DTNX Postmaster wrote:
                                    > On Feb 27, 2013, at 18:05, Robert Moskowitz <rgm@...> wrote:
                                    >
                                    >> Another tidbit is you should firewall access to port 53. Your caching server is only for you. It is listening only on localhost, but why open up a port not needed.
                                    > Review the examples given again, please. Why would you need to firewall
                                    > a local nameserver that ONLY listens on the localhost interface?

                                    I would hope you are running local firewall, and only opening what is
                                    needed. Just pointing out that there is no need to open port 53 as it
                                    is only used local.

                                    Also about chroot. Only needed if you disable selinux.
                                  Your message has been successfully submitted and would be delivered to recipients shortly.