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  wrote:

>
> On Thu, Aug 25, 2016 at 12:56 PM, project722  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. 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?
>>
>
> Seems like the 'any' would override the 'trusted'.  Probably not what you
> wanted.
>
> --
> Bob Harold
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list

Re: Request reverse dns mapping advice

[Bob Harold]

On Tue, Sep 6, 2016 at 1:39 AM, Dave Warren  wrote:

> On Mon, Sep 5, 2016, at 09:46, John Levine wrote:
> > >1.  pick a primary domain from the list of virtual hosts (example2.com)
> > >2.  use the "real" host name of the server (juvat.example1.com)
> > >3.  the mail server name (mail.example1.com)
> > >4.  the dns server name (ns2.example1.com)
> > >5.  another domain from the virtual hosts list (example 3.com)
> >
> > Publish a PTR with the mail server name, forget about the rest of
> > them.
> >
> > On today's Internet, you want your mail server to EHLO with a name
> > that has matching forward and reverse DNS with the server's IP.  If
> > you don't, you look unnecessarily like a spambot.
> >
> > Everyone knows that web servers and DNS servers have multiple names,
> > and neither should be sending unsolicited traffic, so matching rDNS
> > doesn't matter.
>
> Perhaps I'm old fashioned, but I like to see things done "correctly",
> and rDNS is one of those things that shows a competent host who worries
> about getting the details right, vs a host who has no technical skills
> or knowledge and does the bare minimum. Does it make for an operational
> difference? Not really. But it does make it obvious what entity is
> responsible for a machine and I feel that that's important.
>
> Personally, I set valid and correct names that identify me (the host) on
> machines under my control, whether or not they're intended to make
> outbound connections (and web servers do). If an IP is dedicated to a
> specific client then I'll consider what makes the most sense, but
> generally I do assign the client's rDNS to a dedicated IP.
>
> With that being said, I'd do something like ns2.example.com, or
> web.juvat.example.com, or whatever is appropriate within your normal
> naming scheme.
>
> > Opinions vary on how well it works to return multiple PTRs.  My
> > advice is don't borrow trouble you don't need.
>
> I agree on this point. Even if it works with only a few PTRs (and it
> mostly will, as long as each PTR has a matching and valid A/
> record), what will happen when you have dozens of domains?
>
> I agree with one PTR per IP.  But since you have 5 IP's, you can have one
PTR record on each, just be sure there is a matching forward "A" record.
Your list of 5 names looks good, but only if each service uses the
corresponding IP for its outgoing connections, which could be difficult or
not the most efficient.  (What is missing here is why 5 IP's - parallel for
more traffic, connections to different Internet providers, ...?)

-- 
Bob Harold
___
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

Overwrite SOA-Records in RPZ-Responses?

[Tom]

Hi list,

From "https://kb.isc.org/getAttach/21/AA-00512/rpz.txt;, Chapter 3 - 
Subscriber Behavior:


...
...
If a policy trigger results in a modified answer, then that modified 
answer will include in its "authority" section the SOA RR of the DNS RPZ 
whose policy was used to generate the modified answer. This SOA RR will 
tell both the fully qualified name of the DNS RPZ and the serial number 
of the policy data which was connected to the DNS control plane at the 
time the answer was modified.

...





Is there a way to overwrite the SOA-Record in a RPZ-Response 
"on-the-fly", whose zone is configured as "slave"? Because we use 
configured some third-party-rpz-zones, the soa-record is predefined...


Thank you.
Kind regards,
Tom
___
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: Latest BIND: Error "rpz_rewrite_name: mismatched summary data; continuing"

[Tom]

Hi Mukund

Many thanks for your hint. In fact named was compiled with 
"--enable-querytrace". After recompiling 9.10.4-P2 without querytrace, 
the log looks good.


Kind regards,
Tom



On 09/06/2016 09:32 AM, Mukund Sivaraman wrote:

Hi Tom

On Tue, Sep 06, 2016 at 07:37:50AM +0200, Tom wrote:

Is there a workaround/configuration-directive not to log every request with
this "error"? One way would be using BIND 9.9.9-P2 (because this code was
added in 9.10.x...), but I would prefer 9.10.x.


(1) Don't use regular BIND 9.9 for RPZ. For using RPZ, please use 9.10
and higher (or 9.9 subscription branch that's available to ISC
customers). RPZ in vanilla 9.9 is unmaintained and unsupported (it was
experimental there).

(2) We'll look at tweaking this log message, but if you want to just not
see this log message, just recompile after removing the offending CTRACE
statement from bin/named/query.c. In fact, this code is normally enabled
when configured with --enable-querytrace. Do you have query tracing
configured? Is seeing this additional log message so inconvenient then?

Mukund


___
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: Latest BIND: Error "rpz_rewrite_name: mismatched summary data; continuing"

[Mukund Sivaraman]

Hi Tom

On Tue, Sep 06, 2016 at 07:37:50AM +0200, Tom wrote:
> Is there a workaround/configuration-directive not to log every request with
> this "error"? One way would be using BIND 9.9.9-P2 (because this code was
> added in 9.10.x...), but I would prefer 9.10.x.

(1) Don't use regular BIND 9.9 for RPZ. For using RPZ, please use 9.10
and higher (or 9.9 subscription branch that's available to ISC
customers). RPZ in vanilla 9.9 is unmaintained and unsupported (it was
experimental there).

(2) We'll look at tweaking this log message, but if you want to just not
see this log message, just recompile after removing the offending CTRACE
statement from bin/named/query.c. In fact, this code is normally enabled
when configured with --enable-querytrace. Do you have query tracing
configured? Is seeing this additional log message so inconvenient then?

Mukund


signature.asc
Description: PGP signature
___
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