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

Running namecache service on postfix server?

Expand Messages
  • Robert Moskowitz
    I have recently updated my DNS server and am observing the traffic from my mail server to constantly query for names. Some of these names are frequent
    Message 1 of 25 , Feb 26, 2013
    • 0 Attachment
      I have recently updated my DNS server and am observing the traffic from
      my mail server to constantly query for names. Some of these names are
      frequent requests, for example: zen.spamhaus.org. So I was thinking
      that I could benefit from running a namecaching setup on my mail server
      platform. This would cut down on traffic and time on my mail server.

      Is this a practice that is common? Are there any downsizes to doing this?
    • Reindl Harald
      ... virtually anybody with a large mail/connection traffic has a chaching nameserver on his mailservers running, it is common practice
      Message 2 of 25 , Feb 26, 2013
      • 0 Attachment
        Am 26.02.2013 15:58, schrieb Robert Moskowitz:
        > I have recently updated my DNS server and am observing the traffic from my mail server to constantly query for
        > names. Some of these names are frequent requests, for example: zen.spamhaus.org. So I was thinking that I could
        > benefit from running a namecaching setup on my mail server platform. This would cut down on traffic and time on my
        > mail server.
        >
        > Is this a practice that is common? Are there any downsizes to doing this?

        virtually anybody with a large mail/connection traffic has a chaching
        nameserver on his mailservers running, it is common practice
      • Robert Moskowitz
        ... thanks. One more piece learned.
        Message 3 of 25 , Feb 26, 2013
        • 0 Attachment
          On 02/26/2013 10:10 AM, Reindl Harald wrote:
          >
          > Am 26.02.2013 15:58, schrieb Robert Moskowitz:
          >> I have recently updated my DNS server and am observing the traffic from my mail server to constantly query for
          >> names. Some of these names are frequent requests, for example: zen.spamhaus.org. So I was thinking that I could
          >> benefit from running a namecaching setup on my mail server platform. This would cut down on traffic and time on my
          >> mail server.
          >>
          >> Is this a practice that is common? Are there any downsizes to doing this?
          > virtually anybody with a large mail/connection traffic has a chaching
          > nameserver on his mailservers running, it is common practice
          >
          thanks. One more piece learned.
        • Viktor Dukhovni
          ... When Postfix support for DANE (RFC 6698) is introduced, there will be a requirement to operate a local nameserver that is DNSSEC aware on any machine that
          Message 4 of 25 , Feb 26, 2013
          • 0 Attachment
            On Tue, Feb 26, 2013 at 09:58:54AM -0500, Robert Moskowitz wrote:

            > I have recently updated my DNS server and am observing the traffic
            > from my mail server to constantly query for names. Some of these
            > names are frequent requests, for example: zen.spamhaus.org. So I
            > was thinking that I could benefit from running a namecaching setup
            > on my mail server platform. This would cut down on traffic and time
            > on my mail server.
            >
            > Is this a practice that is common? Are there any downsizes to doing this?

            When Postfix support for DANE (RFC 6698) is introduced, there will
            be a requirement to operate a local nameserver that is DNSSEC aware
            on any machine that wants to take advantage of peer certificate details
            published via DNSSEC to scalably deliver verified TLS email to many
            sites without the overhead of local per-site configuration.

            Consider not only deploying a local cache, but also making sure
            that it is DNSSEC aware. I recommend "unbound" from nlnetlabs.nl.
            Of course you don't have to use DANE and TLS, but you still benefit
            from a local cache regardless.

            Setting up DNSSEC on a local unbound cache that forwards all queries
            to an upstream server boils down to:

            /etc/unbound/unbound.conf
            server:
            ... other server settings ...
            #
            # Local (non-public) cache listens only on the loopback interface.
            #
            interface: 127.0.0.1
            interface: ::1
            access-control: 127.0.0.1 allow
            access-control: ::1 allow
            #
            # Enable internal non-DNSSEC RFC 1918 nets.
            #
            local-zone: "10.in-addr.arpa." nodefault
            domain-insecure: "10.in-addr.arpa."
            #
            local-zone: "16.172.in-addr.arpa." nodefault
            domain-insecure: "16.172.in-addr.arpa."
            #
            local-zone: "17.172.in-addr.arpa." nodefault
            domain-insecure: "17.172.in-addr.arpa."
            ...
            #
            local-zone: "30.172.in-addr.arpa." nodefault
            domain-insecure: "30.172.in-addr.arpa."
            #
            local-zone: "31.172.in-addr.arpa." nodefault
            domain-insecure: "31.172.in-addr.arpa."
            #
            local-zone: "168.192.in-addr.arpa." nodefault
            domain-insecure: "168.192.in-addr.arpa."
            #
            # Internal domains may map to private addresses,
            # and may not be DNSSEC signed.
            #
            private-domain: "example.com."
            domain-insecure: "example.com."

            #
            # root zone key fingerprint, get your copy from a trusted source.
            # AND update it from time to time if and when the root zone key is
            # updated.
            #
            trust-anchor: ". IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5"

            # Forward all requests to upstream server at 192.0.2.1
            # This server must not forward queries for internal
            # names (forward or reverse) to the public internet.
            #
            forward-zone:
            name: "."
            forward-addr: "192.0.2.1"

            --
            Viktor.
          • DTNX Postmaster
            ... Another advantage of a local cache is that you can intercept or redirect DNS queries. We have a dedicated zone for our own DNS blacklist, for example, that
            Message 5 of 25 , Feb 26, 2013
            • 0 Attachment
              On Feb 26, 2013, at 17:51, Viktor Dukhovni <postfix-users@...> wrote:

              > On Tue, Feb 26, 2013 at 09:58:54AM -0500, Robert Moskowitz wrote:
              >
              >> I have recently updated my DNS server and am observing the traffic
              >> from my mail server to constantly query for names. Some of these
              >> names are frequent requests, for example: zen.spamhaus.org. So I
              >> was thinking that I could benefit from running a namecaching setup
              >> on my mail server platform. This would cut down on traffic and time
              >> on my mail server.
              >>
              >> Is this a practice that is common? Are there any downsizes to doing this?
              >
              > When Postfix support for DANE (RFC 6698) is introduced, there will
              > be a requirement to operate a local nameserver that is DNSSEC aware
              > on any machine that wants to take advantage of peer certificate details
              > published via DNSSEC to scalably deliver verified TLS email to many
              > sites without the overhead of local per-site configuration.
              >
              > Consider not only deploying a local cache, but also making sure
              > that it is DNSSEC aware. I recommend "unbound" from nlnetlabs.nl.
              > Of course you don't have to use DANE and TLS, but you still benefit
              > from a local cache regardless.

              Another advantage of a local cache is that you can intercept or
              redirect DNS queries. We have a dedicated zone for our own DNS
              blacklist, for example, that redirects to rbldnsd on a different port.
              Postfix (and postscreen) query this local blacklist via DNS, just like
              they would with Spamhaus blacklists, the BRBL etc.

              We currently use BIND, but would recommend Unbound as well, that's what
              we'll be moving towards for DNSSEC support.

              HTH,
              Jona
            • btb@...
              ... why must the nameserver be local? i gather the point is to be able to trust the dns responses, which of course goes without saying - but there are methods
              Message 6 of 25 , Feb 26, 2013
              • 0 Attachment
                On Feb 26, 2013, at 11.51, Viktor Dukhovni <postfix-users@...> wrote:

                > On Tue, Feb 26, 2013 at 09:58:54AM -0500, Robert Moskowitz wrote:
                >
                >> I have recently updated my DNS server and am observing the traffic
                >> from my mail server to constantly query for names. Some of these
                >> names are frequent requests, for example: zen.spamhaus.org. So I
                >> was thinking that I could benefit from running a namecaching setup
                >> on my mail server platform. This would cut down on traffic and time
                >> on my mail server.
                >>
                >> Is this a practice that is common? Are there any downsizes to doing this?
                >
                > When Postfix support for DANE (RFC 6698) is introduced, there will
                > be a requirement to operate a local nameserver that is DNSSEC aware
                > on any machine that wants to take advantage of peer certificate details
                > published via DNSSEC to scalably deliver verified TLS email to many
                > sites without the overhead of local per-site configuration.

                why must the nameserver be local? i gather the point is to be able to trust the dns responses, which of course goes without saying - but there are methods for accomplishing this in scenarios with a non local nameserver, aren't there? i think rfc 6698 speaks to this briefly?

                -ben
              • Robert Moskowitz
                ... I don t think there is a MUST there in the IETF tradition. More of a SHOULD; I think it is a matter of performance, and perhaps security (I would have to
                Message 7 of 25 , Feb 26, 2013
                • 0 Attachment
                  On 02/26/2013 08:57 PM, btb@... wrote:
                  > On Feb 26, 2013, at 11.51, Viktor Dukhovni <postfix-users@...> wrote:
                  >
                  >> On Tue, Feb 26, 2013 at 09:58:54AM -0500, Robert Moskowitz wrote:
                  >>
                  >>> I have recently updated my DNS server and am observing the traffic
                  >>> from my mail server to constantly query for names. Some of these
                  >>> names are frequent requests, for example: zen.spamhaus.org. So I
                  >>> was thinking that I could benefit from running a namecaching setup
                  >>> on my mail server platform. This would cut down on traffic and time
                  >>> on my mail server.
                  >>>
                  >>> Is this a practice that is common? Are there any downsizes to doing this?
                  >> When Postfix support for DANE (RFC 6698) is introduced, there will
                  >> be a requirement to operate a local nameserver that is DNSSEC aware
                  >> on any machine that wants to take advantage of peer certificate details
                  >> published via DNSSEC to scalably deliver verified TLS email to many
                  >> sites without the overhead of local per-site configuration.
                  > why must the nameserver be local? i gather the point is to be able to trust the dns responses, which of course goes without saying - but there are methods for accomplishing this in scenarios with a non local nameserver, aren't there? i think rfc 6698 speaks to this briefly?

                  I don't think there is a MUST there in the IETF tradition. More of a
                  SHOULD; I think it is a matter of performance, and perhaps security (I
                  would have to net it out; definitely less 'room' for a MITM). I suspect
                  people with experience in this area (mine is elsewhere in the IETF and
                  IEEE 802) can well list the advantages of 'co-location'.
                • Viktor Dukhovni
                  ... Very easy. If the server is *not* local, you should not trust the AD-bit in its responses without authenticating the nameserver via something like TSIG. I
                  Message 8 of 25 , Feb 26, 2013
                  • 0 Attachment
                    On Tue, Feb 26, 2013 at 08:57:51PM -0500, btb@... wrote:

                    > > When Postfix support for DANE (RFC 6698) is introduced, there will
                    > > be a requirement to operate a local nameserver that is DNSSEC aware
                    > > on any machine that wants to take advantage of peer certificate details
                    > > published via DNSSEC to scalably deliver verified TLS email to many
                    > > sites without the overhead of local per-site configuration.
                    >
                    > Why must the nameserver be local?

                    Very easy. If the server is *not* local, you should not trust the
                    AD-bit in its responses without authenticating the nameserver via
                    something like TSIG.

                    I am not going to bloat Postfix with TSIG support, this would be
                    really silly, when a local cache can take care of that. A fortiori
                    I am not going to bloat Postfix with its own RRSIG-validing DNSSEC
                    support. Therefore, Postfix support for DANE will be sensibly
                    predicated on a *local* DNSSEC verifying cache.

                    Unless we add code to check that the resolv.conf in fact only
                    contains local servers (I am disinclined to do that also), you will
                    be able to "break the warranty" and trust the AD-bit from non-local
                    nameservers by telling Postfix to enable DANE even with a resolv.conf
                    that points to remote servers. If you do that, you only have yourself
                    to blame when lack of TSIG, ... makes it possible to MITM your
                    server's ostensibly "secure" email deliveries.

                    All, I can say (and will say in the documentation) is that you've
                    been warned. Since the fields of "_res" other than "_res.options"
                    are not generally documented, there is no reasonable way to perform
                    a run-time check that the configured nameservers consist of just
                    127.0.0.1 and/or ::1. So the plan is to document the warning clearly
                    in all the relevant documents, and leave the rest to the administrator's
                    ability to restrain himself from folly.

                    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).

                    --
                    Viktor.
                  • Robert Moskowitz
                    ... Ah, thought there was a MITM lurking around the corner if DNS server not local. Thank you for the details. ... I had to add listen on the server s IP
                    Message 9 of 25 , Feb 27, 2013
                    • 0 Attachment
                      On 02/27/2013 01:21 AM, Viktor Dukhovni wrote:
                      > On Tue, Feb 26, 2013 at 08:57:51PM -0500, btb@... wrote:
                      >
                      >>> When Postfix support for DANE (RFC 6698) is introduced, there will
                      >>> be a requirement to operate a local nameserver that is DNSSEC aware
                      >>> on any machine that wants to take advantage of peer certificate details
                      >>> published via DNSSEC to scalably deliver verified TLS email to many
                      >>> sites without the overhead of local per-site configuration.
                      >> Why must the nameserver be local?
                      > Very easy. If the server is *not* local, you should not trust the
                      > AD-bit in its responses without authenticating the nameserver via
                      > something like TSIG.
                      >
                      > I am not going to bloat Postfix with TSIG support, this would be
                      > really silly, when a local cache can take care of that. A fortiori
                      > I am not going to bloat Postfix with its own RRSIG-validing DNSSEC
                      > support. Therefore, Postfix support for DANE will be sensibly
                      > predicated on a *local* DNSSEC verifying cache.
                      >
                      > Unless we add code to check that the resolv.conf in fact only
                      > contains local servers (I am disinclined to do that also), you will
                      > be able to "break the warranty" and trust the AD-bit from non-local
                      > nameservers by telling Postfix to enable DANE even with a resolv.conf
                      > that points to remote servers. If you do that, you only have yourself
                      > to blame when lack of TSIG, ... makes it possible to MITM your
                      > server's ostensibly "secure" email deliveries.

                      Ah, thought there was a MITM lurking around the corner if DNS server not
                      local. Thank you for the details.

                      > All, I can say (and will say in the documentation) is that you've
                      > been warned. Since the fields of "_res" other than "_res.options"
                      > are not generally documented, there is no reasonable way to perform
                      > a run-time check that the configured nameservers consist of just
                      > 127.0.0.1 and/or ::1.

                      I had to add listen on the server's IP addresses. Some services require
                      that.

                      > So the plan is to document the warning clearly
                      > in all the relevant documents, and leave the rest to the administrator's
                      > ability to restrain himself from folly.
                      >
                      > 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).

                      My main DNS server is no longer chrooted, as selinux is claimed to be
                      better protection. And people better at OS security than I have vetted it.

                      But with this, I realize that I have had to turn off selinux on my mail
                      server. Or rather I have not found selinux assistance for all the
                      services needed on a mail server that 'does it all'. Therefore got to
                      add chroot for bind.
                    • 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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.