Re: zone transfer delay

[project722]

Yes, I seem to be learning that the hard way:) My shop is still on Bind
9.8.2 (Red Hat) on our authoritative servers. These new features in 9.11
are nice!

On Fri, Sep 21, 2018 at 4:29 PM Reindl Harald 
wrote:

>
> Am 21.09.18 um 20:01 schrieb project722:
> > Are you saying do a zone xfer then check the slave with the commands
> > above to see what it actaully returns? Instead of checking the file
> > itself? Sounds like to me you are saying that the server would return
> > the updated data, because its in the journal file, regardless of whether
> > its made it into the regular zone file yet. Is that a correct assumption?
>
> surely!
>
> how do you come to the idea to look at zone files instead use "dig"?
> on most setups the slave zones are even not human readable these days
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: zone transfer delay

[project722]

Ok, is this something new to the later BIND versions? I'm looking on our
authoritative servers running the red hat bind 9.8.2 and do not see any
.jnl files.

Also, I made a zone transfer and ran a dig axfr rpz-local @ipaddress and it
returned the updated data, while the file remained unchanged. (for now)

On Fri, Sep 21, 2018 at 1:28 PM Tony Finch  wrote:

> project722  wrote:
>
> > Sounds like to me you are saying that the server would return the updated
> > data, because its in the journal file, regardless of whether its made it
> > into the regular zone file yet.
>
> Yes, that's how it works.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> South Fitzroy: Variable 4. Moderate or rough. Fog patches. Moderate,
> occasionally very poor.
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: zone transfer delay

[project722]

Are you saying do a zone xfer then check the slave with the commands above
to see what it actaully returns? Instead of checking the file itself?
Sounds like to me you are saying that the server would return the updated
data, because its in the journal file, regardless of whether its made it
into the regular zone file yet. Is that a correct assumption?

On Fri, Sep 21, 2018 at 12:05 PM Tony Finch  wrote:

> project722  wrote:
>
> > But the slave still takes @15 minutes for the new data to get populated
> > in the file.
>
> Use `dig axfr` or `named-compilezone -j` to get the server's view of the
> zone. Zone updates are written to a journal and are not incorporated into
> the zone file immediately.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> fight poverty, oppression, hunger, ignorance, disease, and aggression
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: zone transfer delay

[project722]

I've added those 2 lines to the master in the zone info section. It seemed
to have helped with the delay with the server announcing the change and
initiating the xfer-out. But the slave still takes @15 minutes for the new
data to get populated in the file.

On Fri, Sep 21, 2018 at 9:09 AM Reindl Harald 
wrote:

>
>
> Am 21.09.18 um 16:05 schrieb project722:
> > Then, on the "slave", it takes about 15 minutes for the file to actaully
> > update with the new info from the time of the xfer-in. I've tried adding
> > NS records for the slave in the zone file and doing some things with
> > notify, but nothing seems to help. I'd like the changes to be almost
> > instantaneous from the time I run the rndc relaod. Here is the config
> > from the "master"
>
> we have this on all our nameserver-pairs for years and it works perfect
>
> notify explicit;
> also-notify {ip-of-slave;};
>
> also make soure you always increase the zone-serial
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

zone transfer delay

[project722]

I've got two recursive dns servers running ISC 9.11 and 9.12. We are using
RPZ and I have a whitelist/blacklist exception zone file on both servers. I
need the ability to change it only on one server and have it propogate to
the other servers. My config is working, but I'm getting some delays that
i'd like to eliminate. First off, on the "master" server, when I update the
rpz-local file and run a rndc reload, it takes about 2 minutes before I see
the xfer-out in the logs. On the "slave", I also see the xfer-in at the
same time. There are no errors, just that kickoff delay.

Then, on the "slave", it takes about 15 minutes for the file to actaully
update with the new info from the time of the xfer-in. I've tried adding NS
records for the slave in the zone file and doing some things with notify,
but nothing seems to help. I'd like the changes to be almost instantaneous
from the time I run the rndc relaod. Here is the config from the "master".

/etc/named.conf
acl RPZ {
192.168.1.100;
};

zone "rpz-local" {
type master;
file "db.rpz-local";
allow-transfer { localhost; RPZ; };
allow-query { localhost; RPZ; };
};

zone file:
$TTL 150

@IN SOA  localhost. need.to.know.only. (
   201707314 ; Serial number
   10; Refresh every 10 seconds
   10; Retry every 30 seconds
   432000; Expire in 5 days
   60 )  ; negative caching ttl 1 minute

IN NSns1master.example.com
IN NSns2slave.example.com

;# ---
;# Whitelist entries using rpz-passthru
;# ---

deteque.comIN CNAME rpz-passthru.
*.deteque.comIN CNAME rpz-passthru.


Here is the config from the slave:

/etc/named.conf
acl RPZ {
192.168.1.101;
};

zone "rpz-local" {
type slave;
file "db.rpz-local";
masters { 192.168.1.101; };
allow-transfer { localhost; RPZ; };
masterfile-format text;
allow-query { localhost; RPZ; };
};
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec KSK rollover

[project722]

Actually I have one more question just to make sure I'm not overlooking
anything for the KSK rollover. The instructions here:

https://www.icann.org/dns-resolvers-checking-current-trust-anchors

say that I need to, in addition to setting validation to "auto" run:

rndc secroots.

Well, I did that and it created the named.secroots file with the correct
contents:

secure roots as of 23-Aug-2018 17:27:15.420:

 Start view _default
   Secure roots:

./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed

   Negative trust anchors:

Does BIND automatically know to use this file or do I need to point
named.conf to it? Do I even need this file at all?


On Thu, Aug 23, 2018 at 9:43 AM project722  wrote:

> Thanks Tony! This was very helpful.
>
> On Thu, Aug 23, 2018 at 8:01 AM Tony Finch  wrote:
>
>> project722  wrote:
>> >
>> > 1) I am still seeing the "no valid signature found" messages in my
>> > bind.log.
>>
>> > ;; validating ncentral.teklinks.com/A: no valid signature found
>>
>> In this case that's because ncentral.teklinks.com is signed but there's
>> no
>> DS in the parent zone, so it's insecure. If you run delv +vtrace you'll
>> see a lot of verbiage between these lines which is the major clue.
>>
>> ;; validating teklinks.com/DS: attempting negative response validation
>>
>> ;; validating teklinks.com/DS: nonexistence proof(s) found
>>
>> Or you can look at dnsviz.net :-)
>>
>> > 2) There is one other scenario that confuses me. When I test against a
>> URL
>> > that's purposely setup to fail dnssec, I get a servfail.
>>
>> dnssec-failed.org has DS records, so it should be secure, but the DS
>> records in the parent don't match the DNSKEY records in the child zone.
>> You can see this by comparing:
>>
>> $ dig +noall +answer dnssec-failed.org ds
>>
>> $ dig +cd dnssec-failed.org dnskey |
>>   dnssec-dsfromkey -f /dev/stdin dnssec-failed.org
>>
>> Tony.
>> --
>> f.anthony.n.finchhttp://dotat.at/
>> protect and enlarge the conditions of liberty and social justice
>>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec KSK rollover

[project722]

Thanks Tony! This was very helpful.

On Thu, Aug 23, 2018 at 8:01 AM Tony Finch  wrote:

> project722  wrote:
> >
> > 1) I am still seeing the "no valid signature found" messages in my
> > bind.log.
>
> > ;; validating ncentral.teklinks.com/A: no valid signature found
>
> In this case that's because ncentral.teklinks.com is signed but there's no
> DS in the parent zone, so it's insecure. If you run delv +vtrace you'll
> see a lot of verbiage between these lines which is the major clue.
>
> ;; validating teklinks.com/DS: attempting negative response validation
>
> ;; validating teklinks.com/DS: nonexistence proof(s) found
>
> Or you can look at dnsviz.net :-)
>
> > 2) There is one other scenario that confuses me. When I test against a
> URL
> > that's purposely setup to fail dnssec, I get a servfail.
>
> dnssec-failed.org has DS records, so it should be secure, but the DS
> records in the parent don't match the DNSKEY records in the child zone.
> You can see this by comparing:
>
> $ dig +noall +answer dnssec-failed.org ds
>
> $ dig +cd dnssec-failed.org dnskey |
>   dnssec-dsfromkey -f /dev/stdin dnssec-failed.org
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> protect and enlarge the conditions of liberty and social justice
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec KSK rollover

[project722]

Hi Tony,

I've removed the config for managed keys out of my named.conf, moved any
files called bind.keys out from my named working directory, and restarted
Bind. I see where Bind created to files - managed-keys.bind and
managed-keys.bind.jnl. So, I think I'm on the right track. That said, two
things:

1) I am still seeing the "no valid signature found" messages in my
bind.log. However, **I don't think* * this is a problem because when I
query a hostname against my server that produces one of these errors, it
still resolves. for instance,

# root@fccore 07:01:07 0 jobs ~ > delv @x.x.x.x ncentral.teklinks.com A
+multiline +rtrace
;; fetch: ncentral.teklinks.com/A
;; fetch: teklinks.com/DNSKEY
;; fetch: teklinks.com/DS
;; fetch: com/DNSKEY
;; fetch: com/DS
;; fetch: ./DNSKEY
;; fetch: teklinks.com.dlv.isc.org/DLV
;; fetch: dlv.isc.org/DNSKEY
;; validating ncentral.teklinks.com/A: no valid signature found
; unsigned answer
ncentral.teklinks.com.2482 INA 104.245.194.14
ncentral.teklinks.com.2482 INRRSIG A 5 3 43200 (
20180915012340 20180816012340 46266 teklinks.com.
k2Q0WFrwuC8ouvapXp8XIgTznwJ3VS1Ag+b8/8ajSKBe
6qLal+hYqc96WmIfYvz1fkM5Oze+WXZifeohO7ZEwlLn
8RJCXlGEEtgZ6Phr44fBbjHg7wAGxaG0KLw3JNJJVDWq
48/sB7Qftat8Hp1M/56qi6OjI22bbyBA8nYQ03kc84c6
MjCBSJfrum78AJXMFD69wXERDz6GCcaLgL3jJlIH9vZg
mB5EquQtZmxU/6izQJGqZs3Ht+3NkhcKYnqpRFyHrEmo
VPqiuEBmGhVyJJChLpbLvOwFvjTZEaedoMXv5pQ8Ys9d
sg4y1gokR+HXkeTKHr8RWayElh8gu5QKoQ== )


So, I can see here that it still resolves BUT something fails to validate a
signature. Where is the breakdown here? It was able to fetch the DHSKEY for
teklinks.com:

;; fetch: teklinks.com/DNSKEY

but not ncentral.teklinks.com:

;; validating ncentral.teklinks.com/A: no valid signature found

Shouldn't this validate? I mean, if teklinks.com can validate, shouldn't
the stub "ncentral" as well, since its in the zonefile? What am I missing
here?



2) There is one other scenario that confuses me. When I test against a URL
that's purposely setup to fail dnssec, I get a servfail.

root@fccore 07:14:57 0 jobs ~ > delv @x.x.x.x www.dnssec-failed.org A
+multiline +rtrace
;; fetch: www.dnssec-failed.org/A
;; resolution failed: SERVFAIL

So, what's the difference here and with the scenario above in #1? My
concern is that our customers will get servfails when they try to access
sites like this one.




On Thu, Aug 23, 2018 at 6:33 AM Tony Finch  wrote:

> project722  wrote:
> >
> > In my named.conf I changed:
> >
> > dnssec-validation yes;
> >
> > to
> >
> > dnssec-validation auto;
>
> Good :-)
>
> Next thing to do is delete all trace of managed-keys or mkeys files or
> trusted-keys configuration, then restart `named`. It will automatically
> create managed-keys files with the correct contents - it has the current
> root KSKs built in, so you don't need the bind.keys file.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> South Fitzroy: Northerly or northeasterly 5 or 6. Slight or moderate.
> Occasional drizzle. Good, occasionally poor at first.
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

dnssec KSK rollover

[project722]

Hey guys,

We received an email today about one of our recursive DNS servers that did
not support the new KSK for DNSSEC.


On 11 October 2018, ICANN will change or "roll over" the DNSSEC key
signing key (KSK) of the DNS root zone. Based on information from your
network received at the DNS root name servers [1], we believe that
there may be at least one recursive resolver (also referred to as a
recursive name server or caching name server) with DNSSEC validation
enabled in AS11272 that is unprepared for the KSK rollover. If that
resolver is not updated before 11 October 2018, users of that resolver
will not be able to resolve any DNS queries, resulting in an outage
for them.
#

So, I followed the instructions here:

https://www.icann.org/dns-resolvers-updating-latest-trust-anchor

In my named.conf I changed:

dnssec-validation yes;

to

dnssec-validation auto;

I then moved my bind.keys file (which does have the latest keys) into the
named working directory. Chown'd it so that named could have group
ownership and could write to it. I then restarted named. I started seeing
these in the logs:



*dnssec: info: validating x.com : no valid signature found*


*So I tried a different approach:*






*I moved the "managed keys" section into my named.conf file. managed-keys {
. initial-key 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0="; .
initial-key 257 3 8
"AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU=";
};Restarted bind and still started seeing validation errors in the logs. *

*Can someone tell me what I am doing wrong?*
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "Jumbo" Security Release of BIND corrects four exploitable vulnerabilities.

[project722]

Is there a way to mitigate these vulnerabilities outside of updating BIND?
We use RHEL and have to wait on the official patch they provide. Our Bind
version is 9.8.2 for RHEL 6 and 9.9.4 for RHEL 7.

On Thu, Jan 12, 2017 at 9:37 AM, G.W. Haywood 
wrote:

> Hello again,
>
> On Thu, 12 Jan 2017, Andrey Fanin wrote:
>
>> On Thu, 12 Jan 2017, G.W. Haywood wrote:
>> > On Thu, 12 Jan 2017, Michael McNally wrote:
>> >
>> > > ISC has issued new security releases of BIND today [..snip..]
>> >
>> > I'm trying to get BIND 9.9.9-P5 from the downloads page, but
>> > it seems to be giving me something else...
>>
>> Looks all is correctly delivered ( all three versions of tar.gz )
>> from my side ( UA )
>>
>
> Maybe it makes a difference that I'm in England, and using IPv6?
>
> laptop3:~$ >>> wget https://www.isc.org/downloads/
> file/bind-9-9-10b1/?version=tar-gz -O bind.tgz
> --2017-01-12 15:16:37--  https://www.isc.org/downloads/
> file/bind-9-9-10b1/?version=tar-gz
> Resolving www.isc.org (www.isc.org)... 2001:4f8:0:2::69, 149.20.64.69
> Connecting to www.isc.org (www.isc.org)|2001:4f8:0:2::69|:443...
> connected.
> HTTP request sent, awaiting response... 200 OK
> Length: unspecified [application/x-gzip]
> Saving to: ‘bind.tgz’
>
> bind.tgz  [.=>...]   8.98M  89.5KB/s   in 71s
>
> 2017-01-12 15:17:50 (129 KB/s) - ‘bind.tgz’ saved [9414022]
>
> laptop3:~$ >>> tar tzvf bind.tgz | head
> drwxr-xr-x each/wheel0 2016-12-29 22:25 bind-9.10.5b1/
> -rw-r--r-- each/wheel   52 2016-12-29 22:22
> bind-9.10.5b1/.gitattributes
> -rw-r--r-- each/wheel   14 2016-12-29 22:25 bind-9.10.5b1/srcid
> -rw-r--r-- each/wheel   88 2016-12-29 22:22 bind-9.10.5b1/Atffile
> -rw-r--r-- each/wheel   479504 2016-12-29 22:22 bind-9.10.5b1/CHANGES
> -rw-r--r-- each/wheel27137 2016-12-29 22:22 bind-9.10.5b1/COPYRIGHT
> -rw-r--r-- each/wheel33543 2016-12-29 22:22 bind-9.10.5b1/FAQ
> -rw-r--r-- each/wheel45917 2016-12-29 22:22 bind-9.10.5b1/FAQ.xml
> -rw-r--r-- each/wheel12791 2016-12-29 22:22 bind-9.10.5b1/HISTORY
> -rw-r--r-- each/wheel 3609 2016-12-29 22:22 bind-9.10.5b1/Makefile.in
>
> --
>
> 73,
> Ged.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dig +trace = Bad Referral orBad Horizontal referral

[project722]

I've reverted my configuration back to before we started using views. But,
if this was a delegation issue, wouldn't we expect to see it regardless of
using views or not? Works fine without views.

On Tue, Sep 20, 2016 at 8:58 AM, Matthew Pounsett <m...@conundrum.com>
wrote:

>
>
> On 16 September 2016 at 11:12, project722 <project...@gmail.com> wrote:
>
>> I have an interesting problem. I started noticing that when I do a dig
>> +trace against one of the domains we are authoritative for, we get errors
>> from our nameservers for "Bad Referral" and you can see where it forwarded
>> the request back up the namespace tree instead of giving the answer.
>> Unfortunately I am unable to reproduce this problem at the moment. However
>> I can reproduce the Bad (HORIZONTAL) referral. Basically once the query is
>> referred to our name server I see this:
>>
>> ;; BAD (HORIZONTAL) REFERRAL
>> ;; Received 187 bytes from x.x.x.x#53(ns.example.com in 2 ms
>>
>
> A horizontal referral is when one authoritative zone (the parent)
> delegates a subdomain to a server that responds out of the same parent
> zone, rather than a subzone.  The DNS is an inverted tree structure, and
> delegations are always supposed to be "down" the tree toward the leaves.
> If a delegation ends up being across, then you get a horizontal referral
> error.
>
> Since you obfuscated your configuration nobody is going to be able to
> provide you with specific advice on where the problem is.  If you can find
> the error in your authoritative data (or share which zone is giving you
> problems so that someone here can point it out) that should clear up your
> issue.
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

dig +trace = Bad Referral orBad Horizontal referral

[project722]

I have an interesting problem. I started noticing that when I do a dig
+trace against one of the domains we are authoritative for, we get errors
from our nameservers for "Bad Referral" and you can see where it forwarded
the request back up the namespace tree instead of giving the answer.
Unfortunately I am unable to reproduce this problem at the moment. However
I can reproduce the Bad (HORIZONTAL) referral. Basically once the query is
referred to our name server I see this:

;; BAD (HORIZONTAL) REFERRAL
;; Received 187 bytes from x.x.x.x#53(ns.example.com in 2 ms

Sometimes this loops until I reach the "too many lookups" error and it just
gives up, or it will stop and try our other server which then gets an
answer. Here's the interesting part. If I was to perform a simple dig A
lookup against the server that continusouly failed the trace, I get an
answer and a correct one. If I then turn around and do the dig +trace
against that same query again *it never fails again.* Its almost like
records are being cached somewhere and after it expires, then you will
start to see the message again. Can anyone help me figure out what id going
on here? Here is info about our environment.

1)RHEL 6 running BIND 9.8.2
2)Public facing auhtoritative Master and Slave Server."
3)Servers are setup in a "view" configuration. (dual-view - one for
"internal" one for external)
4)It seems like we just started to see these oddities after implementing
views.
5)Queries that hit the internal view are forwarded to the external view for
zones not contained in the internal view. We use the loopback IP to acheive
this.
6) These authoritative servers are also setup to answer non-authoritative
queries with recusrion through the use of the recusion statement and root
"hint" zone.

Here is our setup simplified.

Master server:

acl ext_trusted {
x.x.x.x; // trusted net external
}; // end of "ext_trusted" ACL definition.

ccl int_trusted {
x.x.x.x; // trusted internal
}; // end of ACL for "int_trusted"


options {
directory "/var/named";
recursive-clients 3;
tcp-clients 2000;
check-names master ignore;
dump-file   "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named.stats.txt";
memstatistics-file "/var/named/data/named_mem/stats.txt";
zone-statistics yes;
cleaning-interval 30;


// Listen on ipv4: // Adding localhost for view forwarding
listen-on port 53 { x.x.x.x; 127.0.0.1; };

// And, also listen on ipv6:
// loopback is required for view forwarding do not remove
listen-on-v6 { ::1; x.x.x.x; };

// Enforce the Customer DNS Query ACL Defined Above:
allow-query { ext_trusted; int_trusted; };

// Enforce the Zone-Transfer ACL Defined Above:
// This will now be defined on a "per view" basis
//allow-transfer { other_ns; };

};


key "internal" {
 algorithm HMAC-SHA512;
secret "x";
};

key "external" {
algorithm HMAC-SHA512;
secret "";
};

 view "internal" {
match-clients { !key external; int_trusted; key internal; };

//IP of slave server
server x.x.x.x {
keys { internal; };
};

server x.x.x.x {
keys { internal; };
};

also-notify { //slave servers go here
x.x.x.x; x.x.x.x;
};

allow-transfer { key internal; local_ns; int_ns; };
empty-zones-enable no;
server fe80::/16 { bogus yes; };
server 0.0.0.0/8 {bogus yes; };

zone "example.org" {
type master;
file "db.eample.org";
allow-query { int_trusted; };
};

forwarders {
// forward to external view //
127.0.0.1; ::1;
};

forward only;

};

view "external" {
  match-clients { any; };

//IP of slave server
  server x.x.x.x {
  keys { external; };
};

  server x.x.x.x {
  keys { external; };
};

also-notify { //IP address of slave server
   x.x.x.x; x.x.x.x;
};

allow-transfer { key external; ext_ns; local_ns; };
server fe80::/16 { bogus yes; };
server 0.0.0.0/8 {bogus yes; };
empty-zones-enable yes;
recursion yes;
allow-recursion { any; };

zone "." {
 type hint;
 file "/var/named/named.ca";
};


zone "example.org" {
type master;
file "db.eampleout.org";
allow-query { any; };
};

zone "example.com" {
type master;
file "db.eample.com";
allow-query { any; };
};

};


Slave server config:


acl ext_trusted {
x.x.x.x; // trusted net external
}; // end of "ext_trusted" ACL definition.

ccl int_trusted {
x.x.x.x; // trusted internal
}; // end of ACL for "int_trusted"

options {
directory "/var/named/slaves";
recursive-clients 3;
tcp-clients 2000;
check-names master ignore;
dump-file   "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
cleaning-interval 30;

// Listen on ipv4:
// Change this to 

Re: DNS views and zone transfers, cont

[project722]

I have moved the new views into production, and all seems to be working
fine. I have an "internal" view and an "external" view. I have noticed a
few re-occuring messages in the logs of the master server that I'd like to
suppress. Here is what I am seeing:

1) Warning: view external: 'empty-zones-enable/disable-empty-zone' not set:
disabling RFC 1918 empty zones: 37 Time(s)

2) connect(fe80::216:3eff:fe37:b866#53) 22/Invalid argument: 7 Time(s)

3) zone
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA/IN/external:
(master) removed: 1 Time(s)
 zone 112/x.x.x.IN-ADDR.ARPA/IN: (master) removed: 1 Time(s)
 zone x.x.x.in-addr.arpa/IN: (master) removed: 1 Time(s)

For # 3 I basically see an entry for each of our reverse mapping zones,
which are valid and I don't want them "removed" as the message states And I
think these are related to #1. I believe I can fix #1 with the
"empty-zones-enable
no;" in my external view, but I am not sure what effect it would have on
the message generation or how it would affect zone behavior in that view.

For #2, - I already have a statement "server fe80::/16 { bogus yes; };" in
my named.conf. However it is above the options statement and I am now
wondering if I need this defined in each view now. Also this
fe80::216:3eff:fe37:b866
is not even my actual link local IP so I am not sure where/how that is
being generated. My actual link local is
fe80::f21f:afff:fedd:6a26/64

Any help is greatly appreciated.

On Thu, Sep 8, 2016 at 11:33 AM, project722 <project...@gmail.com> wrote:

> I am not seeing that but thanks for the heads up. I will keep an eye on
> it.
>
> On Thu, Sep 8, 2016 at 10:14 AM, Bob Harold <rharo...@umich.edu> wrote:
>
>> I changed the subject slightly, because I had to cut out a lot of the
>> forwarded message - the list server was complaining about the size of the
>> messages.
>>
>> I just found that my setup was not working completely as I expected.  The
>> view with only a few zones and forwarding to another view automatically got
>> the "empty zones" created, so any queries in those zones did not get
>> forwarded.  I am fixing it by adding to that view the line:
>>empty-zones-enable no;
>>
>> --
>> Bob Harold
>>
>>
>> On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold <rharo...@umich.edu> wrote:
>>
>>>
>>> On Thu, Sep 8, 2016 at 9:13 AM, project722 <project...@gmail.com> wrote:
>>>
>>>> Bob, in our prod environment, we are allowing 127.0.0.1 to make zone
>>>> transfers. First off, what is the reasoning or benefit of allowing
>>>> localhost to make zone transfers? Secondly, In my new view config since I
>>>> will be using 127.0.0.1 as a forwarder, would this in any way cause a
>>>> problem or a conflict if I was to leave the localhost IP in the ACL for
>>>> zone transfers?
>>>>
>>>
>>> I would allow 127.0.0.1 to do zone transfers for troubleshooting
>>> purposes, if I am on the server and want to look at a whole zone.  But it
>>> is not required, if you don't use it for transfers.
>>> Allowing zone transfers should not affect its use for forwarding, as far
>>> as I can see.
>>>
>>> --
>>> Bob Harold
>>>
>>>
>>>
>>>> On Wed, Sep 7, 2016 at 2:30 PM, Bob Harold <rharo...@umich.edu> wrote:
>>>>
>>>>> You should change:
>>>>>   match-clients { internal; key tsigkey; !key tsigkeyext;
>>>>> To:
>>>>>   match-clients { !key tsigkeyext; internal; key tsigkey;
>>>>>
>>>>> The 'not' (!) won't work if it is last, they are checked in order, so
>>>>> it needs to be first.
>>>>>
>>>>> --
>>>>> Bob Harold
>>>>>
>>>>>
>>>>> On Wed, Sep 7, 2016 at 3:21 PM, project722 <project...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I think I have found the problem. I did not need dnssec enabled after
>>>>>> all. All this time I thought it was needed for TSIG to work. But
>>>>>> apparently, the forwarding is working, and zone transfers are going to 
>>>>>> the
>>>>>> right view without it enabled.
>>>>>>
>>>>>> On Wed, Sep 7, 2016 at 1:15 PM, project722 <project...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Ok I'm with you now. I have reconfigured my servers and I cant get
>>>>>>> the f

Re: DNS views and zone transfers, cont

[project722]

I am not seeing that but thanks for the heads up. I will keep an eye on it.

On Thu, Sep 8, 2016 at 10:14 AM, Bob Harold <rharo...@umich.edu> wrote:

> I changed the subject slightly, because I had to cut out a lot of the
> forwarded message - the list server was complaining about the size of the
> messages.
>
> I just found that my setup was not working completely as I expected.  The
> view with only a few zones and forwarding to another view automatically got
> the "empty zones" created, so any queries in those zones did not get
> forwarded.  I am fixing it by adding to that view the line:
>empty-zones-enable no;
>
> --
> Bob Harold
>
>
> On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold <rharo...@umich.edu> wrote:
>
>>
>> On Thu, Sep 8, 2016 at 9:13 AM, project722 <project...@gmail.com> wrote:
>>
>>> Bob, in our prod environment, we are allowing 127.0.0.1 to make zone
>>> transfers. First off, what is the reasoning or benefit of allowing
>>> localhost to make zone transfers? Secondly, In my new view config since I
>>> will be using 127.0.0.1 as a forwarder, would this in any way cause a
>>> problem or a conflict if I was to leave the localhost IP in the ACL for
>>> zone transfers?
>>>
>>
>> I would allow 127.0.0.1 to do zone transfers for troubleshooting
>> purposes, if I am on the server and want to look at a whole zone.  But it
>> is not required, if you don't use it for transfers.
>> Allowing zone transfers should not affect its use for forwarding, as far
>> as I can see.
>>
>> --
>> Bob Harold
>>
>>
>>
>>> On Wed, Sep 7, 2016 at 2:30 PM, Bob Harold <rharo...@umich.edu> wrote:
>>>
>>>> You should change:
>>>>   match-clients { internal; key tsigkey; !key tsigkeyext;
>>>> To:
>>>>   match-clients { !key tsigkeyext; internal; key tsigkey;
>>>>
>>>> The 'not' (!) won't work if it is last, they are checked in order, so
>>>> it needs to be first.
>>>>
>>>> --
>>>> Bob Harold
>>>>
>>>>
>>>> On Wed, Sep 7, 2016 at 3:21 PM, project722 <project...@gmail.com>
>>>> wrote:
>>>>
>>>>> I think I have found the problem. I did not need dnssec enabled after
>>>>> all. All this time I thought it was needed for TSIG to work. But
>>>>> apparently, the forwarding is working, and zone transfers are going to the
>>>>> right view without it enabled.
>>>>>
>>>>> On Wed, Sep 7, 2016 at 1:15 PM, project722 <project...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Ok I'm with you now. I have reconfigured my servers and I cant get
>>>>>> the forwarding to work. Since 127.0.0.1 is forwarding request, I made 
>>>>>> sure
>>>>>> in the options stanza to set it to a listen IP. I have tried several
>>>>>> different variations of this method and all end up with SERVFAIL's using
>>>>>> dig from a client that gets the "internal" view. Here is my config.
>>>>>>
>>>>>> acl internal {
>>>>>> 192.168.254.0/23; // corpnet
>>>>>> };
>>>>>>
>>>>>> acl external {
>>>>>> 192.168.155.0/24;
>>>>>> 192.168.160.0/24;
>>>>>> };
>>>>>>
>>>>>> options {
>>>>>> listen-on port 53 { 192.168.155.128; 127.0.0.1; }; #Master
>>>>>> DNS Servers IP
>>>>>> directory   "/var/named";
>>>>>> dump-file   "/var/named/data/cache_dump.db";
>>>>>> statistics-file "/var/named/data/named.stats";
>>>>>> memstatistics-file "/var/named/data/named_mem_stats.txt";
>>>>>> allow-query{ internal; external; };
>>>>>> dnssec-enable yes;
>>>>>> dnssec-validation auto;
>>>>>> dnssec-lookaside auto;
>>>>>> zone-statistics yes;
>>>>>>
>>>>>> /* Path to ISC DLV key */
>>>>>> bindkeys-file "/etc/named.iscdlv.key";
>>>>>>
>>>>>> managed-keys-directory "/var/named/dynamic";
>>>>>>
>>>>>> };
>>>>>>

Re: DNS views and zone transfers

[project722]

Bob, I have few questions regarding your sample config. First off it is
slightly different than mine, which does work BTW at least in a lab
environment. In your internal view what is the purpose of having this line:

 // this list must not match 127.0.0.1
!key "external";   // use this key to test the external view
10.0.0.0/8;

Why use 127.0.0.1 and what is the 10.0.0.0/8 block for? I also noticed you
did not include the external key indie the external view. Why is that?

On Wed, Sep 7, 2016 at 10:48 AM, Bob Harold <rharo...@umich.edu> wrote:

>
> On Wed, Sep 7, 2016 at 11:37 AM, project722 <project...@gmail.com> wrote:
>
>> Thanks Bob, I will look into this. Do you know if the forwarders feature
>> is supported in Bind 9.8.2?
>>
>>
> Yes, forwarders is an old and stable feature.
>
> ("in-view" is new and experimental)
>
> --
> Bob Harold
>
>
>> On Wed, Sep 7, 2016 at 9:38 AM, Bob Harold <rharo...@umich.edu> wrote:
>>
>>>
>>> On Tue, Sep 6, 2016 at 5:23 PM, project722 <project...@gmail.com> wrote:
>>>
>>>> I'm interested in the "view forwarding" method. I'm only setting up
>>>> views to resolve a split DNS issue with one domain. I'd like to have that
>>>> one zone/domain in my internal view and then if the source IP requests info
>>>> for any other zone forward that to my external view. To me this sounds like
>>>> a whole lot less work. Do you have any specifics on how I would go about
>>>> setting that up or can you point me in the direction where I can get info
>>>> on setting that up? Ideally, I'd want my "internal" clients to still find
>>>> example.com even if the internal view only had example.org in it.
>>>> Something like this but how do I incorporate the forwarding?
>>>>
>>>> view internal {
>>>>
>>>>match clients - internal;
>>>>
>>>> zone - example.org
>>>>
>>>> };
>>>>
>>>> view external {
>>>>
>>>> match clients - external {
>>>>
>>>> zone example.org {
>>>> };
>>>>
>>>> zone example.com {
>>>> };
>>>>
>>>> };
>>>>
>>>>
>>>>
>>>> On Tue, Aug 30, 2016 at 2:53 PM, Bob Harold <rharo...@umich.edu> wrote:
>>>>
>>>>>
>>>>> On Thu, Aug 25, 2016 at 12:56 PM, project722 <project...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I have successfully setup TSIG keys for "views" using a DNS
>>>>>> master/server pair. Zone transfers are working as expected between the 2
>>>>>> servers for each view. Before we go live into production with this I need
>>>>>> some clarification on a couple things. Our prod servers are also allowing
>>>>>> zone transfers to a few other servers besides the slave server. We have 
>>>>>> an
>>>>>> acl setup that looks similar to this:
>>>>>>
>>>>>> other_xfer_allowed_ns {
>>>>>> x.x.x.x; // This is our Secondary DNS server
>>>>>> 127.0.0.1; // localhost can make zone transfers
>>>>>> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
>>>>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>>>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>>>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>>>>> }; // end of "other_xfer_allowed" ACL
>>>>>>
>>>>>> And in the "allow transfer" statement we have included that ACL. My
>>>>>> question is:
>>>>>>
>>>>>> Now that we are using TSIG, will I need to get with the admins of all
>>>>>> these other servers and provide them my TSIG key so they can request zone
>>>>>> transfers? I would think somehting like that needs to be done since it 
>>>>>> was
>>>>>> required to be configured on slave server, but I am not sure.
>>>>>>
>>>>>
>>>>> No, if you allowed the IP range in your ACL, they don't need the TSIG
>>>>> key.
>>>>> It might be more secure to hand out TSIG keys and remove the IP ranges
>>>>> from the ACL, so only the TSIG key will al

Re: DNS views and zone transfers

[project722]

Thanks Bob, I will look into this. Do you know if the forwarders feature is
supported in Bind 9.8.2?

On Wed, Sep 7, 2016 at 9:38 AM, Bob Harold <rharo...@umich.edu> wrote:

>
> On Tue, Sep 6, 2016 at 5:23 PM, project722 <project...@gmail.com> wrote:
>
>> I'm interested in the "view forwarding" method. I'm only setting up views
>> to resolve a split DNS issue with one domain. I'd like to have that one
>> zone/domain in my internal view and then if the source IP requests info for
>> any other zone forward that to my external view. To me this sounds like a
>> whole lot less work. Do you have any specifics on how I would go about
>> setting that up or can you point me in the direction where I can get info
>> on setting that up? Ideally, I'd want my "internal" clients to still find
>> example.com even if the internal view only had example.org in it.
>> Something like this but how do I incorporate the forwarding?
>>
>> view internal {
>>
>>match clients - internal;
>>
>> zone - example.org
>>
>> };
>>
>> view external {
>>
>> match clients - external {
>>
>> zone example.org {
>> };
>>
>> zone example.com {
>> };
>>
>> };
>>
>>
>>
>> On Tue, Aug 30, 2016 at 2:53 PM, Bob Harold <rharo...@umich.edu> wrote:
>>
>>>
>>> On Thu, Aug 25, 2016 at 12:56 PM, project722 <project...@gmail.com>
>>> wrote:
>>>
>>>> I have successfully setup TSIG keys for "views" using a DNS
>>>> master/server pair. Zone transfers are working as expected between the 2
>>>> servers for each view. Before we go live into production with this I need
>>>> some clarification on a couple things. Our prod servers are also allowing
>>>> zone transfers to a few other servers besides the slave server. We have an
>>>> acl setup that looks similar to this:
>>>>
>>>> other_xfer_allowed_ns {
>>>> x.x.x.x; // This is our Secondary DNS server
>>>> 127.0.0.1; // localhost can make zone transfers
>>>> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
>>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>>> }; // end of "other_xfer_allowed" ACL
>>>>
>>>> And in the "allow transfer" statement we have included that ACL. My
>>>> question is:
>>>>
>>>> Now that we are using TSIG, will I need to get with the admins of all
>>>> these other servers and provide them my TSIG key so they can request zone
>>>> transfers? I would think somehting like that needs to be done since it was
>>>> required to be configured on slave server, but I am not sure.
>>>>
>>>
>>> No, if you allowed the IP range in your ACL, they don't need the TSIG
>>> key.
>>> It might be more secure to hand out TSIG keys and remove the IP ranges
>>> from the ACL, so only the TSIG key will allow transfers, since IP addresses
>>> are easier to spoof, but since a zone transfer requires TCP, spoofing is
>>> not likely.
>>>
>>> The TSIG key was required on the slave in order to get the right view,
>>> if I remember correctly.
>>>
>>>
>>>>
>>>> Next,
>>>>
>>>> I setup views so that clients on the "internal" network when requesting
>>>> a record would be presented with different records than clients on the
>>>> outside. And at the moment there is only one zone that is required to have
>>>> different records. However, It is my understanding that since views are
>>>> based off source IP's, if I was to ONLY include that one zone in my
>>>> "internal" view, if a record was requested for another zone from that same
>>>> IP, they would probably get an nxdomain answer since that IP is limited to
>>>> that one view.
>>>>
>>>> So, my question is, will I need to include all zones in both views so
>>>> that all clients can get results, even though I would only have (at the
>>>> moment) one zone that points to two different zone files? All others in
>>>> both views would point to the same zone file, unless of course there is
>>>> another zone we need to present a different view to for internal clients.
>>>>
&

Re: DNS views and zone transfers

[project722]

I'm interested in the "view forwarding" method. I'm only setting up views
to resolve a split DNS issue with one domain. I'd like to have that one
zone/domain in my internal view and then if the source IP requests info for
any other zone forward that to my external view. To me this sounds like a
whole lot less work. Do you have any specifics on how I would go about
setting that up or can you point me in the direction where I can get info
on setting that up? Ideally, I'd want my "internal" clients to still find
example.com even if the internal view only had example.org in it. Something
like this but how do I incorporate the forwarding?

view internal {

   match clients - internal;

zone - example.org

};

view external {

match clients - external {

zone example.org {
};

zone example.com {
};

};



On Tue, Aug 30, 2016 at 2:53 PM, Bob Harold <rharo...@umich.edu> wrote:

>
> On Thu, Aug 25, 2016 at 12:56 PM, project722 <project...@gmail.com> wrote:
>
>> I have successfully setup TSIG keys for "views" using a DNS master/server
>> pair. Zone transfers are working as expected between the 2 servers for each
>> view. Before we go live into production with this I need some clarification
>> on a couple things. Our prod servers are also allowing zone transfers to a
>> few other servers besides the slave server. We have an acl setup that looks
>> similar to this:
>>
>> other_xfer_allowed_ns {
>> x.x.x.x; // This is our Secondary DNS server
>> 127.0.0.1; // localhost can make zone transfers
>> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>> }; // end of "other_xfer_allowed" ACL
>>
>> And in the "allow transfer" statement we have included that ACL. My
>> question is:
>>
>> Now that we are using TSIG, will I need to get with the admins of all
>> these other servers and provide them my TSIG key so they can request zone
>> transfers? I would think somehting like that needs to be done since it was
>> required to be configured on slave server, but I am not sure.
>>
>
> No, if you allowed the IP range in your ACL, they don't need the TSIG key.
> It might be more secure to hand out TSIG keys and remove the IP ranges
> from the ACL, so only the TSIG key will allow transfers, since IP addresses
> are easier to spoof, but since a zone transfer requires TCP, spoofing is
> not likely.
>
> The TSIG key was required on the slave in order to get the right view, if
> I remember correctly.
>
>
>>
>> Next,
>>
>> I setup views so that clients on the "internal" network when requesting a
>> record would be presented with different records than clients on the
>> outside. And at the moment there is only one zone that is required to have
>> different records. However, It is my understanding that since views are
>> based off source IP's, if I was to ONLY include that one zone in my
>> "internal" view, if a record was requested for another zone from that same
>> IP, they would probably get an nxdomain answer since that IP is limited to
>> that one view.
>>
>> So, my question is, will I need to include all zones in both views so
>> that all clients can get results, even though I would only have (at the
>> moment) one zone that points to two different zone files? All others in
>> both views would point to the same zone file, unless of course there is
>> another zone we need to present a different view to for internal clients.
>>
>
> You have a few choices:
> - Copies of zones in both views.  More memory used, more zone transfers,
> but probably safest and best performance.  This is what I do.  The zones in
> the two views will need to be in separate files, if they are "slave" zones,
> otherwise Bind will get confused and complain, because it does not realize
> that two different views are trying to write the same file.
> - One view could 'forward' to the other view for zones it does not have.
> (Doubles the query logging, if you have that turned on.)
> - Views could do normal recursion for some zones if they can reach the
> servers listed in the NS records and get the info from there.
>
>
>>
>> Now, last question.
>>
>> I have a concern about the allow-query statement. On our production
>> server we have an ACL list we'll call it "trusted".
>> We have an allow query statement in the global options to only allow
>> queries from IP's in the trusted ACL. 

Re: SPF and domain keys

[project722]

Awesome, Actually one more question. If we allow folks from another domain
to send as us is there a chance anywhere in any of the email "from" headers
it would reveal the "true" domian?

eg..

folks at alphazulu send as @foxtrot.com.

Would @alphazulu.com appear anywhere in the headers?

On Mon, Aug 29, 2016 at 9:34 AM, Mike Ragusa <mrag...@gmail.com> wrote:

> Glad to help! If you need a low cost DMARC reporting service, I would
> recommend www.dmarcian.com
>
> On Mon, Aug 29, 2016 at 10:33 AM project722 <project...@gmail.com> wrote:
>
>> Thanks guys - very helpful information indeed.
>>
>> On Mon, Aug 29, 2016 at 9:08 AM, Mike Ragusa <mrag...@gmail.com> wrote:
>>
>>> Ideally it is best to use both technologies and then put DMARC on top to
>>> ensure reporting and enforcement of the policies. DKIM cryptographically
>>> signs your messages and SPF informs receiving mail servers of who is
>>> allowed to send on your behalf.  You should not think of using only one or
>>> the other as they work best together to accomplish the same goal. When
>>> utilizing DMARC on top of it all, you get the added benefit of reporting
>>> from over 200 different ISPs from around the world. In general, DKIM is
>>> first used as the authentication method and SPF as a backup.
>>>
>>> If you have a valid DKIM key, then failed SPF should not matter but if
>>> you have a failed DKIM key and SPF passes, there still may be
>>> deliverability issues to account for. If you do enable DMARC, then your
>>> DKIM and/or SPF headers must align with your domain or you will encounter
>>> deliverability issues depending on how your policies are setup. DKIM in
>>> relaxed mode allows for mail to pass the test with the same parent domain
>>> but canonicalization requires that your domains match up exactly as stated
>>> ie example.com and mail.example.com are not the same and will fail. SPF
>>> with DMARC requires two or more FROM headers (
>>> https://tools.ietf.org/html/rfc2822#section-3.6.2) match up exactly or
>>> it will fail SPF checks but without DMARC anyone listed in the sender
>>> policy can send on your behalf. While this may seem strange at first, this
>>> is to prevent people from signing up to something like google and sending
>>> on your behalf with the default google DKIM key and a wide open SPF policy.
>>>
>>> With DMARC:
>>> DKIM : headers must match domain or else fail
>>> SPF:  2 or more headers must match domain or else fail
>>>
>>> Without DMARC:
>>> DKIM: just needs to be signed by sending mail server
>>> SPF: just needs to be send from a valid sender
>>>
>>> Depending on your needs, I would recommend putting SPF in soft fail,
>>> DKIM in relaxed mode and DMARC in reporting mode only for the first 15-30
>>> days and see how your traffic looks and who is sending on your behalf. Once
>>> you have a comfortable baseline, start to tighten up your policies.
>>>
>>>
>>>
>>>
>>> On Mon, Aug 29, 2016 at 9:51 AM project722 <project...@gmail.com> wrote:
>>>
>>>> What about DKIM only? Can it be used instead of, or, as a "replacement"
>>>> for SPF? For example mails are signed with DKIM from the SMTP servers, and
>>>> the receiving servers are checking both SPF and DKIM. If the receiving
>>>> server detected a missing SPF would it allow mail through if DKIM is
>>>> present and valid? I suppose a lot of this depends on the SPF policies
>>>> enforced on the receiving side.
>>>>
>>>> On Mon, Aug 29, 2016 at 1:53 AM, Dave Warren <da...@hireahit.com>
>>>> wrote:
>>>>
>>>>> The easiest answer is: Whatever you want. Strictly speaking,
>>>>> alphazulu.com can send mail on behalf of foxtrot.com using a
>>>>> alphazulu.com DKIM selector, and that's perfectly valid under DKIM.
>>>>> However, it won't have DMARC alignment, which is becoming more and more
>>>>> important, so if alignment is relevant, you'll need to use a
>>>>> foxtrot.com selector.
>>>>>
>>>>> tl;dr: Use a foxtrot.com selector unless you simply can't.
>>>>>
>>>>> As for who generates it, it's irrelevant. The sending server will need
>>>>> the private key, your DNS records will contain the public key, but it 
>>>>> makes
>>>>> no difference if foxtrot.com creates the keys and delivers them to
>&g

Re: SPF and domain keys

[project722]

Thanks guys - very helpful information indeed.

On Mon, Aug 29, 2016 at 9:08 AM, Mike Ragusa <mrag...@gmail.com> wrote:

> Ideally it is best to use both technologies and then put DMARC on top to
> ensure reporting and enforcement of the policies. DKIM cryptographically
> signs your messages and SPF informs receiving mail servers of who is
> allowed to send on your behalf.  You should not think of using only one or
> the other as they work best together to accomplish the same goal. When
> utilizing DMARC on top of it all, you get the added benefit of reporting
> from over 200 different ISPs from around the world. In general, DKIM is
> first used as the authentication method and SPF as a backup.
>
> If you have a valid DKIM key, then failed SPF should not matter but if you
> have a failed DKIM key and SPF passes, there still may be deliverability
> issues to account for. If you do enable DMARC, then your DKIM and/or SPF
> headers must align with your domain or you will encounter deliverability
> issues depending on how your policies are setup. DKIM in relaxed mode
> allows for mail to pass the test with the same parent domain but
> canonicalization requires that your domains match up exactly as stated ie
> example.com and mail.example.com are not the same and will fail. SPF with
> DMARC requires two or more FROM headers (https://tools.ietf.org/html/
> rfc2822#section-3.6.2) match up exactly or it will fail SPF checks but
> without DMARC anyone listed in the sender policy can send on your behalf.
> While this may seem strange at first, this is to prevent people from
> signing up to something like google and sending on your behalf with the
> default google DKIM key and a wide open SPF policy.
>
> With DMARC:
> DKIM : headers must match domain or else fail
> SPF:  2 or more headers must match domain or else fail
>
> Without DMARC:
> DKIM: just needs to be signed by sending mail server
> SPF: just needs to be send from a valid sender
>
> Depending on your needs, I would recommend putting SPF in soft fail, DKIM
> in relaxed mode and DMARC in reporting mode only for the first 15-30 days
> and see how your traffic looks and who is sending on your behalf. Once you
> have a comfortable baseline, start to tighten up your policies.
>
>
>
>
> On Mon, Aug 29, 2016 at 9:51 AM project722 <project...@gmail.com> wrote:
>
>> What about DKIM only? Can it be used instead of, or, as a "replacement"
>> for SPF? For example mails are signed with DKIM from the SMTP servers, and
>> the receiving servers are checking both SPF and DKIM. If the receiving
>> server detected a missing SPF would it allow mail through if DKIM is
>> present and valid? I suppose a lot of this depends on the SPF policies
>> enforced on the receiving side.
>>
>> On Mon, Aug 29, 2016 at 1:53 AM, Dave Warren <da...@hireahit.com> wrote:
>>
>>> The easiest answer is: Whatever you want. Strictly speaking,
>>> alphazulu.com can send mail on behalf of foxtrot.com using a
>>> alphazulu.com DKIM selector, and that's perfectly valid under DKIM.
>>> However, it won't have DMARC alignment, which is becoming more and more
>>> important, so if alignment is relevant, you'll need to use a foxtrot.com
>>> selector.
>>>
>>> tl;dr: Use a foxtrot.com selector unless you simply can't.
>>>
>>> As for who generates it, it's irrelevant. The sending server will need
>>> the private key, your DNS records will contain the public key, but it makes
>>> no difference if foxtrot.com creates the keys and delivers them to the
>>> appropriate parties, or if alphazulu.com generates generates a private
>>> key and provides the alphazulu._domainkey.foxtrot.com record to
>>> foxtrot.com.
>>>
>>> Remember that you can have as many selectors as you want, don't reuse
>>> them across trust boundaries (in other words, consider that in the future,
>>> foxtrot.com and alphazulu.com may part ways, when that happens, it's
>>> ideal if you can remove the selector from your DNS (after a period of time,
>>> at least a week), such that alphazulu.com cannot continue to sign mail.
>>> It's also ideal if you don't have to update DKIM records elsewhere in your
>>> infrastructure.
>>>
>>> I hope at least some of this makes sense, but if not, ask. DKIM and
>>> DMARC are fiddly, and a lot of the DKIM advice out there isn't entirely
>>> complete now that DMARC is on the scene and DMARC builds on top of DKIM and
>>> SPF.
>>>
>>>
>>> On Sun, Aug 28, 2016, at 16:13, project722 wrote:
>>>
>>> Lets say my domain is foxtrot.

Re: SPF and domain keys

[project722]

What about DKIM only? Can it be used instead of, or, as a "replacement" for
SPF? For example mails are signed with DKIM from the SMTP servers, and the
receiving servers are checking both SPF and DKIM. If the receiving server
detected a missing SPF would it allow mail through if DKIM is present and
valid? I suppose a lot of this depends on the SPF policies enforced on the
receiving side.

On Mon, Aug 29, 2016 at 1:53 AM, Dave Warren <da...@hireahit.com> wrote:

> The easiest answer is: Whatever you want. Strictly speaking, alphazulu.com
> can send mail on behalf of foxtrot.com using a alphazulu.com DKIM
> selector, and that's perfectly valid under DKIM. However, it won't have
> DMARC alignment, which is becoming more and more important, so if alignment
> is relevant, you'll need to use a foxtrot.com selector.
>
> tl;dr: Use a foxtrot.com selector unless you simply can't.
>
> As for who generates it, it's irrelevant. The sending server will need the
> private key, your DNS records will contain the public key, but it makes no
> difference if foxtrot.com creates the keys and delivers them to the
> appropriate parties, or if alphazulu.com generates generates a private
> key and provides the alphazulu._domainkey.foxtrot.com record to
> foxtrot.com.
>
> Remember that you can have as many selectors as you want, don't reuse them
> across trust boundaries (in other words, consider that in the future,
> foxtrot.com and alphazulu.com may part ways, when that happens, it's
> ideal if you can remove the selector from your DNS (after a period of time,
> at least a week), such that alphazulu.com cannot continue to sign mail.
> It's also ideal if you don't have to update DKIM records elsewhere in your
> infrastructure.
>
> I hope at least some of this makes sense, but if not, ask. DKIM and DMARC
> are fiddly, and a lot of the DKIM advice out there isn't entirely complete
> now that DMARC is on the scene and DMARC builds on top of DKIM and SPF.
>
>
> On Sun, Aug 28, 2016, at 16:13, project722 wrote:
>
> Lets say my domain is foxtrot.com and we have SPF records for the SMTP
> servers on foxtrot.com. Now lets say I have decided I want to allow
> alphazulu.com to send mail as foxtrot.I know how to add alphazulu.com to
> the SPF but If I wanted to also use DomainKeys or DKIM to authenticate
> alphazulu.com would the keys need to be in foxtrots name or alphazulu?
> For example,
> Would I use:
>
> _domainkey.foxtrot.com.  IN TXT  "t=y\; o=~\;"
> xxx._domainkey.foxtrot.com.   IN TXT  "k=rsa\;
> p=xxx
>
> or
>
> _domainkey.alphazulu.com.  IN TXT  "t=y\; o=~\;"
> xxx._domainkey.alphazulu.com.   IN TXT  "k=rsa\;
> p=xxx
>
> Also,
> 1) Who generates the keys? Foxtrot or Alphazulu?
> 2) Would I need both SPF and keys or would keys alone be enough to
> authenticate the other domain? ( I am in a position where I would like to
> use only keys)
> 3) Which one is better to use in terms of provider checking? For example,
> are providers even checking keys as much as they are SPF?
>
> *___*
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

SPF and domain keys

[project722]

Lets say my domain is foxtrot.com and we have SPF records for the SMTP
servers on foxtrot.com. Now lets say I have decided I want to allow
alphazulu.com to send mail as foxtrot.I know how to add alphazulu.com to
the SPF but If I wanted to also use DomainKeys or DKIM to authenticate
alphazulu.com would the keys need to be in foxtrots name or alphazulu? For
example,

Would I use:

_domainkey.foxtrot.com.  IN TXT  "t=y\; o=~\;"
xxx._domainkey.foxtrot.com.   IN TXT  "k=rsa\;
p=xxx

or

_domainkey.alphazulu.com.  IN TXT  "t=y\; o=~\;"
xxx._domainkey.alphazulu.com.   IN TXT  "k=rsa\;
p=xxx

Also,
1) Who generates the keys? Foxtrot or Alphazulu?
2) Would I need both SPF and keys or would keys alone be enough to
authenticate the other domain? ( I am in a position where I would like to
use only keys)
3) Which one is better to use in terms of provider checking? For example,
are providers even checking keys as much as they are SPF?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS views TSIG and zone xfers

[project722]

Thanks Bob, that is exactly what I ended up doing. And its working great
now. You are also right about the view selection.

On Fri, Aug 26, 2016 at 3:43 PM, Bob Harold <rharo...@umich.edu> wrote:

>
> On Thu, Aug 25, 2016 at 6:25 PM, project722 <project...@gmail.com> wrote:
>
>> Actually, I got to thinking about this. The "other_allowed_ns" ACL is in
>> the global options, along with an "allow-transfer" for that ACL. So, I
>> *think* they will still be able to zone transfer via the global option
>> based on simply IP. BUT...since I have multiple views, which zones from
>> which views get sent over to these servers and how will they know how to
>> handle the info if zones from both views get sent. Would something like
>> this help:
>>
>> allow-transfer { other_allowed_ns; view "external"; };
>>
>> So they only get sent the zones from the external view?
>>
>> On Thu, Aug 25, 2016 at 5:14 PM, project722 <project...@gmail.com> wrote:
>>
>>> I have successfully setup TSIG keys for "views" using a DNS
>>> master/server pair. Zone transfers are working as expected between the 2
>>> servers for each view. Before we go live into production with this I need
>>> some clarification on a couple things. Our prod servers are also allowing
>>> zone transfers to a few other servers besides the slave server. We have an
>>> acl setup that looks similar to this:
>>>
>>>
>
>> {
>>> x.x.x.x; // This is our Secondary DNS server
>>> 127.0.0.1; // localhost can make zone transfers
>>> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>> }; // end of "other_xfer_allowed" ACL
>>>
>>> And in the "allow transfer" statement we have included that ACL. My
>>> question is:
>>>
>>> Now that we are using TSIG, will I need to get with the admins of all
>>> these other servers and provide them my TSIG key so they can request zone
>>> transfers? I would think somehting like that needs to be done since it was
>>> required to be configured on slave server, but I am not sure. I'd rather do
>>> an IP based control just for these other servers instead of TSIG but I am
>>> not sure how that would look or how to set that up in the context of my
>>> config. How can I tell my conf to NOT force these other xfer allowed
>>> servers to use TSIG and use IP only? This gets complicated when you start
>>> throwing views into the mix.
>>>
>>> acl internal {
>>> 192.168.200.0/24; // corpnet
>>> };
>>>
>>> acl external {
>>> 192.168.201.0/24;
>>> 192.168.202.0/24;
>>> };
>>>
>>>
>>>  other_xfer_allowed_ns {
>>> x.x.x.x; // This is our Secondary DNS server
>>> 127.0.0.1; // localhost can make zone transfers
>>> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>> }; // end of "other_xfer_allowed" ACL
>>>
>>>
>>> key "tsigkey" {
>>> algorithm HMAC-SHA512;
>>> secret   "x";
>>> };
>>>
>>> key "tsigkeyext" {
>>> algorithm HMAC-SHA512;
>>> secret  "xx";
>>> };
>>>
>>>
>>> view "corpnet" {
>>>   match-clients { internal; key tsigkey;
>>> };
>>>
>>>   //IP of slave server
>>>   server 192.168.173.78 {
>>>   keys { tsigkey; };
>>> };
>>>
>>>   also-notify {
>>>   192.168.173.78;
>>> };
>>>
>>>   zone "." IN {
>>>   type hint;
>>>   file "named.ca";
>>> };
>>>
>>>   zone"internalzone1.com" IN {
>>>   type master;
>>>   file "internalzone1.com";
>>>   allow-transfer { key tsigkey; };
>>> };
>>>
>>>   zone"sharedzone.com" IN {
>>> 

This is a test. Please disregard.

[project722]

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS views TSIG and zone xfers

[project722]

Actually, I got to thinking about this. The "other_allowed_ns" ACL is in
the global options, along with an "allow-transfer" for that ACL. So, I
*think* they will still be able to zone transfer via the global option
based on simply IP. BUT...since I have multiple views, which zones from
which views get sent over to these servers and how will they know how to
handle the info if zones from both views get sent. Would something like
this help:

allow-transfer { other_allowed_ns; view "external"; };

So they only get sent the zones from the external view?

On Thu, Aug 25, 2016 at 5:14 PM, project722 <project...@gmail.com> wrote:

> I have successfully setup TSIG keys for "views" using a DNS master/server
> pair. Zone transfers are working as expected between the 2 servers for each
> view. Before we go live into production with this I need some clarification
> on a couple things. Our prod servers are also allowing zone transfers to a
> few other servers besides the slave server. We have an acl setup that looks
> similar to this:
>
> other_xfer_allowed_ns {
> x.x.x.x; // This is our Secondary DNS server
> 127.0.0.1; // localhost can make zone transfers
> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
> }; // end of "other_xfer_allowed" ACL
>
> And in the "allow transfer" statement we have included that ACL. My
> question is:
>
> Now that we are using TSIG, will I need to get with the admins of all
> these other servers and provide them my TSIG key so they can request zone
> transfers? I would think somehting like that needs to be done since it was
> required to be configured on slave server, but I am not sure. I'd rather do
> an IP based control just for these other servers instead of TSIG but I am
> not sure how that would look or how to set that up in the context of my
> config. How can I tell my conf to NOT force these other xfer allowed
> servers to use TSIG and use IP only? This gets complicated when you start
> throwing views into the mix.
>
> acl internal {
> 192.168.200.0/24; // corpnet
> };
>
> acl external {
> 192.168.201.0/24;
> 192.168.202.0/24;
> };
>
>
>  other_xfer_allowed_ns {
> x.x.x.x; // This is our Secondary DNS server
> 127.0.0.1; // localhost can make zone transfers
> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
> }; // end of "other_xfer_allowed" ACL
>
>
> key "tsigkey" {
> algorithm HMAC-SHA512;
> secret   "x";
> };
>
> key "tsigkeyext" {
> algorithm HMAC-SHA512;
> secret  "xx";
> };
>
>
> view "corpnet" {
>   match-clients { internal; key tsigkey;
> };
>
>   //IP of slave server
>   server 192.168.173.78 {
>   keys { tsigkey; };
> };
>
>   also-notify {
>   192.168.173.78;
> };
>
>   zone "." IN {
>   type hint;
>   file "named.ca";
> };
>
>   zone"internalzone1.com" IN {
>   type master;
>   file "internalzone1.com";
>   allow-transfer { key tsigkey; };
> };
>
>   zone"sharedzone.com" IN {
>   type master;
>   file "sharedzone1.com";
>   allow-transfer { key tsigkey; };
> };
>
>  include "/etc/named.rfc1912.zones";
>   include "/etc/named.root.key";
> };
>
>
> view "external" {
>   match-clients { external; key tsigkeyext; };
>
>   //IP of slave server
>   server 192.168.173.78 {
>   keys { tsigkeyext; };
> };
>
>also-notify {
>   192.168.173.78;
> };
>
> zone "." IN {
> type hint;
> file "named.ca";
> };
>
> zone"externalzone1.com" IN {
> type master;
> file "externalzone1";
> allow-transfer { key tsigkeyext; };
>
> zone"sharedzone.com" IN {
> type master;
> file "sharedzone2.com";
> allow-transfer { key tsigkeyext; };
>  };
> include "/etc/named.rfc1912.zones";
> include "/etc/named.root.key";
>  };
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

DNS views TSIG and zone xfers

[project722]

I have successfully setup TSIG keys for "views" using a DNS master/server
pair. Zone transfers are working as expected between the 2 servers for each
view. Before we go live into production with this I need some clarification
on a couple things. Our prod servers are also allowing zone transfers to a
few other servers besides the slave server. We have an acl setup that looks
similar to this:

other_xfer_allowed_ns {
x.x.x.x; // This is our Secondary DNS server
127.0.0.1; // localhost can make zone transfers
x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
}; // end of "other_xfer_allowed" ACL

And in the "allow transfer" statement we have included that ACL. My
question is:

Now that we are using TSIG, will I need to get with the admins of all these
other servers and provide them my TSIG key so they can request zone
transfers? I would think somehting like that needs to be done since it was
required to be configured on slave server, but I am not sure. I'd rather do
an IP based control just for these other servers instead of TSIG but I am
not sure how that would look or how to set that up in the context of my
config. How can I tell my conf to NOT force these other xfer allowed
servers to use TSIG and use IP only? This gets complicated when you start
throwing views into the mix.

acl internal {
192.168.200.0/24; // corpnet
};

acl external {
192.168.201.0/24;
192.168.202.0/24;
};


 other_xfer_allowed_ns {
x.x.x.x; // This is our Secondary DNS server
127.0.0.1; // localhost can make zone transfers
x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
}; // end of "other_xfer_allowed" ACL


key "tsigkey" {
algorithm HMAC-SHA512;
secret   "x";
};

key "tsigkeyext" {
algorithm HMAC-SHA512;
secret  "xx";
};


view "corpnet" {
  match-clients { internal; key tsigkey;
};

  //IP of slave server
  server 192.168.173.78 {
  keys { tsigkey; };
};

  also-notify {
  192.168.173.78;
};

  zone "." IN {
  type hint;
  file "named.ca";
};

  zone"internalzone1.com" IN {
  type master;
  file "internalzone1.com";
  allow-transfer { key tsigkey; };
};

  zone"sharedzone.com" IN {
  type master;
  file "sharedzone1.com";
  allow-transfer { key tsigkey; };
};

 include "/etc/named.rfc1912.zones";
  include "/etc/named.root.key";
};


view "external" {
  match-clients { external; key tsigkeyext; };

  //IP of slave server
  server 192.168.173.78 {
  keys { tsigkeyext; };
};

   also-notify {
  192.168.173.78;
};

zone "." IN {
type hint;
file "named.ca";
};

zone"externalzone1.com" IN {
type master;
file "externalzone1";
allow-transfer { key tsigkeyext; };

zone"sharedzone.com" IN {
type master;
file "sharedzone2.com";
allow-transfer { key tsigkeyext; };
 };
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
 };
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

DNS views and zone transfers

[project722]

I have successfully setup TSIG keys for "views" using a DNS master/server
pair. Zone transfers are working as expected between the 2 servers for each
view. Before we go live into production with this I need some clarification
on a couple things. Our prod servers are also allowing zone transfers to a
few other servers besides the slave server. We have an acl setup that looks
similar to this:

other_xfer_allowed_ns {
x.x.x.x; // This is our Secondary DNS server
127.0.0.1; // localhost can make zone transfers
x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
}; // end of "other_xfer_allowed" ACL

And in the "allow transfer" statement we have included that ACL. My
question is:

Now that we are using TSIG, will I need to get with the admins of all these
other servers and provide them my TSIG key so they can request zone
transfers? I would think somehting like that needs to be done since it was
required to be configured on slave server, but I am not sure.

Next,

I setup views so that clients on the "internal" network when requesting a
record would be presented with different records than clients on the
outside. And at the moment there is only one zone that is required to have
different records. However, It is my understanding that since views are
based off source IP's, if I was to ONLY include that one zone in my
"internal" view, if a record was requested for another zone from that same
IP, they would probably get an nxdomain answer since that IP is limited to
that one view.

So, my question is, will I need to include all zones in both views so that
all clients can get results, even though I would only have (at the moment)
one zone that points to two different zone files? All others in both views
would point to the same zone file, unless of course there is another zone
we need to present a different view to for internal clients.

Now, last question.

I have a concern about the allow-query statement. On our production server
we have an ACL list we'll call it "trusted".
We have an allow query statement in the global options to only allow
queries from IP's in the trusted ACL. However every one of our zone entries
in the conf file also has an "allow-query { any; }; statement. Doesn't that
defeat the purpose of have a "trusted" ACL for queries? Is this bad design?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS views setup help

[project722]

Thanks Matthew, I got pulled away in some other projects, so I will go over
your last email sometime this week and get back with you with the results.
I appreciate the help so far.

On Fri, Aug 19, 2016 at 11:49 AM, Mathew Ian Eis <mathew@nau.edu> wrote:

> > where would I place it in the context of my views on the master?
>
> Inside of the view
>
>
>
> >  Do I only need that one stanza on the master?
>
> I believe it is needed on the slave as well, to tell the slave to use the
> correct key when communicating with the master. That is how we are doing it…
>
>
>
> > Why in the linked doc does it show it listed under the internal view?
>
> Because in the linked doc they are hosting the same zone on the internal
> and external view; in the context of showing how to use tsig keys, you are
> right, that aspect of the example is confusing. They have it that way
> because they are doing a zone transfer from the internal view to the
> external view, which is different than what I think you want to do.
>
>
>
> > If that's the designated external key should that be placed in the
> external view and not the internal?
>
> If I understand what you want to do correctly, yes…
>
>
>
> > And why does the internal view in the linked doc show both the external
> key and a "mykey" in the internal view
>
> “mykey” has nothing to do with zone transfers and is probably meant for
> management, although the example doesn’t specify.
>
>
>
> > Exactly how many keys do I need here?
>
> I think two … but it depends on your architecture. We have one key for
> admin of each view, and another key for each master/slave/view triplet.
> Managing the keys that way is more difficult (a lot of keys!), but less
> likely to accidentally put the wrong data in the wrong place.
>
>
>
> > Using my config from my first email  … can you provide a modified view?
>
> Here’s a possible way to set up your internal view. Try and get this
> working by itself without your external view, then go back and see if
> adding the external view makes more sense.
>
>
>
> ### master:
>
>
>
> view "insideview" {
>
>   match-clients {
>
> internal-key;
>
> !external-key;
>
> internal;
>
>   };
>
>   server 26.26.26.26 {
>
> keys { internal-key };
>
>   };
>
>   also-notify {
>
> 26.26.26.26 key internal-key;
>
>   };
>
>   zone"example.com" IN {
>
> type master;
>
> file "/var/named/db.exampleinside.com";
>
> allow-transfer {
>
>   key internal-key;
>
> };
>
>   };
>
> };
>
>
>
> ### slave:
>
>
>
> view "insideview" {
>
>   match-clients {
>
> internal-key;
>
> !external-key;
>
> internal;
>
>   };
>
>   server 25.25.25.25 {
>
> keys { internal-key };
>
>   };
>
>   zone"example.com" IN {
>
> type slave;
>
> file "/var/named/db.exampleinside.com";
>
> masters { 25.25.25.25; };
>
>   };
>
> };
>
>
>
>
>
> Mathew Eis
>
> Northern Arizona University
>
> Information Technology Services
>
>
>
> *From: *project722 <project...@gmail.com>
> *Date: *Thursday, August 18, 2016 at 8:17 PM
> *To: *Mathew Eis <mathew@nau.edu>
> *Cc: *"bind-users@lists.isc.org" <bind-users@lists.isc.org>
> *Subject: *Re: DNS views setup help
>
>
>
> That is correct, as I have not setup the TSIG keys yet.
>
> Also, I am still a bit confused on how this code should be implemented in
> my conf file. In the example you posted that refers back to the link, where
> would I place it in the context of my views on the master? Do I only need
> that one stanza on the master and why in the linked doc does it show it
> listed under the internal view? If that's the designated external key
> should that be placed in the external view and not the internal? And why
> does the internal view in the linked doc show both the external key and a
> "mykey" in the internal view while only showing one for the external view?
> Exactly how many keys do I need here?
>
> Lets say my master server IP is 25.25.25.25 and my slave is 26.26.26.26.
> Using my config from my first email and your code from your reply (lets use
> only the part from the linked doc you wrote) can you provide a modified
> view for internal an

Re: DNS views setup help

[project722]

That is correct, as I have not setup the TSIG keys yet.

Also, I am still a bit confused on how this code should be implemented in
my conf file. In the example you posted that refers back to the link, where
would I place it in the context of my views on the master? Do I only need
that one stanza on the master and why in the linked doc does it show it
listed under the internal view? If that's the designated external key
should that be placed in the external view and not the internal? And why
does the internal view in the linked doc show both the external key and a
"mykey" in the internal view while only showing one for the external view?
Exactly how many keys do I need here?

Lets say my master server IP is 25.25.25.25 and my slave is 26.26.26.26.
Using my config from my first email and your code from your reply (lets use
only the part from the linked doc you wrote) can you provide a modified
view for internal and external for both the master and slave server?

Sorry for all the questions, its just that I'm very new to this view thing,
as you might have guessed:)

On Thu, Aug 18, 2016 at 9:50 PM, Mathew Ian Eis  wrote:

> I think you are pretty close. One detail that you appear to be missing are
> is in the linked document:
>
>
>
> server 10.0.1.1 {
>
> /* Deliver notify messages to external view. */
>
> keys { external-key; };
>
> };
>
>
>
> Your slaves should have a similar statement in each view with the IP of
> the master and the relevant key for that view.
>
>
>
> Two other things we have learned in deploying this:
>
>
>
> * It is helpful to change your allow-transfer section to be key-based
> per-view instead of IP based to save you from accidental zone transfers
> when other configuration errors are made.
>
> * The match-clients rule can be prepended with a key/!key set to prevent
> accidental communication on that view when using keys; e.g.
>
>
>
> match-clients {
>
> # key matching rules
>
> key admin-internal;
>
> !key admin-external;
>
> key slave-internal;
>
> !key slave-external;
>
> # ip/acl matching rules
>
> internal-ips;
>
> };
>
>
>
>
>
> Regards,
>
>
>
> Mathew Eis
>
> Northern Arizona University
>
> Information Technology Services
>
>
>
> *From: *bind-users  on behalf of Brian
> Pugh 
> *Date: *Thursday, August 18, 2016 at 7:15 PM
> *To: *"bind-users@lists.isc.org" 
> *Subject: *DNS views setup help
>
>
>
> I am running bind 9.8.2 on a pair of RHEL 6 DNS servers.. One server is
> the master, one is the slave. My goal is to setup 2 views so that our
> internal folks can resolve hostnames to internal IP's while still allowing
> our external customers to resolve from the outside. Both of these servers
> are external facing and have only one public IP each. First of all I would
> like to know if what I am trying to achieve is even possible with my
> current setup. What we have are internal users that are trying to access
> internal resources via a domain name that only exist in our external DNS.
> We do not have an internal zone for this domain or a inside DNS server that
> we can point them to in order to get a result for the query. So that leaves
> us looking at views for the solution.
>
> To be more precise, this is what is happening now.
>
> Internal client > looks up host that's actually on the internal network
> but resolves to an external IP. The problem with this is 2 fold.
>
> 1) DNS returns an external IP
>
> 2) Since the resource is internal, the traffic flow to the outside and
> back in happens on the same outside interface, which results in a hairpin,
> which we do not allow.
>
> Now, what I was told is that a DNS view type solution would not be
> applicable to the hairpin. My understanding is that internal clients query
> the server already to get results for external IP, so if we had a zone file
> in a view that had internal mappings, this would work and the internal user
> could access the resource since they are now being pointed to an internal
> IP.
>
> So what I want to do is setup an "internal" view for the zone in question
> that points to a db file with the internal IP of that host, and an external
> view for everyone else.
>
>
>
> My questions is:
>
> 1) Would DNS views work for my use case now that my server layout has been
> described?
>
> If so I need help in setting up TSIG because in my test lab everything
> seems to work except that on my slave server my zone in "view A" is being
> updated with the data from the master server from "view B". And view B
> seems to be in sync on both servers, although it seems when I update zone
> files I have to restart instead of a reload to get the zones to update.
> Even then, that does not always work. There is a link I found online that
> says TSIG would be the solution for this but it gives very