Re: Answers for www.dnssec-failed.org with dnssec-validation auto;

[Bob McDonald]

Thanks Mark. It's right there in the log. 

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Answers for www.dnssec-failed.org with dnssec-validation auto;

[Bob McDonald]

Would this be true for FreeBSD as well?  I also have a bind 9.18.24
instance running on freeBSD
and it seems to be ok.

Bob

> The crypto policy stuff ultimately creates and maintains files in
/etc/crypto-policy/backends, which has a list of acceptable or
not-acceptable crypto settings.

> Whilst a "bind.config" is created, you aren't including it in your config
(this is fine), which suggests that the issue is with some of openssl
configurations (which will be system wide anyway).

> You can use the update-crypto-policies to update only the openssl
configuration to allow sha1, or you could manually recreate those files
(instead of the usual symlinks) and edit them individually as you please.

> Stuart
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Answers for www.dnssec-failed.org with dnssec-validation auto; (John Thurston)

[Bob McDonald]

My bind 9.18.24 server runs under Debian.
When I query with dig it appears to take long enough to resolve that it
goes to the next DNS server in the client's IP stack. The secondary server
in my list is quad9. It seems to resolve correctly. If I point to the
address of my Debian server, it works but it's REALLY slow.

Dig shows both the address of the server providing the answer and the
amount of time it took for the resolution. That MAY provide some clues as
to what's going on.

I suspect this is an issue with bind 9.18.24. I can't say for sure.

HTH,

Bob

Sent from my Google Pixel phone.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Facing issues while resolving only one record

[Bob McDonald]

This is why I try to read this list every day...

Thanks Mark.

I need to go back to RTFM (or read the man page)
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Facing issues while resolving only one record

[Bob McDonald]

Turning off validation for that domain fixes the issue.

When using dig to diagnose this issue, one might be tempted to use the
DNSSEC switch. However, the following command:

dig eportal.incometax.gov.in. +NODNSSEC

will NOT turn off DNSSEC validation.

The DNSSEC switch in dig is used to display the associated DNSSEC records
(if they exist). It doesn't affect validation. You must make the options
change indicated by Greg Choules in his previous post to disable DNSSEC
validation for a specific domain.

Sorry if this is redundant or very rudimentary.

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

RE: PPA for Raspbian distros

[Bob McDonald]

My RaspberryPI has two micro SD cards with different OS setups.

One is Debian Bullseye running Bind 9.16.37.(I upgraded from Buster 6+
months ago)
The other is FreeBSD 13.1 running Bind 9.18.13.

I've found that the BSD distros tend to be more generous with their
offerings on DNS software versions. e.g. FreeBSD offers 9.16, 9.18, and
9.19. They are also a little quicker to offer packages for new releases.

YMMV,

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Sanity Check

[Bob McDonald]

I'm implementing a caching resolver under FreeBSD 13.1 running on a
RaspberryPI. Bind 9.18.11

My named.conf is below. My question is do these look like workable options?
I include logging and a statistics channel in my preliminary
implementations for more detail on what's going on. That will go away
eventually. Any comments are welcome.

Thanks,

Bob

named.conf:

acl rfc1918-nets {
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
};

include "/usr/local/etc/namedb/rndc.key";

controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
inet ::1 port 953 allow { ::1; } keys { rndc-key; };
};

options {
directory   "/usr/local/etc/namedb/working";
pid-file"/var/run/named/pid";
dump-file   "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
secroots-file "/var/cache/bind/secroots.txt";
memstatistics-file "/var/stats/named_mem_stats.txt";
managed-keys-directory "/var/cache/bind";
session-keyfile "/var/cache/bind/session.key";
recursion yes;
masterfile-format text;
minimal-responses no;
empty-zones-enable yes;
empty-server "raspberrypi-00.ddisupport.tech";
empty-contact "robert\.mcdonald.ddiarchitect.tech";
querylog yes;
query-source address 172.27.255.99;
transfer-source 172.27.255.99;
notify-source 172.27.255.99;
request-nsid yes;
server-id hostname;
zone-statistics full;
dnssec-validation auto;
dnssec-accept-expired no;

listen-on   { 127.0.0.1; };
listen-on   { 172.27.255.99; };
listen-on-v6{ ::1; };

allow-query { ::1; 127.0.0.1; rfc1918-nets; };
allow-query-cache { ::1; 127.0.0.1; rfc1918-nets; };
allow-recursion { ::1; 127.0.0.1; rfc1918-nets; };
};

zone "localhost"{ type master; file
"/usr/local/etc/namedb/primary/localhost-forward.db"; };
zone "127.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/primary/localhost-reverse.db";};

statistics-channels {
inet 172.27.255.99 port 28079 allow { rfc1918-nets; };
};

logging {
channel default_log {
file "/var/log/named/default" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel auth_servers_log {
file "/var/log/named/auth_servers" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel dnssec_log {
file "/var/log/named/dnssec" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel zone_transfers_log {
file "/var/log/named/zone_transfers" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel ddns_log {
file "/var/log/named/ddns" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel client_security_log {
file "/var/log/named/client_security" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel rate_limiting_log {
file "/var/log/named/rate_limiting" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel rpz_log {
file "/var/log/named/rpz" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel dnstap_log {
file "/var/log/named/dnstap" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel queries_log {
file "/var/log/named/queries" versions 600 size 20m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel query-errors_log {
file "/var/log/named/query-errors" versions 5 size 20m;
print-time yes;
print-category yes;
print-severity yes;
severity dynamic;
};
channel default_syslog {
print-time yes;
 

Re: Incremental transfers generate complete zone reloading

[Bob McDonald]

Mea Culpa. Apparently RPZ IS the issue here.

I learn something new every time I read this list.

My apologies for the waste of bandwidth.

Bob

On Mon, Jan 16, 2023 at 9:02 AM Bob McDonald  wrote:

> This is just conjecture but I'll take a stab at this problem.
>
> First, the fact that the zone is RPZ really doesn't have any bearing on
> this problem.
>
> Do you control both the primary and secondary zones?
>
> Please provide the SOA for the zone. This will allow the list to see some
> key timer values.
>
> 1) Updates are applied to the primary zone which triggers a notify to the
> secondary zone and a resulting incremental zone transfer. (IXFR)
>
> 2) Before the IXFR from item 1 is finished, the refresh timer expires
> triggering the secondary zone to request the SOA from the primary. Since
> the serial number on the secondary has not yet been updated as a result of
> the IXFR from item 1, the secondary requests ANOTHER IXFR from the primary.
> This can cause the overlap you are seeing.
>
> The following suggestions for possible workarounds depend on you having
> control of both primary and secondary zones.
>
> There are a couple of things that could help. the refresh timer for
> properly configured dynamically updatable zone sets needs to be set fairly
> high. I like 8 hours. YMMV.
>
> The updates to the primary zone can be effectively batched using the
> notify-delay value. This will require some further thought and testing. The
> ultimate value depends on the volume of updates being generated.
>
> Hope that helps,
>
> Bob
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

RE: Incremental transfers generate complete zone reloading

[Bob McDonald]

This is just conjecture but I'll take a stab at this problem.

First, the fact that the zone is RPZ really doesn't have any bearing on
this problem.

Do you control both the primary and secondary zones?

Please provide the SOA for the zone. This will allow the list to see some
key timer values.

1) Updates are applied to the primary zone which triggers a notify to the
secondary zone and a resulting incremental zone transfer. (IXFR)

2) Before the IXFR from item 1 is finished, the refresh timer expires
triggering the secondary zone to request the SOA from the primary. Since
the serial number on the secondary has not yet been updated as a result of
the IXFR from item 1, the secondary requests ANOTHER IXFR from the primary.
This can cause the overlap you are seeing.

The following suggestions for possible workarounds depend on you having
control of both primary and secondary zones.

There are a couple of things that could help. the refresh timer for
properly configured dynamically updatable zone sets needs to be set fairly
high. I like 8 hours. YMMV.

The updates to the primary zone can be effectively batched using the
notify-delay value. This will require some further thought and testing. The
ultimate value depends on the volume of updates being generated.

Hope that helps,

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: managed-keys vs trust-anchors

[Bob McDonald]

Thanks Evan and Ondrej.  I'll let the folks at FreeBSD know also. Their
bind packages still include that file.

Bob


On Wed, Jan 4, 2023, 14:59 Evan Hunt  wrote:

> On Mon, Jan 02, 2023 at 07:33:46AM -0500, Bob McDonald wrote:
> > I've upgraded to bind 9.16.36.
> >
> > I went to the ISC site and picked up the bind.keys file.
> >
> > However, it is intended for use in bind 9.11 and contains the
> managed-keys
> > clause. This throws an error in the syslog messages during startup. It
> > appears to still function correctly.
> >
> > In the ARM for bind 9.16 it states that managed-keys clause is
> deprecated.
> > Replacing the managed-keys clause with the trust-anchors clause seems to
> > fix the issue. In the file itself it states the following:
> >
> > # This file is NOT expected to be user-configured.
> >
> > Perhaps I've missed something. If not, the documentation needs to be a
> bit
> > more clear on this. Would it be helpful to have a version of the
> bind.keys
> > file for bind 9.16 and above?
>
> Thanks for bringing this to our attention. It's no longer necessary
> to get the bind.keys file from the ISC website. We've updated the
> site to remove the downloadable version, and just put some explanatory
> text there instead.
>
> The bind.keys file was originally put there for reasons that aren't really
> applicable anymore; you can safely rely on the one that's compiled in to
> named now.  Some background on this can be found in the discussion at
> https://www.mail-archive.com/bind-users@lists.isc.org/msg31664.html.
>
> (And, if for some odd reason you really do need to download a new copy of
> bind.keys instead of updating BIND, you can pull it from the source tree:
> https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bind.keys.)
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

managed-keys vs trust-anchors

[Bob McDonald]

I've upgraded to bind 9.16.36.

I went to the ISC site and picked up the bind.keys file.

However, it is intended for use in bind 9.11 and contains the managed-keys
clause. This throws an error in the syslog messages during startup. It
appears to still function correctly.

In the ARM for bind 9.16 it states that managed-keys clause is deprecated.
Replacing the managed-keys clause with the trust-anchors clause seems to
fix the issue. In the file itself it states the following:

# This file is NOT expected to be user-configured.

Perhaps I've missed something. If not, the documentation needs to be a bit
more clear on this. Would it be helpful to have a version of the bind.keys
file for bind 9.16 and above?

Regards,

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: PowerDNS secondary servers receive empty SOA response for particular zone.

[Bob McDonald]

Under certain circumstances, DNS zones representing Windows Active
Directory domains can have rather large numbers of NS records if there
are/were DCs running DNS. This can happen in any DNS zone with a large
number of secondary DNS servers.

The size of the TCP packets is a problem. You might also look at
minimal-responses.

Look at the structure of your DNS environment.

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: dig +norecurse behaviour changed with 9.16.33

[Bob McDonald]

Are the zones cern.ch and spectrum-lb.cern.ch on the same authoritative
sDNS server?
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

RE: dig +norecurse behaviour changed with 9.16.33

[Bob McDonald]

For both versions of bind, please submit the actual dig command and the
complete results received. That will make diagnosing this issue MUCH easier.

Regards,

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Question About Internal Recursive Resolvers

[Bob McDonald]

Let's not overthink this. I fear that I've activated a lot of creative
circuitry in individuals and provided flimsy details around my example.

There are no outside clients. In this example, I'm only discussing inside
clients on inside DNS. The recursive resolvers that ALL inside clients
connect to will seek responses from the DNS root servers AFTER determining
that the response can not be determined from the internal DNS zones. There
is no access provided to outside (internet centric) clients to inside DNS.
The determination of known/unknown clients is via a NAC layer and further,
the classification of unknown gets automatically assigned to those clients
combining in through GUEST WiFi (e.g. cell phones, ipads, etc.). Most
organizations with a NAC layer in place have procedures to allow unknown
clients temporary access at some level (e.g. vendors, etc.).

HTH,

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Question About Internal Recursive Resolvers

[Bob McDonald]

OK, if a known client accesses DNS on the internal network, that
client is pointed at a recursive resolver (e.g by DHCP). That resolver
either provides access to the internal DNS zones (e.g. via stub zones)
or sends the client query to the root servers on the internet. An
unknown client (e.g. guest WiFi) will be given the same resolver
address for its DNS server. At this point it would require ACLs to
prevent that unknown client from accessing the internal DNS zones. All
DNS traffic from that client would be sent to the internet.

Another way to achieve that would be to have a separate set of DNS
resolvers for unknown clients (resolver addresses handed out via
DHCP). That's my current view of how to get things done in this case.

What I'm discerning from the discussion so far is that this isn't
strictly necessary. The internal DNS zones can/should reside on the
recursive resolvers. The question of unknown client access to internal
DNS zones is resolved (no pun intended...).

RPZ COULD be implemented on ANY of the recursive DNS resolvers.

The tsig key discussion is around its use as a method of allowing
updates to internal DNS zones. Strictly hypothetical. Don't get hung
up on it.

Thank you all for the information. You've provided answers to my
questions and have renewed my faith in geekdom.

If anyone is still confused, I'd be glad to discuss this offline until
we have a final solution. Then we can publish if necessary.

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Question About Internal Recursive Resolvers

[Bob McDonald]

>>I'm thinking about redesigning an internal DNS environment. To begin
>>with, all internal DNS zones would reside on non-recursive servers
>>only.

>why?

My understanding has always been that the recommendation is/was to
separate recursive and non-recursive servers. Now I understand I'm
talking about an INTERNAL environment and the rules have over the
years become somewhat lax... In this case I also believe this would
provide a more granular approach to using security features such as
tsig keys to control updates.

>> That said, all clients would connect to recursive resolvers.

>don't they now?

They do. I'm talking about a situation where an edge layer can be
eliminated. Each recursive server would have access out to the
internet. No forwarding would be required.

>>The question is this; do I use an internal root with pointers to the
>>internal zones (as well as the outside DNS world) or do I include stub
>>zones to point at the non-recursive internal servers?

>stub zones, forward zones (forward with recursion bit set) or static-stub
zones (send iterative queries to configured servers)>

Again, my understanding is that forwarding would require recursion.
Thanks for the info about stub zones etc.

>>Access to the internal DNS zones would be controlled by location.

>if you have recursive servers in internal network, you don't need control
>access on auth-only servers

If a non-secure client (read the next sentence...) accesses the same
recursive server as a regular client, it will have access to the
internal zones by default.. Therefore we need to have some sort of
access controls in place.

>>(e.g. guest WiFi devices would NOT have access to internal DNS
>>zones...)
>>
>>Recursive resolvers would allow implementation of features such as RPZ, etc.

>do you need RPZ for internal zones?

Since ALL recursive servers have access out to the internet, yes.

Please forgive me if my post was confusing, arrogant, or naive. I'm
simply trying to seek the wisdom of those on the list that have more
experience or different experience than myself. Hopefully, I can gain
from that wisdom and we can provide a kind environment where those
less educated feel mentored.

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Question About Internal Recursive Resolvers

[Bob McDonald]

I'm thinking about redesigning an internal DNS environment. To begin
with, all internal DNS zones would reside on non-recursive servers
only. That said, all clients would connect to recursive resolvers.

The question is this; do I use an internal root with pointers to the
internal zones (as well as the outside DNS world) or do I include stub
zones to point at the non-recursive internal servers?

Access to the internal DNS zones would be controlled by location.
(e.g. guest WiFi devices would NOT have access to internal DNS
zones...)

Recursive resolvers would allow implementation of features such as RPZ, etc.

Regards,

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: bugs for cname can not be working properly with bind 9.11.4

[Bob McDonald]

I also get the same value for the serial number from a dig soa .

A couple of questions.

1) I assume you are updating the serial number on the master (primary) zone
file. Correct? Is this a stealth (hidden) master?
2) On that same server, what are your values for NOTIFY and if specified,
EXPLICIT-NOTIFY.
3) Is there a firewall between the master (primary) and any.all slave
(secondary) servers? If yes, does the firewall allow port 53 botj UDP
and TCP traffic between those servers?
4) Are you logging everything? (yeah, I know query logging can use alot of
resources)

Just from a cursory glance at the zone with dig, it looks as though the
domain wasn't reloaded.

Also, it looks like NS2 doesn't responf.

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Determining Which Authoritative Sever to Use

[Bob McDonald]

Coding a zone statement within the dhcp config file tells dhcp where to
send DDNS updates to. This has traditionally been a method used to update a
truly stealth (hidden) DNS master/primary zone.

However, in the case of using bind DNS servers to provide DNS for Windows
Active Directory, this can present an issue. There are a couple of
requirements for Active Directory Domain Controllers. Ome, they must have
authoritative access to the Active Directory DNS domain. Two, they must be
able to dynamically update that same DNS domain. The issue this presents is
that with a truly stealth (hidden) DNS domain, the server identified in the
MNAME field of the SOA record is not really the master/primary. At this
point, there are traditionally a few choices. One, use
allow-update-forwarding and be stuck with increased and time consuming
troubleshooting. Two, use GSS-TSIG to update the DNS domain. (Be careful,
this method has its own holy war. You've been warned!) Three, eliminate the
stealth master/primary by making the MNAME field of the SOA record match
the actual master/primary server name. Now, personally, I have never seen
the worth of having stealth master/primary servers within an internal
environment. Again, my personal opinion is that it needlessly complicates
the architecture of the environment and adds unnecessary cost. However, my
experience with internal environments is with DDI appliances and they would
offer any necessary backup requirements for a DNS zone. YMMV

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Determining Which Authoritative Sever to Use

[Bob McDonald]

It's always an architectural choice to use anycast with your authoritative
zones. I'm speaking from purely a private network (inside) viewpoint. I
typically only use anycast for recursive DNS servers on my
private (internal) network.

That said, here are some thoughts. (This is my understanding only)

A default primary/secondary DNS zone setup as per the relevant RFCs
includes one primary DNS server name in the MNAME field of the SOA record
for that DNS zone. Following a non-Windows update procedure, a device
(client of DHCP server - specified by DHCP option 81) sends a DNS query for
the zone SOA record. It then sends a dynamic update to the
specified MNAME server found in the reply to the SOA record query.
Windows can be a bit different. If, for example, the zone to be updated is
an Active Directory integrated DNS zone then this applies; a DHCP client
sends a rDNS request for SOA to it's local DNS server. Because this is an
Active Directory integrated DNS zone, each DC running DNS places it's own
name in the MNAME field. Now the update request goes to the local DC
running DNS. This spreads out the update request workload. There is a more
convoluted process involving stepping through the NS records looking for a
valid update server if the update should fail. This also does not take into
account any security involved with said updates.
Going back to "normal" DNS setups. If the MNAME in the SOAis replaced with
another name, this is an example of a truly hidden master. Updates sent in
this case require allow-update-fowarding to be set to any. This may on the
surface seem like it will do the trick but unsecured (those without tsig or
gss-tsig)  update requests may be hard to troubleshoot. Forwarding the
update replaces the update origin IP with that of the secondary server that
forwards the request. It would seem that using an anycast cloud name (An
anycast cloud of the NS device IPs) for the MNAME might provide the same
level of distribution as per Windows. However, again, you run into the
issues of forwarded updates. More testing would need to be done to see if
secured updates actually identify the correct requester in the log files.

In summary, there are SEVERAL methods to explore here and tons of options
within DNS and DHCP that might have some bearing on this also. Then there's
the holy war about the security of gss-tsig signed updates. Anyway, I've
been looking at this for the last decade. I'm sure I'll discover more along
the way.

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Determining Which Authoritative Sever to Use (Bob McDonald)

[Bob McDonald]

Thanks for the answers. A couple more questions and then I'll stand down.

First, it's Ben Croswell. Just pointing that out.

Second, my reading of the definition of a static-stub zone in the Bvarm
indicates that its use is to allow a local copy of the NS list which may
differ from the primary zone. I'm not sure that's what I'm looking for. I
think I'm ok with the NS list from the primary zone. Lei me take another
swing and try to be a bit more pedantic to see if that helps.

I wish to define a global internal DNS environment.

At the level closest to the client would be a global network of recursive
DNS servers which would handle all internal and external DNS requests. The
internal DNS zones would be housed on a global network of authoritative
only DNS servers. The NS list for the internal DNS zones on these
authoritative only servers would be known to the recursive servers via stub
zones. My question is, if a client in Mumbai submits a DNS request to his
local recursive server for an internal authoritative only zone defined by a
stub zone statement, which authoritative only server does the recursive
server pick from the NS list and will that eventually be the "closest"
server. I'm assuming a global distribution of the authoritative servers.
E.g. Hong Kong, London, US East, US West, South Amer, etc. The use of the
stub zones in this case is to eliminate the need for an internal root. I
want to avoid lookups for example from clients in Asia being sent to
authoritative only servers in South Amer.

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Determining Which Authoritative Sever to Use

[Bob McDonald]

Forgive my ignorance if this is a trivial question.

Supposing I have an internal IP network (rfc1918)  where there atr local
caching servers (recursive) which clients connect to and scattered around
are several authoritative servers  which provide answers for internal only
zones. Those internal only zones are defined on the caching servers via
stub zones.

My question is this; how do the recursive servers determine from
the information in the stub zone which name server to query? And, is that
the closest (network wise)? Do I need to put anycast into the mix?

TTFN,

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: AA flag

[Bob McDonald]

I'm guessing that the zone files hosted on the new DNS servers still
contain NS records pointing to the old DNS servers.

Based on your post, that's my guess.

Bob
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

RE: replication time for dynamic records from primary to secondary servers

[Bob McDonald]

Is there an entry in your server options similar to this?

notify-delay nn;

Regards,

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Local resolution first and then public resolution for "google.com" domain (Roberto Carna)

[Bob McDonald]

You could use RPZ for the entry "www.google.com" and then the rest of the
domain would resolve from the internet.

Regards,

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: bind 9.16.7 Odd query error (Borja Marcos)

[Bob McDonald]

My config took the following combination before it would work:

max-recursion-depth 20;
max-recursion-queries 275;

I'm running both IPv4 and IPv6.

Regards,

Bob

On Thu, Oct 1, 2020 at 2:37 AM Borja Marcos  wrote:

>
>
> > On 30 Sep 2020, at 22:34, Mark Andrews  wrote:
> >
> > No, it’s just fetches per query taking effect.  With a empty cache there
> are just too many queries made looking up addresses of name servers. You
> can raise the default slightly.
>
> Alright, I think I found this particular issue. I begun hammering quotas
> and this one is the culprit in this particular case:
>
> max-recursion-queries
>
> which, according to the documentation, has a default value of 75. I raised
> it to 200
> (I said, hammering!) and now it works reliably.
>
> Maybe the default value is too low.
>
>
>
>
>
>
> Borja.
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: bind 9.16.7 Odd query error (Borja Marcos)

[Bob McDonald]

Same thing here. Here's what I found.

1) there's and old version of the root hints file. Nov 2017. Current is
sept 2020. New one didn't change things. I'll look at my other setup which
slaves the root.
Caveat: I'm running FreeBSD 12.1
2) Upon executing the dig a second time, it resolves.

Almost looks like some sort of priming issue.

YMMV,

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

RE: "minimal-any" configuration query

[Bob McDonald]

Without seeing your configuration, I can only suggest trying the
minimal-responses option.

Regards,

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: A And Cname-record

[Bob McDonald]

May I suggest the following?:

If you are an individual that is so pedantic that seeing a spelling error
causes you to lose sleep or have other soul searing consternation, send an
email (gently worded) to the poster only. Please also be encouraging to
that individual pointing out that these types of errors happen and will not
cause loss of their immortal soul. As Ondrej points out, we are trying to
build community that's welcoming to newcomers to the wonderful world of DNS.

I remember when I first subscribed to this list being terrified of posting
after reading several rather terse replies. I've since gotten a bit thicker
skin. I've learned a lot from this list. However, it's not for the timid.
Please be considerate in the wording of your replies.

With my lack of typing skills, my lack of spelling skills, and my lack of
grammar skills, it's a small wonder that anything I post on this list is
understood.

Couple that with most readers not having english as a first language and it
quickly becomes a miracle!

My somewhat simpler interpretation of that error:

if during the named loading process a zone produces an error that says
CNAME and other data, my experience has been that the zone being loaded
contains an A record and one or more CNAME records with the same owner
value (hostname). That's not allowed under the RFC documents for bind.

e.g.

remtest IN A 100.64.0.2
remtest IN CNAME temp.example.com.

-OR-

remtest IN CNAME temp.example.com.
remtest IN CNAME temp001.example.com.

Both examples are not allowed under the RFCs.

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

re: How to disable recursion on ONE domain? (Bind-9.11.14)

[Bob McDonald]

Would adding the following to the zone config work?

forwarders {};

Regards,

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

re: Delegation not working from slave.

[Bob McDonald]

If I'm reading this correctly, it looks like delegation DOES work from the
slave.

Looking at the zone file for sub.example.org. from the main DNS server, is
the delegation present for dyn.sub.example.org.? (e.g. is there a
dyn.sub.example.org. IN NS dynsub.example.org. in the zone file for
sub.example.com. on the main DNS server?) And does the zone file on the
main have a glue record for dynsub.example.org.?

Regards,

Bob
___
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: Intermittent ServFail for FreeBSD.org names? (Havard Eidnes)

[Bob McDonald]

What does your request show when you include a +nodnssec switch on the dig?

-Bob
___
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: nsupdate reject

[Bob McDonald]

The most obvious thing is to look at the zone and see if that key is
included in an allow-update statement for the zone.

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

Questions about delegation

[Bob McDonald]

I have a DNS server that serves a zone for domain example.org.
That DNS server lives at 192.0.2.53
As part of hosting that domain, a child domain is delegated. (
gtm-int.example.org.)
There are two NS records as follows:
gtm-int.example.org. IN NS gtm-int-east.example.org.
gtm-int.example.org. IN NS gtm-int-west.example.org.
gtm-int-east.example.org. IN A 203.0.113.53
gtm-int-west.example.org. IN A 198.51.100.53
(and yes, in this case the delegated child domain lives on two F5 GTMs)

The devices hosting the delegated child domain both contain NS records
which match the parent's NS records for the child domain and they contain
glue records which also match the parent's A records for the NS records.

Here are my curiosities:

1) should the NS records for the delegated child domain be hosts which
reside in the parent domain or the delegated child domain? (or does it
matter as long as the glue is correct?)
gtm-int.example.org. IN NS gtm-int-east.example.org.
gtm-int.example.org. IN NS gtm-int-west.example.org.
gtm-int-east.example.org. IN A 203.0.113.53
gtm-int-west.example.org. IN A 198.51.100.53
-OR-
gtm-int.example.org. IN NS gtm-int-east.gtm-int.example.org
.
gtm-int.example.org. IN NS gtm-int-west.gtm-int.example.org
.
gtm-int-east.gtm-int.example.org . IN A
203.0.113.53
gtm-int-west.gtm-int.example.org . IN A
198.51.100.53

2) Do I need to specify a null forwarder statement for the parent domain?
(to prevent query forwarding to the delegated child domain)

Regards,

Bob
___
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: NTP through DNS?

[Bob McDonald]

Having multiple CNAME records for the same hsotname is a violation of
rfc1034. (that and bind9 won't allow it...)

Surely there must be some creative solution which doesn't a) violate the
DNS specs and b) doesn't suggest the use of deprecated software (bind8).

Regards,

Bob
___
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: how two dns bind master sync?

[Bob McDonald]

> This may be an unpopular opinion, especially on the BIND-Users mailing
> list (sometimes BIND is not the best answer).
>
> It sounds like you might want something like multi-master DNS servers
> that Active Directory (with AD integrated zones) provides.

Here's the Microsoft AD DNS explanation:
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/active-directory-integrated-dns-zones

This may be the time to start some dialogue around the way Bind processes
updates. While AD integrated DNS does process updates for multiple masters,
it does it outside the Bind-centric communications path. (I believe it uses
AD to forward updates from one master to the others). Bind needs some sort
of multi-master framework but there are a few issues if things stay the way
they are. There are obvious issues with serial number accounting and slave
notification. There are also issues with update processing (and
forwarding). Right now the only server that can accept updates is the
master. Forwarded updates are stamped as coming from the forwarding node.
That makes tracking updates almost impossible. (And that seems to be the
case for both signed and un-signed updates) I may be not seeing something
but from my point of view, that, above all else, must change if a
meaningful multi-master framework is to emerge.

Regards,

Bob
___
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: SRV record not working

[Bob McDonald]

> I know that most of you hate nslookup but I have been using it since the
> 90's and it's my go-to utility. I get the same responses whether I use
> Dig or nslookup. If nslookup doesn't return what I am looking for, I do
> use Dig also.

I don't think anyone hates nslookup (well maybe a few do ) I suppose
the immense dislike stems from the fact that it's the default utility under
Windows. Folks who use dig as their default realize that when used
properly, dig provides much more functionality than nslookup. For example,
try using TSIG with nslookup or getting a NSID response. These are only a
couple of examples. There's other reasons to change. The output from dig is
much more comprehensive. And, yes, if you install the bind tools from ISC
under Windows, dig works quite well.

Just my $.02

Bob
___
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: Local Slave copy of root zone

[Bob McDonald]

Thank you sir! I'll investigate the newer bind implementations.

Regards.

Bob

On Wed, Aug 15, 2018 at 12:41 PM Tony Finch  wrote:

> Bob McDonald  wrote:
>
> > I've recently been investigating having a local slave copy of the root
> zone
> > on a caching/forwarder type server.
>
> I do this on my toy server for various strange reasons, and although it
> has worked OK I'm not confident it's really solid enough for production.
>
> If you are running BIND 9.12 then its RFC 8198 implementation removes a
> lot of the benefits of having a local root (and it also works for the arpa
> zones).
>
> BIND 9.14 will have an improved local root implementation (called a
> "mirror" zone) which validates the zone so you don't blindly serve bogus
> data. The feature is available now in the 9.13 dev branch; I have not
> tried mirroring the arpa zones - the docs suggest that isn't a supported
> config for mirror zones.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> democracy, participation, and the co-operative principle
>
___
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

Local Slave copy of root zone

[Bob McDonald]

I've recently been investigating having a local slave copy of the root zone
on a caching/forwarder type server. I've even put the local slave copy of
the root zone into a separate view accessed via a different loopback
address. (An limited example of this exists on the ISC site)

My question is this. Is there any benefit to also hosting local slave
copies of arpa., in-addr.arpa., and ip6.arpa.? Although FreeBSD now comes
with unbound as it's default DNS software, installing bind yields an
example named.conf which floats the concept of the local slave copies of
the above zones. (That is what led me down this path...)

Anyone care to weigh in?

Regards,

Bob
___
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 can be a subdomain

[Bob McDonald]

Hmmm...  My understanding was that the only requirement was that the DNS
server pointed to by the AD DC (in this case the AD is managed by SAMBA)
had to be authoritative for the domain in DNS which represented the
matching AD domain. This was a common holy war between MCSE folks and Bind
groupies. If you drank the Microsoft cool aid in the early days, you
staunchly believed that DNS had to be AD integrated on the AD DCs. That's
just not the case.

Again that's my understanding.

Bob
___
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: request-nsid seems to not be working (Bind 9.11.3)

[Bob McDonald]

from the Bv9ARM: (9.11.3)

request-nsid
If yes, then an empty EDNS(0) NSID (Name Server Identifier) option is sent
with all
queries to authoritative name servers during iterative resolution. If the
authoritative
server returns an NSID option in its response, then its contents are logged
in the resolver
category at level info. The default is no.

Seems to suggest that they get logged at the info level.

Regards,

Bob

On Wed, May 16, 2018 at 3:18 PM, Bob McDonald <bmcdonal...@gmail.com> wrote:

> Is that a functionality change from previous versions? I seem to remember
> it working at the info level.
>
> I could be wrong...
>
> On Wed, May 16, 2018 at 3:09 PM, Tony Finch <d...@dotat.at> wrote:
>
>> Bob McDonald <bmcdonal...@gmail.com> wrote:
>>
>> > I have a server that has request-nsid yes; specified in the options
>> block
>> > within named.conf. However, I don't see the NSID responses in the
>> resolver
>> > channel log file.
>>
>> It only appears at debug level 3 or greater.
>>
>> Tony.
>> --
>> f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/
>> Malin, South Hebrides: Northerly 5 at first in east Malin, otherwise
>> variable
>> 3 or 4. Slight or moderate. Fair. Good.
>>
>
>
___
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: request-nsid seems to not be working (Bind 9.11.3)

[Bob McDonald]

Is that a functionality change from previous versions? I seem to remember
it working at the info level.

I could be wrong...

On Wed, May 16, 2018 at 3:09 PM, Tony Finch <d...@dotat.at> wrote:

> Bob McDonald <bmcdonal...@gmail.com> wrote:
>
> > I have a server that has request-nsid yes; specified in the options block
> > within named.conf. However, I don't see the NSID responses in the
> resolver
> > channel log file.
>
> It only appears at debug level 3 or greater.
>
> Tony.
> --
> f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/
> Malin, South Hebrides: Northerly 5 at first in east Malin, otherwise
> variable
> 3 or 4. Slight or moderate. Fair. Good.
>
___
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

request-nsid seems to not be working (Bind 9.11.3)

[Bob McDonald]

I have a server that has request-nsid yes; specified in the options block
within named.conf. However, I don't see the NSID responses in the resolver
channel log file. Anyone else see this behaviour? dig +nsid seems to work.

Regards,

Bob
___
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: notify explicit and also-notify

[Bob McDonald]

This gets much more involved the further downstream you go.

For example, when a downstream slave (true or stealth) provides transfers
to a further downstream slave (true or stealth), the notify options can get
a bit messy.

Bottom line is it requires some detailed analysis and probably some
pictures.

Regards,

Bob

On Fri, May 4, 2018 at 6:21 AM, Bob McDonald <bmcdonal...@gmail.com> wrote:

> This is my understanding of how Current (ver. 9.8 and above) ISC Bind
> works. It may or may not apply to older versions of ISC Bind and/or DNS
> resolver programs from other sources. This is only MY understanding. You
> are welcome to disagree and point out the folly of my understanding.
>
> There are several types of zones:
>
> 1) True Master - Defined in the zone block in the named.conf as a master
> AND appearing in the MNAME field in the SOA record of the zone.
>
> 2) Stealth Master - Defined in the zone block in the named.conf as a
> master AND NOT appearing in the MNAME field in the SOA record of the zone.
> NOT visible to clients. Requires update forwarding for DDNS updates.
>
> 3) Apparent Master - defined in the zone block in the named.conf as a
> slave AND appearing in the MNAME field in the SOA record of the zone.
> Although visible to clients, not really the master. Think of it as
> masquerading as the True Master in place of a Stealth Master.
>
> 4) True Slaves - Defined in the zone block in the named.conf as a slave
> AND appearing in the zone as part of the  NS RRset..
>
> 5) Stealth Slaves - Defined in the zone block in named.conf as a slave AND
> NOT appearing in the zone as part of the NS RRset. (e.g. authoritative for
> the zone yet not in the NS RRset)
>
> notify=no - Notifies are not sent. Updating is done via the zone refresh
> timers. (now there's something to explain to management...)
>
> notify=yes - notifies are sent to all servers appearing in the NS RRset
> (except the server identified in the MNAME field of the SOA record) and to
> the also-notify list
>
> notify=master-only - notifies are only sent to master servers. (still
> getting my head wrapped around this one)
>
> notify=explicit - notifies are ONLY sent to servers listed in the
> also-notify list.
>
> To complicate things further...  The notify option may also be specified
> in the zone statement, in which case it overrides the options notify
> statement. It would only be necessary to turn off this option if it caused
> slaves to crash.
>
> There is also an option:
>
> notify-to-soa -  If yes do not check the nameservers in the NS RRset
> against the SOA MNAME. Normally a NOTIFY message is not sent to the SOA
> MNAME (SOA ORIGIN) as it is supposed to contain the name of the ultimate
> master. Sometimes, however, a slave is listed as the SOA MNAME in hidden
> master configurations and in that case you would want the ultimate master
> to still send NOTIFY messages to all the nameservers listed in the NS RRset.
>
> So, the bottom line is that there are SEVERAL ways to make notifies (and
> therefore updates) flow through the environment.
>
> Once you get this figured out, add in allow-notify, allow-updates, and
> update-forwarding (just say no...). There are also other use cases for
> dial-up. etc.
>
> Also, authoritative means serving a valid copy of a specific zone. (e.g.
> the server has a copy of the zone file and has a valid definition in it's
> named.conf that matches one of the above defined types)
>
> Hope that helps.
>
> Regards,
>
> Bob
>
___
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: notify explicit and also-notify

[Bob McDonald]

This is my understanding of how Current (ver. 9.8 and above) ISC Bind
works. It may or may not apply to older versions of ISC Bind and/or DNS
resolver programs from other sources. This is only MY understanding. You
are welcome to disagree and point out the folly of my understanding.

There are several types of zones:

1) True Master - Defined in the zone block in the named.conf as a master
AND appearing in the MNAME field in the SOA record of the zone.

2) Stealth Master - Defined in the zone block in the named.conf as a master
AND NOT appearing in the MNAME field in the SOA record of the zone. NOT
visible to clients. Requires update forwarding for DDNS updates.

3) Apparent Master - defined in the zone block in the named.conf as a slave
AND appearing in the MNAME field in the SOA record of the zone. Although
visible to clients, not really the master. Think of it as masquerading as
the True Master in place of a Stealth Master.

4) True Slaves - Defined in the zone block in the named.conf as a slave AND
appearing in the zone as part of the  NS RRset..

5) Stealth Slaves - Defined in the zone block in named.conf as a slave AND
NOT appearing in the zone as part of the NS RRset. (e.g. authoritative for
the zone yet not in the NS RRset)

notify=no - Notifies are not sent. Updating is done via the zone refresh
timers. (now there's something to explain to management...)

notify=yes - notifies are sent to all servers appearing in the NS RRset
(except the server identified in the MNAME field of the SOA record) and to
the also-notify list

notify=master-only - notifies are only sent to master servers. (still
getting my head wrapped around this one)

notify=explicit - notifies are ONLY sent to servers listed in the
also-notify list.

To complicate things further...  The notify option may also be specified in
the zone statement, in which case it overrides the options notify
statement. It would only be necessary to turn off this option if it caused
slaves to crash.

There is also an option:

notify-to-soa -  If yes do not check the nameservers in the NS RRset
against the SOA MNAME. Normally a NOTIFY message is not sent to the SOA
MNAME (SOA ORIGIN) as it is supposed to contain the name of the ultimate
master. Sometimes, however, a slave is listed as the SOA MNAME in hidden
master configurations and in that case you would want the ultimate master
to still send NOTIFY messages to all the nameservers listed in the NS RRset.

So, the bottom line is that there are SEVERAL ways to make notifies (and
therefore updates) flow through the environment.

Once you get this figured out, add in allow-notify, allow-updates, and
update-forwarding (just say no...). There are also other use cases for
dial-up. etc.

Also, authoritative means serving a valid copy of a specific zone. (e.g.
the server has a copy of the zone file and has a valid definition in it's
named.conf that matches one of the above defined types)

Hope that helps.

Regards,

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

[Bob McDonald]

 I should have pointed out that BOTH servers have recursion turned on.

Yeah, I know about having DNSSEC-enable=yes to not break downstream
validation. (I inherited this setup...)

BOTH are internal DNS servers with access to the internet to query the
internet roots (no default forwarding active).

I suspect it's the issue of having the DNSSEC-enable set to off on server B
even though it's not validating. (But that's just a guess...)

Thanks,

Bob

On Wed, Apr 11, 2018 at 9:48 AM, Tony Finch <d...@dotat.at> wrote:

> Bob McDonald <bmcdonal...@gmail.com> wrote:
> >
> > Server A
> > DNSSEC=yes
> > DNSSEC-validation=yes
> > Valid trust anchor for the root zone
> > DNSSEC validation seems to work correctly
> > Zone one.com. is setup as a forward zone to server B
> >
> > Server B
> > DNSSEC=no
> > DNSSEC-validation=N/A
> > authoritative and the master for one.com.
>
> This setup will not work reliably: the target forwarding server has to be
> a recursive server, since the forwarding client will expect it to do full
> resolution of the query - following delegations, etc. I expect it will
> have funky interactions with DNSSEC validation (e.g. chasing DS records)
> but I have not experimented with this myself.
>
> Also, you should never turn off the `dnssec-enable` setting, since that
> prevents BIND from doing the right thing with RRSIG/NSEC/DS records. This
> will break downstream validation even if the server is not itself
> validating - that is, if you turn it off on an authoritative server, it
> cannot serve any signed zones.
>
> Tony.
> --
> f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/
> Southeast Malin: Easterly 5 to 7. Slight or moderate, becoming moderate or
> rough. Mainly fair. Good.
>
___
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 Question

[Bob McDonald]

Consider the follwing example:

Server A
DNSSEC=yes
DNSSEC-validation=yes
Valid trust anchor for the root zone
DNSSEC validation seems to work correctly
Zone one.com. is setup as a forward zone to server B

Server B
DNSSEC=no
DNSSEC-validation=N/A
authoritative and the master for one.com.

When server A has DNSSEC turned on, requests for resolution of hosts in
zone one.com. get a SERVFAIL response (DNSSEC Signature issues).

When server A has DNSSEC turned off, requests for resolution of hosts in
zone one.com. succeed.

While I can fix the errors by turning DNSSEC off on server A, I'd like to
enable DNSSEC validation at some point in the not too distant future. Both
servers are running bind 9.10. Am I missing something?

Regards,

Bob
___
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: "Hiding" version.bind in /etc/bind/named.conf.options doesn't work

[Bob McDonald]

Personally, I leave the version statement alone. I like having my
"internal" servers return the current running version when queried. I
disable chaos queries on my internet facing servers via views thus
effectively not answering any queries for the version or hostname  from
folks I don't know. I agree that today's attackers really don't care, they
just try to exploit everything known.

The other thing I do is code server-id=hostname; on my "internal" servers
and server-id=; on my internet facing servers. This
returns the actual hostname for "internal" servers when queried for the
chaos hostname.bind or id.server or  when repomding to a +nsid request. It
will not return an answer for chaos queries on the internet facing servers
(because of the previously mentioned view restriction) while the response
to a +nsid request will be a meaningful name. This is especially handy on
the "inside" for HA clusters and anycast cloud member servers as it returns
the actual server name the response came from. For internet facing queries
it will simply return the meaningful name you specified when responding to
a +nsid request. Depending on the name chosen, this can be useful for
troubleshooting. Choose wisely.

YMMV,

Bob
___
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: Max slaves limit?

[Bob McDonald]

Mea culpa of the Windows process. I should have indicated that as well.
Also I was remiss on not mentioning the MINIMAL-RESPONSES option in the
discussion. It sounds like there are some newer options available under
bind 9.11 and up (Thanks Mr. Andrews!)

That's why I read this list. It's a great source of information. Thanks
again.

Best,

Bob
___
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: Max slaves limit?

[Bob McDonald]

Barry has a good point. I've seen cases where folks have added all of the
Domain Controller addresses for an AD forest to the NS list for a domain.
This results in huge TCP response packets for ALL requests to that domain.
Folks don't seem to get the concept of stealth slaves and the associated
NOTIFY options to keep things current. (As an alternative to shortening the
REFRESH time for a domain)

Best,

Bob
___
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: problem domains host in ns1/ns2.planetdomain.com (Eric Yiu)

[Bob McDonald]

On first glance it looks like although the domain registration points to
the DNS servers at planetdomain.com., the actual domain has NS records (and
an MNAME entry in the SOA) which point to DNS servers at netregistry.net.

Anyone else have different results?

Regards,

Bob
___
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: ACL

[Bob McDonald]

I think what you are looking for is:

acl test0 { !192.168.1.50/32; 192.168.1.0/24; };

http://jodies.de/ipcalc is a good resource for checking. (As was mentioned
by Reindl...)

Learning basic sub-netting of IP addresses (Both IPv4 and IPv6) takes time
but it's necessary for DNS configuration. There's plenty of other resources
out there. (Try googling sub-netting with or without the hyphen)

Hope that helps,

Bob

> Message: 1
> Date: Sat, 8 Oct 2016 15:14:36 +0200
> From: Pol Hallen 
> To: Bind Users 
> Subject: acl
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi all :-)
>
> can someone advice me about a fully howto / handbook to understand ACL?
>
> I need to permit all network 192.168.1/24 and deny 192.168.1.50/24 host:
>
> acl test0 { !192.168.1.50/24; 192.168.1/24;};
>
> thanks for help!
>
> Pol
___
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: Delegation questions

[Bob McDonald]

> Your problem here is not directly related to the delegation.  Your
problem is that you have a recursive server (C) which is blocked from
reaching a part of the Internet
> where there is an authoritative server (B) it needs to contact.

I thought I had said that...

> That's a very convoluted way of fixing what is simply a bug in your
firewall configuration.

Maybe. Perhaps I don't have direct control over the firewalls and it will
take a (sometimes extended) period of time to get them changed. Perhaps I'm
looking for a temporary solution.

I'm just looking for an answer as to whether or not this might work. I'm ok
either way. Just curious.

Thanks for the replies.

Bob

On Thu, Aug 11, 2016 at 12:21 PM, Matthew Pounsett <m...@conundrum.com>
wrote:

>
>
> On 11 August 2016 at 10:14, Bob McDonald <bmcdonal...@gmail.com> wrote:
>
>>
>> Currently, clients sending queries for domain child.example.com. to
>> server A get good results.
>> However, clients sending queries for domain child.example.com. to server
>> C get SERVFAIL because server C has no access to server B. (I'm guessing
>> there is a firewall issue)
>>
>
> Your problem here is not directly related to the delegation.  Your problem
> is that you have a recursive server (C) which is blocked from reaching a
> part of the Internet where there is an authoritative server (B) it needs to
> contact.
>
> If these servers are not listed in the stub resolvers of systems as their
> local recursors, then turn off recursion on the servers.  Otherwise, open
> up your firewall rules to allow your recursive servers to reach the entire
> Internet, and the entire Internet to reach your authoritative servers.
>
>
>>
>> The question is if I get rid of the delegation and put in a stub zone on
>> server A pointing to child.example.com. on server B, can I use
>> forwarders for child.example.com. on server C to point at server A for
>> resolution of child.example.com.? (Will server A get answers directly
>> from server B or will server A simply refer me to server B?)
>>
>
> That's a very convoluted way of fixing what is simply a bug in your
> firewall configuration.
>
>
>
___
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: Delegation questions

[Bob McDonald]

Let me be a bit more clear...

This is strictly internal. There are no external clients or servers
involved. All three of the servers have recursion turned ON.

Server A has a domain (example.com.)
example.com. has an NS record that points to server B and delegate
child.example.com. (yes there's really two, this is just an example)

Server B is at another company. (probably connected via some sort of IPSEC
tunnel)

Server C has a slave copy of example.com. from server A (and the associated
NS record delegating child.example.com. to server B)
Server C is at another site at the same company as server A

Currently, clients sending queries for domain child.example.com. to server
A get good results.
However, clients sending queries for domain child.example.com. to server C
get SERVFAIL because server C has no access to server B. (I'm guessing
there is a firewall issue)

The question is if I get rid of the delegation and put in a stub zone on
server A pointing to child.example.com. on server B, can I use forwarders
for child.example.com. on server C to point at server A for resolution of
child.example.com.? (Will server A get answers directly from server B or
will server A simply refer me to server B?)

Hope that's clearer.

Bob


On Thu, Aug 11, 2016 at 11:52 AM, Matthew Pounsett <m...@conundrum.com>
wrote:

>
>
> On 11 August 2016 at 09:13, Bob McDonald <bmcdonal...@gmail.com> wrote:
>
>> I have a child domain that is delegated to a second site. Pretty
>> straightforward situation. In the parent zone I have NS records that point
>> to the DNS servers at the second site.
>>
>> The issue comes up when a slaved copy of the parent domain is running at
>> a third site and that third site doesn't have a rule in their firewall
>> allowing DNS access to the second site (where the child domain is
>> delegated).
>>
>> The question is this; can I use stub zones to reference the child domain
>> on the master server (instead of delegation) and the use forwarding at the
>> third site to direct queries for the child domain through the master
>> server?
>>
>> I hope the picture I've tried to describe is somewhat clear.
>>
>
> If the setup is exactly as you describe, then there's probably no reason
> for a name server authoritative for the parent zone to ever need to contact
> a server authoritative for the child zone.  Delegation from A to B doesn't
> imply direct communication between A and B.
>
> That said, you never know where on the Internet queries for a zone will
> arrive from.  If you want the Internet at large to be able to resolve names
> in your zone, then you can't firewall yourself off from parts of the
> Internet.
>
> If any of the servers in this scenario are also acting as recursive
> servers, then you have the same problem;  you never know where on the
> Internet an authoritative server you need to speak to is going to be, so
> you can't firewall your recursive server off from speaking to parts of the
> Internet and expect it to work reliably.
>
>
>
>
>>
>> Regards,
>>
>> Bob
>>
>> ___
>> 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

Delegation questions

[Bob McDonald]

I have a child domain that is delegated to a second site. Pretty
straightforward situation. In the parent zone I have NS records that point
to the DNS servers at the second site.

The issue comes up when a slaved copy of the parent domain is running at a
third site and that third site doesn't have a rule in their firewall
allowing DNS access to the second site (where the child domain is
delegated).

The question is this; can I use stub zones to reference the child domain on
the master server (instead of delegation) and the use forwarding at the
third site to direct queries for the child domain through the master
server?

I hope the picture I've tried to describe is somewhat clear.

Regards,

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

Questions about .ro domain

[Bob McDonald]

I'm having issues with resolution of a domain in the .ro TLD.

See below:

; <<>> DiG 9.9.5-P1 <<>> @127.0.0.1 ns01.ebsromania.ro. +trace
; (1 server found)
;; global options: +cmd
.   263965  IN  NS  a.root-servers.net.
.   263965  IN  NS  j.root-servers.net.
.   263965  IN  NS  i.root-servers.net.
.   263965  IN  NS  d.root-servers.net.
.   263965  IN  NS  m.root-servers.net.
.   263965  IN  NS  b.root-servers.net.
.   263965  IN  NS  h.root-servers.net.
.   263965  IN  NS  c.root-servers.net.
.   263965  IN  NS  g.root-servers.net.
.   263965  IN  NS  e.root-servers.net.
.   263965  IN  NS  k.root-servers.net.
.   263965  IN  NS  f.root-servers.net.
.   263965  IN  NS  l.root-servers.net.
.   264673  IN  RRSIG   NS 8 0 518400
2016022205 2016021204 54549 .
Qff4Qwn6BpFTL4MJy/ztLc+bH1PIMoNf00tfGvClLJ26IiodlKpl4Kvb
bE/tWr1JsDg3uilNAG6nR967VufWZYhNngBNpGdYXMi+GTaM8o/R7wHL
XIeijMj9v7tbNQza7JVMwxc/vF2nP4+xajbSiTZDDQeslkdpZJLl3njD Nw4=
;; Received 397 bytes from 127.0.0.1#53(127.0.0.1) in 6 ms

ro. 172800  IN  NS  dns-ro.denic.de.
ro. 172800  IN  NS  sec-dns-a.rotld.ro.
ro. 172800  IN  NS  dns-at.rotld.ro.
ro. 172800  IN  NS  sec-dns-b.rotld.ro.
ro. 172800  IN  NS  primary.rotld.ro.
ro. 172800  IN  NS  sns-pb.isc.org.
ro. 86400   IN  NSECrocher. NS RRSIG NSEC
ro. 86400   IN  RRSIG   NSEC 8 1 86400
2016022505 2016021504 54549 .
LKnWJRnQdMQ67X7PVrChhY0CuT+A0hpLv1Yh2zOrdglKGGYFQGP+sO24
A31Uj9g8SAKroH1XlJD000bhm+jTkd9Suf1uefDC8y3hV1HlmwkAzoIE
cPQ1rKj66R0kVrEfsSYoXK7pau/mq583n7Hw24H6SSuWivQNbHUD+FLt 9rQ=
;; Received 624 bytes from 192.33.4.12#53(c.root-servers.net) in 7 ms

ebsromania.ro.  86400   IN  NS  ns02.ebsromania.ro.
ebsromania.ro.  86400   IN  NS  ns01.ebsromania.ro.
;; Received 112 bytes from 193.230.31.230#53(sec-dns-b.rotld.ro) in 20151 ms

;; connection timed out; no servers could be reached


The server running the dig is in the US while a server in NL produces this:

; <<>> DiG 9.9.5-P1 <<>> @127.0.0.1 ns01.ebsromania.ro. +trace
; (1 server found)
;; global options: +cmd
.   92407   IN  NS  m.root-servers.net.
.   92407   IN  NS  b.root-servers.net.
.   92407   IN  NS  c.root-servers.net.
.   92407   IN  NS  g.root-servers.net.
.   92407   IN  NS  h.root-servers.net.
.   92407   IN  NS  j.root-servers.net.
.   92407   IN  NS  l.root-servers.net.
.   92407   IN  NS  a.root-servers.net.
.   92407   IN  NS  d.root-servers.net.
.   92407   IN  NS  e.root-servers.net.
.   92407   IN  NS  i.root-servers.net.
.   92407   IN  NS  f.root-servers.net.
.   92407   IN  NS  k.root-servers.net.
.   518398  IN  RRSIG   NS 8 0 518400
2016022505 2016021504 54549 .
Sh3DsQaxrP1CC31ZxY3fzM2QHKGdZ0sKb3DxI1G974dvdxLubBK7vG5N
4A+Cshd8ci/zQmJw6ASWeYL5uUFrS4szqr05FMS8oNLLntbVVWoQTPld
X+vfmAZo8wQPrVqBHwxJyFucJrWFZN4rWUdhvxrbkoMbYpeqDHGCDioR oow=
;; Received 397 bytes from 127.0.0.1#53(127.0.0.1) in 1124 ms

ro. 172800  IN  NS  dns-at.rotld.ro.
ro. 172800  IN  NS  dns-ro.denic.de.
ro. 172800  IN  NS  sns-pb.isc.org.
ro. 172800  IN  NS  primary.rotld.ro.
ro. 172800  IN  NS  sec-dns-a.rotld.ro.
ro. 172800  IN  NS  sec-dns-b.rotld.ro.
ro. 86400   IN  NSECrocher. NS RRSIG NSEC
ro. 86400   IN  RRSIG   NSEC 8 1 86400
2016022505 2016021504 54549 .
LKnWJRnQdMQ67X7PVrChhY0CuT+A0hpLv1Yh2zOrdglKGGYFQGP+sO24
A31Uj9g8SAKroH1XlJD000bhm+jTkd9Suf1uefDC8y3hV1HlmwkAzoIE
cPQ1rKj66R0kVrEfsSYoXK7pau/mq583n7Hw24H6SSuWivQNbHUD+FLt 9rQ=
;; Received 624 bytes from 198.97.190.53#53(h.root-servers.net) in 436 ms

ebsromania.ro.  86400   IN  NS  ns02.ebsromania.ro.
ebsromania.ro.  86400   IN  NS  ns01.ebsromania.ro.
;; Received 112 bytes from 192.162.16.18#53(primary.rotld.ro) in 147 ms

ns01.ebsromania.ro. 86400   IN  A   193.239.218.2
ebsromania.ro.  

RE: Query on ignoring additional section returned in replies

[Bob McDonald]

Is this hosted on some sort of load-balancer?

Add a +norecurse to your dig and see how that changes things.

Regards,

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

Options for non-recursive servers

[Bob McDonald]

for non-recursive (authoritative only) servers I have:

options {
directory "/var/cache/bind";
allow-query { any; };
allow-query-cache { none; };
allow-recursion { none; };
listen-on { 127.0.0.1; };
listen-on { 172.26.99.117; };
listen-on-v6 { none; };
empty-zones-enable no;
recursion no;
masterfile-format text;
minimal-responses no,
transfer-source 172.26.99.117;
notify-source 172.26.99.117;
query-source address 172.26.99.117;
server-id "registered-NS-server-name";
zone-statistics full;
dnssec-enable yes;
dnssec-validation auto;
};

view "default" IN {
match-clients { any; };

include "/etc/bind/named.conf.default-zones";

};

view bind chaos {
match-clients { any; };
recursion no;
allow-query { 127.0.0.1; internal-networks; none; };
allow-recursion { none; };
zone  authors.bind ch { type master; database "_builtin authors";
 };
zone hostname.bind ch { type master; database "_builtin hostname";
};
zone  version.bind ch { type master; database "_builtin version";
 };
zone id.server ch { type master; database "_builtin id";
};
zone   "." ch { type hint;   file "/dev/null";
};
};

Note: There is actually only one interface with an inside address.. It's
NATed to the outside address (query-source). Several options are defaults
and specified for clarity.

Does anything jump out as being incorrect? Are there implications to
setting minimal-responses to yes?

Thanks,

Bob
___
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: Troubleshooting Information

[Bob McDonald]

It appears that receiving an NSID response depends on having server-id set
in the options block. However, I'm seeing no way to restrict such queries.

regards,

Bob

On Fri, Aug 28, 2015 at 7:48 AM, Bob McDonald bmcdonal...@gmail.com wrote:

 No, and there seems to be sparse documentation of the use of NSID in
 troubleshooting. I'm all ears. I would. however, like to restrict queries
 to inside networks/users and negate access to that data from the outside
 altogether.

 TIA,

 Bob

 Alan Clegg wrote:

  Has anyone recommended doing debugging via NSID instead of the CH class
  data?



___
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: Troubleshooting Information

[Bob McDonald]

No, and there seems to be sparse documentation of the use of NSID in
troubleshooting. I'm all ears. I would. however, like to restrict queries
to inside networks/users and negate access to that data from the outside
altogether.

TIA,

Bob

Alan Clegg wrote:

 Has anyone recommended doing debugging via NSID instead of the CH class
 data?
___
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: Troubleshooting Information

[Bob McDonald]

If I set this up as follow, it works.

view bind chaos {
recursion no;
allow-query { 127.0.0.1; none; };
zone  authors.bind ch { type master; database _builtin authors;  };
zone hostname.bind ch { type master; database _builtin hostname; };
zone  version.bind ch { type master; database _builtin version;  };
zone id.server ch { type master; database _builtin id;   };
};

Queries from 127.0.0.1 are answered correctly, queries from anywhere else
are met with a REFUSED reply.

However, the answers show as coming from view bind in the statistics.
There is also a view named _bind which seems to serve those same zones.
(named won't start if I try to name the view _bind.)

I can get answers from the zones in view _bind if I accept/reject via the
match-clients statement. If I also remove the zones from view bind, it
returns a SERFAIL to queries for selected devices in that view of class
chaos. I think I understand this last one.

Setting recursion off does not seem to affect the warning message generated
by omitting the root hints zone for class chaos.

Bob


On Wed, Aug 26, 2015 at 5:50 AM, Bob McDonald bmcdonal...@gmail.com wrote:

 The warning is issued either way (with or without recursion specified).
 But I see the logic in not needing it if recursion is set to no.

 Thanks again,

 Bob

 On Wed, Aug 26, 2015 at 5:45 AM, Tony Finch d...@dotat.at wrote:

 Bob McDonald bmcdonal...@gmail.com wrote:
 
  I'd still include the hint zone (as I'm partial to not having
 unnecessary
  warnings on startup).

 The recursion no directive means you shouldn't have a hint zone in that
 view. (I don't know if it will complain about the inconsistency.)

  Also a lot of folks use localhost and/or localnets in DNS configuration.
  Just from a security standpoint, I prefer to be more specific. localhost
  and/or localnets can be much more template friendly, I know.

 I just used them as placeholders since they are used in the default ACLs
 :-)

 Tony.
 --
 f.anthony.n.finch  d...@dotat.at  http://dotat.at/
 Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
 moderate, but rough in southwest Viking. Showers later. Good, occasionally
 poor later.



___
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: Troubleshooting Information

[Bob McDonald]

That's brilliant! Thanks.

I'd still include the hint zone (as I'm partial to not having unnecessary
warnings on startup).

Also a lot of folks use localhost and/or localnets in DNS configuration.
Just from a security standpoint, I prefer to be more specific. localhost
and/or localnets can be much more template friendly, I know.

However, your suggestion changes my response for excluded addresses from
SERVFAIL to REFUSED. Much better.

Cheers!

On Wed, Aug 26, 2015 at 5:02 AM, Tony Finch d...@dotat.at wrote:

 Bob McDonald bmcdonal...@gmail.com wrote:

  To further lock this information down I would suggest adding the
  following view statements to any internet facing DNS device
 configuration:
 
  view outsiders chaos {
  match-clients { !127.0.0.1; !your-inside--nets; any; };
  allow-query { none; };
  # we need a zone within a view and Bind complains on startup if there is
 no hint file in classes
  #  other than internet. (it is provided with the software for the
 internet class)
  zone . chaos {
  type hint;
  file /dev/null;  // or any empty file
  };
 
  };

 Another way is to use BIND's syntax for explicitly configuring the special
 server information zones, like below. This view handles all queries for
 the chaos class, and rejects queries from nonlocal clients.

   view bind chaos {
 recursion no;
 allow-query { localhost; localnets; };
 zone  authors.bind ch { type master; database _builtin authors;  };
 zone hostname.bind ch { type master; database _builtin hostname; };
 zone  version.bind ch { type master; database _builtin version;  };
 zone id.server ch { type master; database _builtin id;   };
   };

 Tony.
 --
 f.anthony.n.finch  d...@dotat.at  http://dotat.at/
 Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
 moderate, but rough in southwest Viking. Showers later. Good, occasionally
 poor later.

___
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

Troubleshooting Information

[Bob McDonald]

Bind 9 provides configurable hosts within the chaos class which can be
queried to provide troubleshooting infornation. They are:

version.bind
hostname.bind

These are all configurable within the options block of the DNS
configuration file. In the past, the suggestion was to specify something
other than the actual version, obscuring the version information and
misleading would be hackers. The other option is to specify version none;
and hostname none; effectively turning them off. (Notice none is specified
without quotes) My contention is that by allowing version and hostname to
default, Bind 9 will produce some useful troubleshooting information.
(Currently running version information of Bind 9 and the hostname of the
host on which it is running) This can be queried via a dig request to class
chaos, type txt as below:

dig version.bind ch txt +norecurse

This is especially useful information to know when troubleshooting a device
that lives within an anycast cloud.

Specifying the options as described above yeilds useful information about
servers to troubleshooters. However, it also yields the same information to
any inquisitve client that can access the DNS device. While that may not be
an issue on inside networks, it poses a major security hole for DNS devices
with access from the internet (authoritative and/or recursive edge
servers). To further lock this information down I would suggest adding the
following view statements to any internet facing DNS device configuration:

view outsiders chaos {
match-clients { !127.0.0.1; !your-inside--nets; any; };
allow-query { none; };
# we need a zone within a view and Bind complains on startup if there is no
hint file in classes
#  other than internet. (it is provided with the software for the internet
class)
zone . chaos {
type hint;
file /dev/null;  // or any empty file
};

};

This view excludes 127.0.0.1 and your inside network (specified in an ACL)
and matches every other address. This effectively negates queries to the
chaos class for addresses outisde of your network and allows them from
address you specify.

id.server is another host that can be queried in the chaos class. It
defaults to server-id none; in the options block of the configuration file.
See the Bind Version 9 Administrator's Reference Manual for more
information.

Caveats: This only works for appropriate levels of ISC Bind 9 software.
While it may work with other packages, I have not tested it. Also, this
example has not been vetted with IPv6. This is an example only. It implies
no gaurantee of security. Any errors, especially in spelling or grammar,
are par for the course. I code for a living, I don't write.
___
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: Troubleshooting Information

[Bob McDonald]

The warning is issued either way (with or without recursion specified). But
I see the logic in not needing it if recursion is set to no.

Thanks again,

Bob

On Wed, Aug 26, 2015 at 5:45 AM, Tony Finch d...@dotat.at wrote:

 Bob McDonald bmcdonal...@gmail.com wrote:
 
  I'd still include the hint zone (as I'm partial to not having unnecessary
  warnings on startup).

 The recursion no directive means you shouldn't have a hint zone in that
 view. (I don't know if it will complain about the inconsistency.)

  Also a lot of folks use localhost and/or localnets in DNS configuration.
  Just from a security standpoint, I prefer to be more specific. localhost
  and/or localnets can be much more template friendly, I know.

 I just used them as placeholders since they are used in the default ACLs
 :-)

 Tony.
 --
 f.anthony.n.finch  d...@dotat.at  http://dotat.at/
 Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
 moderate, but rough in southwest Viking. Showers later. Good, occasionally
 poor later.

___
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: 9.10.2-P2 not receiving/logging inbound queries.

[Bob McDonald]

Is SELINUX enabled on the server? (several of the red hat centric distros
have it enabled by default.) That would cause the server to act as if it
were running normally while not accepting queries.

Regards,

Bob

Message: 2
Date: Fri, 10 Jul 2015 08:42:32 +1000
From: Neil nei...@iprimus.com.au
To: 'Tony Finch' d...@dotat.at
Cc: bind-users@lists.isc.org
Subject: RE: 9.10.2-P2 not receiving/logging inbound queries.
{REP=5.6}
Message-ID: 02dc01d0ba98$8bca4a30$a35ede90$@iprimus.com.au
Content-Type: text/plain;   charset=us-ascii

Yes

-Original Message-
From: Tony Finch [mailto:fa...@hermes.cam.ac.uk] On Behalf Of Tony Finch
Sent: Thursday, 9 July 2015 7:50 PM
To: Neil
Cc: bind-users@lists.isc.org
Subject: Re: 9.10.2-P2 not receiving/logging inbound queries. {REP=5.6}

Neil nei...@iprimus.com.au wrote:

 What would cause a query to not show in any logs on BIND 9.10.2-p2,
 seems
 9.10.2-p2 is not receiving

Is your server able to make queries over TCP?

Tony.
___
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: Reciving Timeout from DNS Server for a zone file Not present in named.conf.

[Bob McDonald]

1) status REFUSED - server with recursion turned off. with or without
+norecurse on the dig command.
2) status NXDOMAIN - server with recursion turned on with or without
+norecurse on the dig command (and access to the internet in my case)
3) status may be NOERROR depending on if a forwarder can resolve that zone.

I'm on ubuntu with bind 9.9.5 (current level of bind9  from ubuntu 14.04.02
LTS)

4) Forgive my being a bit naive but isn't it e164.arpa. instead of e164.ld.
?  l don't recall ld being a valid TLD. (That might affect your response)
5) YMMV with other Linux distros or other unixes because of differing bind
versions (but probably not)

Regards,

Bob


Message: 5
Date: Wed, 08 Jul 2015 12:38:20 -0400
From: Barry Margolin bar...@alum.mit.edu
To: comp-protocols-dns-b...@isc.org
Subject: Re: Receiving Timeout from DNS Server for a zone file Not
   present in  named.conf
Message-ID: barmar-25f285.12382008072...@88-209-239-213.giganet.hu

In article mailman.2239.1436350643.26362.bind-us...@lists.isc.org,
Harshith Mulky harshith.mu...@outlook.com wrote:

 Hello,
 I have a query here,
 I have named.conf configured But I do not have zone file configured for a
 domain name as e164.ld
 I am sending out a query asdig @DNS Server IP
 8.7.9.8.6.0.3.6.6.9.1.e164.ld. NAPTR
 ;  DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 
 8.7.9.8.6.0.3.6.6.9.1.e164.ld.  NAPTR;; global options: +cmd;; connection
 timed out; no servers could be reached
 I am receiving  a Connection TimeOut message
 Should not i be receiving a NXDOMAIN response from DNS Server?
 What are the scenarios, I will be receiving a Timeout, or a NXDOMAIN, or
a
 REFUSED from DNS Server
 I have Installed BIND on RHEL system! Would the reposnes be different in
 different servers like Linux, Solaris, CENTOS?

Since you didn't use the +norecurse option, the server will try to make
a recursive query for you (assuming you're in its allow-recursion access
list). If dig times out before that completes, you'll get a timeout
error.

--
Barry Margolin
Arlington, MA
___
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: bind-web-based control panel (Ejaz)

[Bob McDonald]

There are several companies that sell IPAM (IP address management)
solutions around the world. One of the side benefits, along with IP address
management, is the configuration and management of DNS and DHCP (as well as
in some cases, NTP). They also can provide hardware platforms for running
DNS and/or DHCP.

Email me separately for a short list.

Regards,

Bob


Message: 4
Date: Tue, 7 Jul 2015 12:26:01 +0300
From: Ejaz me...@cyberia.net.sa
To: bind-users@lists.isc.org
Subject: bind-web-based control panel
Message-ID: 18f101d0b896$f3955640$dac002c0$@cyberia.net.sa
Content-Type: text/plain; charset=us-ascii

All.



Dees bind support for  web-based  control panel? I need one that can
automatically push updates to both the master and slave servers, as well as
having logins for customers to modify their zone information.



Regards,

Mohammed Ejaz

CYBERIAR SAUDI ARABIA

P.O.Box 301079, Riyadh 11372, Saudi Arabia

Tel: +966 11 464 7114 Ext. 140

Fax: +966 11 465 4735
___
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: RPZ Question

[Bob McDonald]

I have not yet received an answer to my query. It appears that when using
RPZ to return bogus addresses it will respond to queries for CNAME, MX, and
SRV records. However, if the target name of those records is expected to
resolve outside of RPZ, then the name needs to be terminated with a period
(normal FQDN). If the target name is in RPZ it should not be terminated
with a period. Apparently when doing the recursion required to resolve the
target names, bind doesn't use RPZ. Is this the correct behaviour? Details
are in my previous posts.

Regards,

Bob

On Thu, Apr 16, 2015 at 2:07 PM, Bob McDonald bmcdonal...@gmail.com wrote:

 Requested information:

 options {
directory /opt/incontrol/dns/db;
allow-query {  127.0.0.1; rfc1918-nets; };
also-notify {   172.26.100.10 port 5053  ;   172.26.100.11  ; };
listen-on { 127.0.0.1; };
listen-on { 172.26.99.160; };
listen-on-v6 { none; };
masterfile-format text;
empty-zones-enable no;
notify-source 172.26.99.160  ;
version none;
server-id hostname ;
query-source address 172.26.99.160  ;
forward only  ;
forwarders {   172.26.1.9; 172.26.1.12; };
allow-notify {  any ; };
allow-transfer {  any; };
allow-update { any ; };
response-policy {  zone rpz-zone01policy given max-policy-ttl 28800  ;
   zone rpz-zone02policy given max-policy-ttl 28800
  ; };
notify explicit  ;
transfer-source 172.26.99.160  ;
check-names master  warn   ;
check-names slave  warn   ;
pid-file /opt/incontrol/etc/named.pid;
 };
 zone rpz-zone01  {
type master;
file db.rpz-zone01;
forwarders { };
 };

 zone rpz-zone02  {
type master;
file db.rpz-zone02;
forwarders { };
 };

 $TTL 28800

 @ IN SOA sapphire-x5-agent.pcn.local. hostmaster.pcn-inc.com. (
  9 ; Serial
  86400; Refresh
  900  ; Retry
  360 ; Expire
  300 ); Negative cache TTL

 ;-
 ; NS Records
 ;-
 NS  sapphire-x5-agent.pcn.local.
 NS  sapphire-agent-00.pcn.local.
 sapphire-x5-agent.pcn.local.  IN A  172.26.99.160
 sapphire-agent-00.pcn.local.  IN A  172.26.100.11

 ;-
 ; Resource Records for rpz-zone02.
 ;-
 $ORIGIN rpz-zone02.
 $TTL 28800

 www.arqiva.com  28800  IN CNAME  www.arqiva-integration.com.
 www.arqiva-integration.com  28800  IN A  83.138.41.100


 Let me know what else you need.

 Regards,

 Bob



___
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

RPZ Question

[Bob McDonald]

I'm using RPZ to return fake addresses for hosts. Although it seems to
work well for A records, I'm questioning the way it processes CNAME records.

Shown below is the output from DIG. Both records are in RPZ. However,
you'll notice that the first DIG returns a NXDOMAIN response.  The CNAME
target is also in RPZ (As shown in the second DIG)

Is this normal behaviour?

I'd also like to know if it's possible to generate fake resposes for MX,
NS, and/or SRV records.

Regards,

Bob

operator@sapphire-x5-agent:/home/operator /opt/incontrol/dns/bin/dig @
127.0.0.1 www.arqiva.com.

;  DiG 9.9.6-P2  @127.0.0.1 www.arqiva.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 64951
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.arqiva.com.IN  A

;; ANSWER SECTION:
www.arqiva.com. 28800   IN  CNAME   www.arqiva-integration.com.

;; AUTHORITY SECTION:
com.361 IN  SOA a.gtld-servers.net.
nstld.verisign-grs.com. 1429203602 1800 900 604800 86400

;; Query time: 90 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Apr 16 13:09:19 EDT 2015
;; MSG SIZE  rcvd: 153

operator@sapphire-x5-agent:/home/operator /opt/incontrol/dns/bin/dig @
127.0.0.1 www.arqiva-integration.com.

;  DiG 9.9.6-P2  @127.0.0.1 www.arqiva-integration.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 506
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.arqiva-integration.com.IN  A

;; ANSWER SECTION:
www.arqiva-integration.com. 28800 INA   83.138.41.100

;; AUTHORITY SECTION:
rpz-zone02. 28800   IN  NS  sapphire-agent-00.pcn.local.
rpz-zone02. 28800   IN  NS  sapphire-x5-agent.pcn.local.

;; Query time: 87 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Apr 16 13:16:50 EDT 2015
;; MSG SIZE  rcvd: 154
___
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: RPZ Question

[Bob McDonald]

Requested information:

options {
   directory /opt/incontrol/dns/db;
   allow-query {  127.0.0.1; rfc1918-nets; };
   also-notify {   172.26.100.10 port 5053  ;   172.26.100.11  ; };
   listen-on { 127.0.0.1; };
   listen-on { 172.26.99.160; };
   listen-on-v6 { none; };
   masterfile-format text;
   empty-zones-enable no;
   notify-source 172.26.99.160  ;
   version none;
   server-id hostname ;
   query-source address 172.26.99.160  ;
   forward only  ;
   forwarders {   172.26.1.9; 172.26.1.12; };
   allow-notify {  any ; };
   allow-transfer {  any; };
   allow-update { any ; };
   response-policy {  zone rpz-zone01policy given max-policy-ttl 28800  ;
  zone rpz-zone02policy given max-policy-ttl 28800  ;
};
   notify explicit  ;
   transfer-source 172.26.99.160  ;
   check-names master  warn   ;
   check-names slave  warn   ;
   pid-file /opt/incontrol/etc/named.pid;
};
zone rpz-zone01  {
   type master;
   file db.rpz-zone01;
   forwarders { };
};

zone rpz-zone02  {
   type master;
   file db.rpz-zone02;
   forwarders { };
};

$TTL 28800

@ IN SOA sapphire-x5-agent.pcn.local. hostmaster.pcn-inc.com. (
 9 ; Serial
 86400; Refresh
 900  ; Retry
 360 ; Expire
 300 ); Negative cache TTL

;-
; NS Records
;-
NS  sapphire-x5-agent.pcn.local.
NS  sapphire-agent-00.pcn.local.
sapphire-x5-agent.pcn.local.  IN A  172.26.99.160
sapphire-agent-00.pcn.local.  IN A  172.26.100.11

;-
; Resource Records for rpz-zone02.
;-
$ORIGIN rpz-zone02.
$TTL 28800

www.arqiva.com  28800  IN CNAME  www.arqiva-integration.com.
www.arqiva-integration.com  28800  IN A  83.138.41.100


Let me know what else you need.

Regards,

Bob
___
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: Cannot get allow-query-on to work.

[Bob McDonald]

Did you specify 127.0.0.1 in the listen-on options statement?

 I am using Ubuntu 12.04.4, BIND 9.8.1-P1, and just added:

 allow-query-on { 127.0.0.1; };

 To the default /etc/bind/named.conf.options file.
 That should make it only answer queries sent to 127.0.0.1, and not answer
 queries sent to the server's normal IP.  But it seems to have no effect.

 I have tried putting the computer's real IP in there instead - same
results
 - both IP's answer queries.

 I have tried the similar allow-recursion-on option and that works as
 documented.

 Any clue how to get allow-query-on to work?
 Searching the mail archives and Google did not find anything - but it is
 hard to filter on just allow-query-on as a complete string.
 Has anyone even used that option?

 --
 Bob Harold
 DNS hostmaster
 University of Michigan

Regards,

Bob
___
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: bind-users Digest, Vol 1798, Issue 1

[Bob McDonald]

This sounds like a Microsoft IP stack where it can be configured to search
the parent domain after a domain failure.  (as opposed to domain suffix
search order).  An attempt to resolve everything for the client no matter
what the client types in.  This generates unnecessary traffic, IMHO.

Bob



--

 Message: 1
 Date: Sun, 23 Mar 2014 14:09:16 -0400
 From: Alan Clegg a...@clegg.com
 To: bind-users@lists.isc.org
 Subject: Re: localhoast A record?
 Message-ID: 532f234c.7090...@clegg.com
 Content-Type: text/plain; charset=iso-8859-1

 On 3/21/14, 2:18 PM, Chris Thompson wrote:

  But in the context of search lists an NXDOMAIN will just make the
 resolver
  go on to try the next entry. So in the case of search lists automatically
  generated from a domain entry, if localhost.astrology.cam.ac.ukdoesn't
  exist, localhost.cam.ac.uk will be tried, and then localhost.ac.uk ...

 I'm trying wrap my head around this automatically generated search
 list that runs outside your domain idea.

 Under what circumstances would this ever be a good idea?

 AlanC

 -- next part --
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 600 bytes
 Desc: OpenPGP digital signature
 URL: 
 https://lists.isc.org/pipermail/bind-users/attachments/20140323/a5a73d31/attachment-0001.bin
 

 --


___
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: Update Security

[Bob McDonald]

Signed updates, that is...


On Sun, Mar 16, 2014 at 5:32 AM, Bob McDonald bmcdonal...@gmail.com wrote:

 Ok so it's not painless.  Do the updates still get forwarded to the master
 by the slaves or do I need to have all Windows devices needing update
 capability to point at the master?

 TIA,

 Bob



 On Fri, Mar 14, 2014 at 7:36 PM, Chris Buxton cli...@buxtonfamily.uswrote:

 On Mar 14, 2014, at 10:50 AM, Bob McDonald bmcdonal...@gmail.com wrote:

  I agree that TSIG or SIG(0) signed updates are certainly a more
 desirable approach than allowing updates via address.  My DHCP server is
 setup to sign all of it's updates this way.  However, I have AD domain
 controllers in the environment that don't currently use signed updates.  Is
 there a fairly painless way to convert all the AD machines to signed
 updates?

 You would need to set up GSS-TSIG, which is not painless. (It's certainly
 doable, but there are plenty of pitfalls to overcome.) Windows doesn't
 support TSIG, just GSS-TSIG.

 AFAIK, use of GSS-TSIG requires update-policy instead of allow-update on
 the master.

 Regards,
 Chris Buxton.



___
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: Update Security

[Bob McDonald]

Ok so it's not painless.  Do the updates still get forwarded to the master
by the slaves or do I need to have all Windows devices needing update
capability to point at the master?

TIA,

Bob



On Fri, Mar 14, 2014 at 7:36 PM, Chris Buxton cli...@buxtonfamily.uswrote:

 On Mar 14, 2014, at 10:50 AM, Bob McDonald bmcdonal...@gmail.com wrote:

  I agree that TSIG or SIG(0) signed updates are certainly a more
 desirable approach than allowing updates via address.  My DHCP server is
 setup to sign all of it's updates this way.  However, I have AD domain
 controllers in the environment that don't currently use signed updates.  Is
 there a fairly painless way to convert all the AD machines to signed
 updates?

 You would need to set up GSS-TSIG, which is not painless. (It's certainly
 doable, but there are plenty of pitfalls to overcome.) Windows doesn't
 support TSIG, just GSS-TSIG.

 AFAIK, use of GSS-TSIG requires update-policy instead of allow-update on
 the master.

 Regards,
 Chris Buxton.
___
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

Update Security

[Bob McDonald]

I want to confirm my understanding of security of DDNS updates.

I have a stealth master A feeding slave B and C.

I have allow-update-forwarding { any; } specified on B and C.

If a client D presents an update to B or C it will automatically be
forwarded to A.

If B or C are in the allow-updates ACL on A all updates will be
applied.

If D is in the allow-udates ACL on A (and not B or C) the updates
from D will be applied.  However an update from E presented to B or
C will be forwarded but not processed.

Is this correct?

Bob
___
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: Update Security

[Bob McDonald]

I agree that TSIG or SIG(0) signed updates are certainly a more desirable
approach than allowing updates via address.  My DHCP server is setup to
sign all of it's updates this way.  However, I have AD domain controllers
in the environment that don't currently use signed updates.  Is there a
fairly painless way to convert all the AD machines to signed updates?

TIA,

Bob



On Fri, Mar 14, 2014 at 12:41 PM, Mark Andrews ma...@isc.org wrote:


 If you are going to forward updates use TSIG or SIG(0) to sign the
 update and stop worrying about addresses.  TSIG and SIG(0) are
 billions and billions of times stronger authenticators than a IP
 address.

 allow-update-forwarding { any; }; says forward all updates
 regardless of the address they were sent from.

 As for you question.  Addresses are not preserved so A doesn't know
 it came from E unless the messages are signed.

 Mark

 In message CAM-YptcevrqfJN0371Zk43gyDt5TiEKusf4EW6=XPvzpwP=
 h...@mail.gmail.com
 , Bob McDonald writes:
 
  I want to confirm my understanding of security of DDNS updates.
 
  I have a stealth master A feeding slave B and C.
 
  I have allow-update-forwarding { any; } specified on B and C.
 
  If a client D presents an update to B or C it will automatically be
  forwarded to A.
 
  If B or C are in the allow-updates ACL on A all updates will be
  applied.
 
  If D is in the allow-udates ACL on A (and not B or C) the updates
  from D will be applied.  However an update from E presented to B or
  C will be forwarded but not processed.
 
  Is this correct?

 No.

  Bob
 
  --001a11337302fad9ea04f49380b0
  Content-Type: text/html; charset=ISO-8859-1
  Content-Transfer-Encoding: quoted-printable
 
  div dir=3DltrdivdivdivdivdivdivdivI want to confirm my
 un=
  derstanding of security of DDNS updates.brbr/divI have a stealth
 mast=
  er quot;Aquot; feeding slave quot;Bquot; and
 quot;Cquot;.brbr/di=
  v
  I have allow-update-forwarding { any; } specified on quot;Bquot; and
 quo=
  t;Cquot;.brbr/divIf a client quot;Dquot; presents an update to
 qu=
  ot;Bquot; or quot;Cquot; it will automatically be forwarded to
 quot;Aq=
  uot;.br
  br/divIf quot;Bquot; or quot;Cquot; are in the allow-updates ACL
 on=
   quot;Aquot; all updates will be applied.brbr/divIf
 quot;Dquot; i=
  s in the allow-udates ACL on quot;Aquot; (and not quot;Bquot; or
 quot;=
  Cquot;) the updates from quot;Dquot; will be applied.=A0 However an
 upda=
  te from quot;Equot; presented to quot;Bquot; or quot;Cquot; will
 be f=
  orwarded but not processed.br
  br/divIs this correct?brbr/divBobbrbr/div
 
  --001a11337302fad9ea04f49380b0--
 
  --===4542560060445475228==
  Content-Type: text/plain; charset=us-ascii
  MIME-Version: 1.0
  Content-Transfer-Encoding: 7bit
  Content-Disposition: inline
 
  ___
  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
  --===4542560060445475228==--
 --
 Mark Andrews, ISC
 1 Seymour St., Dundas Valley, NSW 2117, Australia
 PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
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: Slowing down bind answers

[Bob McDonald]

 Unless the goal is to move all DNS services off that subnet.  Our network
 staff would love to reclaim the /24 our DNS servers are tying up with very
 little else on it wasting 250 addresses.

I'm not sure I'm describing a properly configured anycast environment
well.  Since in anycast the client never see the physical address of a
DNS server, it matters not where they (the DNS server(s)) physically are
(only if they are in the anycast cloud or not).  You can move them around
(insert/delete servers to/from the cloud) to your heart's content and the
client doesn't know.  The requirement here (to avoid having clients left on
legacy devices) is that all the affected servers be in the anycast cloud
and all of your client devices point to the logical anycast address for
DNS resolution NOT the physical address(es) of the DNS server(s).  You
add the new server(s) to the cloud and delete the legacy server(s) from the
cloud.  Easy peasey.  Obviously, this takes some up front planning and
having a group of servers on the same subnet is probably not a good idea
(although it could be interesting from a load sharing perspective...).
YMMV, it's just a thought.
___
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: Slowing down bind answers

[Bob McDonald]

Of course, anycast would have solved this issue by allowing one to
add/remove a server from a properly configured environment without
affecting the clients...

 On 03/01/2014 18:00, wbr...@e1b.org wrote:
 From: Mark Andrews ma...@isc.org
 After that specify a final date for them to fix their machines by
 after which you will send NXDOMAIN responses.  Sometimes sending a
 poisoned reponse is the only way to get peoples attention.

 zone . {
 type master;
 file empty;
 };

 empty:
 @ 0 IN SOA . stop.using.this.nameserver 0 0 0 0 0
 @ 0 IN NS .
 @ 0 IN A 127.0.0.1

 Or really mess with them and answer all A queries with 199.181.132.249

 It's not a bad idea. I could wildcard all requests to an internal HTTP
 server saying that the DNS configuration of the client is deprecated.



Regards,

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

Delegation and Forwarding

[Bob McDonald]

I'm a bit confused on the need for a blank forwarders statement inside of a
zone statement in the named.conf file.  Given an internal zone on a
recursive server with global forwarders, what are the situations which
would require me to code a blank forwarders statement inside of a zone
statement in a named.conf?  I have internal zones which 1) do not delegate
children, 2) delegate children on the same server, and delegate children on
different servers (and different versions of bind).  I know that delegation
is not affected on servers without global forwarders.  The documentation
around this is not clear (at least to me grin).

Is there a difference if the parent is local and the child is forwarded?
 (or both forwarded but to different addresses?)

Thanks,

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

How to influence forwarder selection BIND 9.7.3

[Bob McDonald]

ANYCAST  (in one cloud).
___
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