RE: Getting all IP adresses for a domain name

[Lightner, Jeffrey]

"dig +trace " will show the whole path to a given record from root 
servers down through registrar to the name servers the registrar specifies.


From: bind-users  On Behalf Of Leroy Tennison
Sent: Wednesday, January 29, 2020 2:13 PM
To: bind-users@lists.isc.org
Subject: Getting all IP adresses for a domain name

I ran into a situation here the IP (v4) address returned for a domain was 
different from two systems.  It turned out that two DNS servers served the 
domain and were replying with different IP addresses (discovered by doing whois 
on the domain followed by dig @ for each name server).  This led 
me to wonder "How would I get all IP addresses if DNS round robin was being 
used?"  I work with external organizations so I can't count on the DNS server 
being ISC's.  I'm not concerned about multiple servers behind a single IP 
address (Anycast for instance) because I consider issues related to that to be 
the destination organization's problem, I'm only concerned with what possible 
IP addresses could be returned in response to a query.

Thanks in advance for any information.

Harriscomputer

Leroy Tennison
Network Information/Cyber Security Specialist
E: le...@datavoiceint.com

[cid:image001.png@01D5D6B0.97204400]

2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com


This message has been sent on behalf of a company that is part of the Harris 
Operating Group of Constellation Software Inc.

If you prefer not to be contacted by Harris Operating Group please notify 
us.



This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential or otherwise legally exempt from disclosure. If you 
are not the named addressee, you are not authorized to read, print, retain, 
copy or disseminate this message or any part of it. If you have received this 
message in error, please notify the sender immediately by e-mail and delete all 
copies of the message.


___
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: RHEL, Centos, Fedora rpm 9.14.6

[Lightner, Jeffrey]

I can't speak for him but will say Carl has been providing these packages and 
announcing them on this list for quite some time now and it is valuable to 
those who would like to use later upstream packages on RHEL/CentOS/Fedora.

RHEL's model (and therefore CentOS') is to start with a base upstream package 
of BIND (and most other packages) tied to their major release then modify it to 
work with the other packages in that release.   They then backport bug and 
security fixes from later upstream into their base and put extended versioning 
on that package so you'll know both the upstream from which it was initially 
derived and the specific build they later did.   Using the extended versioning 
one can learn specifically what has changed (e.g. what CVEs are addressed).

Despite using RHEL or CentOS some people prefer to roll their own using later 
(or the latest) upstream versions of BIND.   Carl is providing packages to 
allow for that.

CentOS releases are built based on the source code RedHat provides for their 
releases.   CentOS is actually maintained by RedHat as of  couple of years 
back.   RedHat offers paid subscriptions/support for RHEL but not for CentOS.   
There is the Fedora EPEL that offers packages or upstream version higher than 
those shipped with RHEL/CentOS.   The packages in the EPEL are designed to work 
on RHEL/CentOS but are not supported (directly) by RedHat on RHEL.

Fedora is a bleeding edge distro in the RedHat ecosystem.  It is used as a test 
bed for much of what later goes into RHEL.   It is also maintained but by 
RedHat but again there is no paid subscription/support for it.   They do 2 
major releases per year so would often have the latest upstream package.   


-Original Message-
From: bind-users  On Behalf Of Jóhann B. 
Guðmundsson
Sent: Monday, September 30, 2019 7:11 AM
To: bind-users@lists.isc.org
Subject: Re: RHEL, Centos, Fedora rpm 9.14.6

> https://www.five-ten-sg.com/mapper/bind contains links to the source 
> rpms, and build instructions.


Bind is already package and maintained in Fedora [1] and derivatives as well as 
ISC having it's ownspecific copr repo [2] in addition to that.

Copr exist to overcome limitation in RHEL/CentOS as in RHEL/CentOS consumer 
wanting newer release then what's available in RHEL/CentOS while Fedora 
packages residing in copr repo would under normal circumstance only be needed 
to provide early testing of branches not yet suitable for rawhide ( read as 
9.15.x branch of Bind would be made available in copr for Fedora while 9.14.x 
is what should be shipped in $CURRENT Fedora releases ).

Now the fact that the copr repo contains newer release of Bind compared to 
what's currently being shipped in Fedora indicates that there is some friction 
between the Fedora maintainer ( which in this case seems to be a Red Hat 
employee not an upstream ISC maintainer ) and ISC community about maintaining 
Bind in the distribution.

That said removing patches implemented by Red Hat for Fedora or it's derivative 
( RHEL/CentOS etc ) is usually not a smart thing to do and or not working with 
upstream community ( ISC ) to provide and help maintain releases for specific 
platform or downstream distribution in a package repository maintained by ISC 
and it's community ( be it a copr repo or repository hosted under the isc 
domain ) will only cause confusion and frustration of consumers of ISC 
components at the cost of the upstream/downstream community surrounding the 
relevant components.

That said and given that there is no rocket science involved with removing 
patches and building packages I ask...

What's the purpose with these builds, what problems do they solve which are 
unsolvable with upstream ( ISC ) or downstream ( Fedora/RHEL/CentOS
) and why announcing you are building it and how long are you intending to 
supporting those builds ( encase someone decides to use those builds instead of 
ISC or downstream distribution maintained ones )?

Regards

                Jóhann B.

1. https://koji.fedoraproject.org/koji/packageinfo?packageID=314

2. https://copr.fedorainfracloud.org/coprs/isc/

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

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

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

RE: Bind 9 with Views: zone transfer refused from master to slave

[Lightner, Jeffrey]

You have to use separate IPs for the separate views on the master and the slave.

Here we just put alias IPs on the primary interfaces and use those for the 
second view.


From: bind-users  On Behalf Of Roberto Carna
Sent: Wednesday, July 03, 2019 3:21 PM
To: ML BIND Users 
Subject: Bind 9 with Views: zone transfer refused from master to slave

Hi people, I have a master/slave Bind 9.10.3 servers configured with views and 
TSIG keys on a Debian 9 host. But the transfer from master to slave is refused 
in the slave side, there is no a descriptive error.

In both Views I have delegated the same two zones: black.com 
and white.com, with different records according to the view.

Please if I send my configuration, can you help me to detect the fail in the 
zone transfer from master to slave??? Thanks a lot in advance.

MASTER

named.conf:

key "rndc-key" {
algorithm hmac-md5;
secret "+PGWO1r5rrT8hcA47Anu0w==";
};

controls {
inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";

named.conf.options:

options {
directory "/var/cache/bind";
also-notify { 10.0.0.2; };
dnssec-validation no;
dnssec-enable yes;
auth-nxdomain no;
allow-query { any; };
notify explicit;
recursion no;
version "none";
};


named.conf.local:

key one {
 algorithm HMAC-MD5;
 secret "uohej/pa1oLBK4Cfhi3zAA==";
};

key two {
 algorithm HMAC-MD5;
 secret "HcKSpnKhqg/+KFvOg2uTag==";
};

key three {
 algorithm HMAC-MD5;
 secret "1JikGx1kdjq/cTCsi36/JQ==";
};

acl one { !key two; !key three; key one; 10.10.0.0/24; };
acl two { !key one; !key three; key two; 10.10.1.0/24; };
acl three { !key one; !key two; key three; 10.10.2.0/24; };

view "one" {
   match-clients { one; };
   server 10.0.0.2 { keys one; };
   recursion yes;
   allow-transfer { key one; };

zone "black.com." {
type master;
file "/etc/bind/zones/black.com.one.db";
also-notify { 10.0.0.2 key one; };
};

zone "white.com" {
type master;
file "/etc/bind/zones/white.com.one.db";
also-notify { 10.0.0.2 key one; };
};
};

view "two" {
match-clients { two; };
server 10.0.0.2 { keys two; };
recursion yes;
allow-transfer { key two; };

zone "black.com." {
type master;
file "/etc/bind/zones/black.com.two.db";
also-notify { 10.0.0.2 key one; };
};

zone "white.com" {
type master;
file "/etc/bind/zones/white.com.two.db";
also-notify { 10.0.0.2 key one; };
};
};


SLAVE

named.conf:

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";

named.conf.options:

options {
directory "/var/cache/bind";
allow-transfer {"none";};
dnssec-validation no;
dnssec-enable yes;
auth-nxdomain no;
allow-query { any; };
notify explicit;
recursion no;
version "none";
};


named.conf.local:

key one {
 algorithm HMAC-MD5;
 secret "uohej/pa1oLBK4Cfhi3zAA==";
};

key two {
 algorithm HMAC-MD5;
 secret "HcKSpnKhqg/+KFvOg2uTag==";
};

key three {
 algorithm HMAC-MD5;
 secret "1JikGx1kdjq/cTCsi36/JQ==";
};

acl one { !key two; !key three; key one; 10.10.0.0/24; };
acl two { !key one; !key three; key two; 10.10.1.0/24; };
acl three { !key one; !key two; key three; 10.10.2.0/24; };

view "one" {
   match-clients { one; };
   server 10.0.0.1 { keys one; };
   recursion yes;

zone "black.com" {
type slave;
masters { 10.0.0.1 key one; };
file "/etc/bind/zones/black.com.one.db";
};

zone "white.com" {
type slave;
masters { 10.0.0.1 key one; };
file "/etc/bind/zones/white.com.one.db";
};

};

view "two" {
match-clients { two; };
server 10.0.0.1 { keys two; };
recursion yes;

zone "black.com" {
type slave;
masters { 10.0.0.1 key one; };
file "/etc/bind/zones/black.com.two.db";
};

zone "white.com" {
type slave;
masters { 10.0.0.1 key one; };
file "/etc/bind/zones/white.com.two.db";
};

};
___
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: A policy for removing named.conf options.

[Lightner, Jeffrey]

But if the knob goes to 11 you'll know it is superior to those that only go to 
10.  :-)


-Original Message-
From: bind-users  On Behalf Of Warren Kumari
Sent: Thursday, June 13, 2019 2:53 PM
To: Evan Hunt 
Cc: Ondřej Surý ; comp-protocols-dns-b...@isc.org
Subject: Re: A policy for removing named.conf options.

On Thu, Jun 13, 2019 at 2:43 PM Evan Hunt  wrote:
>
> > > Is it really much of a hassle to leave the obsolete options in the 
> > > parser, but just ignore them?
>
> IMHO, it depends on the option. For something like "managed-keys" and 
> "trusted-keys", there are clear security implications.  Once those are 
> no longer effective, it would be dangerous to have named ignore them - 
> even with a logged warning. Operators who didn't notice the log 
> message wouldn't realize they were running without the security they'd 
> configured.
>
> For something like "cleaning-interval" or "max-acache-size", IMHO it 
> would be safe to let it slide. With "dnssec-enable" or 
> "queryport-pool-ports", maybe those fall somewhere in between, I could see 
> arguments either way.

I personally think that while it may or may not be a hassle to have the parser 
ignore them, it would be a significant operational risk / annoyance.
Having knobs which you can twiddle which don't do anything leads to all sorts 
of annoyance -- if I'm running low on space for cache, and spend much time 
twiddling the "max-acache-size" knob before discovering that someone has simply 
snipped the wires to it, I'd be super-grumpy.

I'm expecting some issues when knobs get deprecated (and I'm likely to run into 
a few lurking in old configs which have grown over time), but I'd rather have 
named not start just after I've upgraded it than be running in some partially 
undefined state.

W

>
> In any case, if we're going to make a policy that covers the whole 
> range of possibilities, then it needs to address the case when an 
> option must removed, and how to ensure operators aren't blindsided by that.
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
> ___
> 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



--
I don't think the execution is relevant when it was obviously a bad idea in the 
first place.
This is like putting rabid weasels in your pants, and later expressing regret 
at having chosen those particular rabid weasels and that pair of pants.
   ---maf
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

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

RE: A policy for removing named.conf options.

[Lightner, Jeffrey]

Systemd writes logs for things it starts to the Journal which can be viewed 
with journalctl command.

On some distros (e.g. RHEL7) it also continues to write many things to system 
logs like /var/log/messages.   Not all of what goes to the Journal is in 
/var/log/messages but all of what is in /var/log/messages goes to the Journal.


From: bind-users  On Behalf Of Leroy Tennison
Sent: Thursday, June 13, 2019 9:57 AM
To: bind-users@lists.isc.org
Subject: Re: A policy for removing named.conf options.


First of all, I appreciate the fact that you are seeking feedback before 
acting, thank you.



I agree with Warren's point about logs and, unfortunately, also with his 
analysis concerning distributions.  A couple of additional comments.



The major Linux distributions are moving to systemd (whether we like it or 
not), whatever is done has to take that into account.

The only thing you have (the most) control over is the software you produce, 
another approach would be to add a generic message facility to all your 
utilities that, for example, displays the contents of a file at startup (if it 
exists).  Daemon startup could check the configuration files and generate the 
content of the displayed file ("You're using 'blah' option which is 
depreciated, see http://...;).  This way, if an administrator uses any of your 
utilities, they see the message.  For "extra credit", add a "don't display this 
message again" option.  If an administrator manages to support your software 
without using any of your utilities then they are capable of remediating their 
own problems.

Harriscomputer

Leroy Tennison
Network Information/Cyber Security Specialist
E: le...@datavoiceint.com

[cid:image001.png@01D521D3.3503B870]

2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com


This message has been sent on behalf of a company that is part of the Harris 
Operating Group of Constellation Software Inc. These companies are listed 
here.

If you prefer not to be contacted by Harris Operating Group please notify 
us.



This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential or otherwise legally exempt from disclosure. If you 
are not the named addressee, you are not authorized to read, print, retain, 
copy or disseminate this message or any part of it. If you have received this 
message in error, please notify the sender immediately by e-mail and delete all 
copies of the message.




From: bind-users 
mailto:bind-users-boun...@lists.isc.org>> on 
behalf of Ondřej Surý mailto:ond...@isc.org>>
Sent: Thursday, June 13, 2019 8:37 AM
To: Warren Kumari
Cc: bind-users@lists.isc.org
Subject: [EXTERNAL] Re: A policy for removing named.conf options.

Hi Warren and everybody,

first, let me thank for the fruitful discussion!

> On 13 Jun 2019, at 15:18, Warren Kumari 
> mailto:war...@kumari.net>> wrote:
>
> Many many people don't look at their logs -- could named also print
> stuff to (stdout, stderr) when starting?
>
> Note that this will require some testing -- various distributions use
> various init scripts - in many cases things printed at startup don't
> actually make it to the console, and I'm suspecting some init systems
> will barf, but...

It's undermentioned in the policy proposal, but the named-checkconf
will be loud about the deprecated options.  We can then bug distros to
integrate the named-checkconf run into the pre/postinst maintainer scripts.
(Hey myself, fix the Debian package. Ok, myself...)

> Another phased approach would be to require users to acknowledge that
> the feature is being deprecated -- initially it could warn, and then
> named could require command line flags to enable the (being)
> deprecated features, and then in the next release they would stop (e.g
> named --enable_deprecated_cleaning-interval). I think that this is way
> overkill, but just a thought.

That would take 4 full years to deprecate single option, as we need to take
people that upgrade from ESV to ESV into account, and we were aiming
at slightly "faster" approach :-).

Thanks,
--
Ondřej Surý
ond...@isc.org

___
Please visit 
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.isc.org%2fmailman%2flistinfo%2fbind-users=E,1,yw6EFdI2bCuC2na2ur7-F1G92uow3vtsWpruIMf4wVLkS96WojpFuQ9yFBatKWXzbsJWnOpPiH9CsJum226CS7Pr4Oi5GsbAuvBcrpl8GbMNpGxrMrpl3M9XNfw,=1
 to unsubscribe from this list

bind-users mailing list
bind-users@lists.isc.org

RE: A policy for removing named.conf options.

[Lightner, Jeffrey]

I'd suggest also giving warnings for deprecated options when running 
named-checkconf (and named-checkzone if applicable).   You mention the logs but 
not the commands.

Jeffrey C. Lightner
Sr. UNIX/Linux Administrator
 
DS Services of America, Inc.
2300 Windy Ridge Pkwy
Suite 600 N
Atlanta, GA  30339-8461
 
P: 678-486-3516
C: 678-772-0018
F: 678-460-3603
E: jlight...@dsservices.com

-Original Message-
From: bind-users  On Behalf Of Matthijs 
Mekking
Sent: Thursday, June 13, 2019 6:47 AM
To: bind-users@lists.isc.org
Subject: A policy for removing named.conf options.

Dear BIND 9 users,

BIND 9 has a lot of configuration options.  Some have lost value over the 
years, but the policy was to keep the options to not break old configurations.

However, we also want to clean up the code at some point.  Keeping these 
options increases the number of corner cases and makes maintenance more 
cumbersome.  It can also be confusing to new users.  We are trying to establish 
an orderly, staged process that gives existing users ample time to react and 
adapt to deprecated options.

The policy below describes our proposal for the procedure for removing 
named.conf options. We would like to hear your feedback.

Thanks, best regards,

Matthijs


# Policy for removing named.conf options

A named.conf option will first become deprecated before it is removed from the 
code and becomes an unknown option.

## Deprecating

A configuration option that is candidate for removal will be deprecated first.  
During this phase the option will still work, but we will be communicating to 
users that the option is going to be removed soon. A user that has deprecated 
options configured will see warnings in their logs and needs to take action to 
get rid of those log messages.
Configuration options that are deprecated will be identified in the Release 
Note for the release they are deprecated in.

Deprecating an option can be done at any time, but preferably before the next 
ESV release.  For example, an option that that needs to be deprecated before 
the ESV 9.16 will need to flagged so in the 9.15 development or the 9.14 stable 
release.

## Removing

A user that has a removed option configured will be unable to start `named` 
because the configuration option is no longer known.  We plan to remove options 
first in an annual stable release, so that we will learn what the impact is of 
removing a certain option before the change hits the more popular ESV release.  
Configuration options that are removed from BIND 9 will be noted in the Release 
Note for the first version they are removed from.

For example, an option that has been marked as deprecated before 9.16 could be 
removed in the 9.17 development release (that will become the stable ESV 
release, 9.18).

If it is not removed in the stable release it should also not be removed in the 
following ESV release.  Following the example, it thus should also stay in 
9.19/9.20.

## Removing related code

The code that relates to a configuration option that is to be removed will in 
general be deleted at the same time as the configuration option is removed.  
The BIND 9 team may decide to remove the related code at an earlier stage if it 
is considered harmful to keep. In that case the option will become obsolete 
rather than deprecated.

## Candidate options to be deprecated/removed

We certainly don't want to remove any options that are still in widespread use. 
Before making the decision to go ahead with removing an option, we plan to post 
a notice on the bind-users mailing list to solicit feedback. Depending on the 
level of concern from the list, we may move ahead or decide to defer 
deprecating the option.

Below is a table of candidate options we may deprecate and remove.  This list 
is by no means set in stone. Feel free to add suggestions, or add comments.

| option | will be deprecated in | comments  |
| -- | - | - |
| cleaning-interval  | 9.15/9.16 | obsolete  |
| dnssec-update-mode |   | use auto-dnssec instead   |
| dialup |   |   |
| managed-keys   | 9.15/9.16 | replaced with dnssec-keys |
| trusted-keys   | 9.15/9.16 | replaced with dnssec-keys |

In addition, there are already quite some options that are ancient, obsoleted, 
or never implemented before 9.15. They are listed in this issue:

  https://gitlab.isc.org/isc-projects/bind9/issues/1086

and may be removed in the next stable release after 9.16.

___
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: isc-bind-esv Repository - "yum update" doing undesirable things!

[Lightner, Jeffrey]

You could look at RHEL's "alternatives" setup to specify paths.   

"man alternatives" is a good place to read about the command.   The RHEL user 
guides have detail as well.

Alternatives is used on RHEL by default for mail (e.g. sendmail or postfix).  
I've used it to change the default Java version when multiple versions were 
installed, and I didn't want the latest to be the default.

-Original Message-
From: bind-users  On Behalf Of Michal Kepien
Sent: Monday, May 13, 2019 9:04 AM
To: Matthew Richardson 
Cc: bind-users@lists.isc.org
Subject: Re: isc-bind-esv Repository - "yum update" doing undesirable things!

Matthew,

> The tools (dig etc) are used both manually and by a number of scripts.
> Following the upgrade without enabling SCL, dig (for example) was the 
> previous version which came from the previous Copr package.  Is there 
> any official/recommended method for updating server to make the new 
> tools the default?

The tricky part here is that the whole idea of Software Collections is not to 
influence the base system underneath.  For shell use, the way to go would be to 
remove the old isc-bind-utils package and put the following line e.g. in your 
.bash_profile file:

source scl_source enable isc-bind

If you want the Software Collection to be available for all users by default, 
you can put the above line in a file placed in /etc/profile.d, as hinted by Red 
Hat [1] (caveats apply).

However, that still does not solve the issue of non-interactive scripts as 
Software Collections requires specific environment variables to be set that are 
not be set by default e.g. by the cron daemon.  You can either put the above 
"source scl_source..." line in your scripts or try using one of the methods 
listed in the official Software Collections docs [2].  I am unable to say which 
solution would work best for you because it really varies on a case-by-case 
basis.

> You also comented about using "--without scl" with SRPMs.  Does this 
> give the previous behaviour?

Yes, it results in "classic" packages being built that do not comprise a 
Software Collection and thus may conflict with stock OS packages, mess with 
other software's dependencies on the same machine etc.

> Also, what is the correct location from which to download the SRPMs?

Since Copr places the SRPM for each package in the same directory as the binary 
RPMs produced from it, once you add a Copr repository to your yum 
configuration, you can do e.g. this:

$ yumdownloader --source isc-bind-bind

Hope this helps,

[1]: https://access.redhat.com/solutions/527703

[2]: 
https://www.softwarecollections.org/en/docs/guide/#sect-Enabling_the_Software_Collection

--
Best regards,
Michał Kępień
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

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

RE: DNS flag day

[Lightner, Jeffrey]

On checking I find that any of our domains that use Network Solutions’ 
Worldnic.com nameservers are reporting failures when checked.

For example this result:  https://ednscomp.isc.org/ednscomp/e30c6cf0ea

Other people online have posted about Network Solutions as they also saw 
failures.

On calling Network Solutions today they told me they are compliant despite what 
was reported by https://dnsflagday.net/

This issue is with domains registered at Network Solutions and using their 
Advanced DNS (i.e. their Worldnic name servers).   Other domains we have 
registered with them but pointing to other name servers (i.e. our own BIND 
servers) displayed as compliant.

When I sent them the links they saw what I saw but still claimed they are 
compliant.   They refused to send me something in writing stating that so I 
suggested they reach out to ISC regarding the checker’s results if they believe 
they are compliant, but they said they don’t see the need.   I’ve asked them to 
escalate and they say they have but I suspect I’ll not hear back from them.

Is there a list of known edns compliant Registrar name severs for the larger 
Registrars?

Is it possible the failures seen are false?   If so, are there alternate edns 
compliance checkers that might show different responses than dnsflagday.net?




From: bind-users  On Behalf Of Ben Croswell
Sent: Friday, January 18, 2019 12:19 PM
To: bind-users@lists.isc.org
Subject: Re: DNS flag day

I shouldn't have posted so closely to responding to the other user.

I am not running 9.8. I was replying to them about firewalls in regards to 
their 9.8 issues.

Was just hoping for a statement of 9.x or greater supports the needed badvers 
signaling etc.

On Fri, Jan 18, 2019, 12:15 PM Victoria Risk 
mailto:vi...@isc.org> wrote:

On Jan 18, 2019, at 9:09 AM, Ben Croswell 
mailto:ben.crosw...@gmail.com>> wrote:

Has ISC released minimum viable BIND version for flag day?

Most versions of BIND authoritative servers, going back years, are EDNS 
compatible. Certainly ALL currently supported versions are compatible. I see 
you are running 9.8, which has been EOL since September, 2014.  I think that is 
probably fine, as far as EDNS, however.

The change in BIND related to DNS Flag Day is removing workarounds from 
resolvers, that will retry without EDNS or otherwise try to proceed even when 
EDNS fails. This change came in the BIND 9.13 development version, and will be 
in BIND 9.14, which is not yet released.

The problem you are seeing is most likely firewall-related.

Vicky


I looked around and couldn't find anything.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

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

RE: Rewrite/Override QTYPE with RPZ

[Lightner, Jeffrey]

That wouldn't help you much.   Many mail systems these days check not only your 
MX record but also your PTR record to make sure the IP you came from has a 
valid (i.e. not generic) reverse lookup.   They'll also check things like dkim 
or spf TXT records.   If they don't like what they find they'll simply reject 
email even if you haven't been blacklisted.

In general blacklisting services blacklist specific IPs rather than domains 
anyway.   A work around would be to change the outbound IP your mail server 
uses rather than changing other records.  Of course you'd have to make 
additional changes for the PTR, A/ and TXT records for the new IP you 
select. 

Many blacklisting services have a way to delist yourself.

However, if you don't fix the underlying problem that caused you to be 
blacklisted in the first place any new IP will quickly be blacklisted as well 
and/or delisting yourself a second time is much more difficult.

If you are sending multiple automated emails (e.g. invoices or marketing 
materials) to customers you need to be monitoring for returns and removing 
rejected email addresses from your databases.   These often occur because the 
customer no longer has the email address they originally gave you (or they had 
a typo in what they gave you).

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Tom
Sent: Thursday, November 08, 2018 11:49 PM
To: bind-users@lists.isc.org
Subject: Re: Rewrite/Override QTYPE with RPZ

Fore example "example.com" and "*.example.com" are blacklisted. I would like to 
return a real ip address for special query types like MX or TXT, but not for A 
or .

Tom


On 08.11.18 16:44, Barry Margolin wrote:
> In article ,
>   Tom  wrote:
> 
>> Hi all
>> Is there a way to override/rewrite QTYPE (ex. MX) with RPZ? If no, is 
>> this planned in future releases of BIND?
> 
> What would be the point? If a query is for MX, and you return A 
> instead, the client won't be able to do anything with it.
> 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

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

RE: Separate DNS slaves as internal and external

[Lightner, Jeffrey]

You can use views for internal and external.   Just create a secondary IP on 
the same NIC you're using as primary on each hosts.  Set the transfer hosts for 
the external view using the primary IP on the NIC and the ones for the internal 
view on the secondary NICs.

You can set ACLs that say which items should use the internal view and which 
should use the external view.



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
McDonald, Daniel (Dan)
Sent: Thursday, March 22, 2018 4:42 PM
To: King, Harold Clyde (Hal); Bind Users
Subject: Re: Separate DNS slaves as internal and external

I've hidden those sort of things using response policy zones.

On 3/19/18, 6:34 AM, "bind-users on behalf of King, Harold Clyde (Hal)" 
 wrote:

I have DNS slaves for internal and external entities. I don't know how to 
work the NS records so that outside users would only get the external slave and 
internal would only get the internal slave.

How can I do this? If I put only the internal slaves with NS records 
external users query the internal servers. If I put both external users still 
see and use internal slave. If I put only external, internal users get the 
external slave. I have put the external slave in our registrar. 

Any help would be appreciated.

Thanks in advance 


-- 
Hal King  - h...@utk.edu
Systems Administrator
Office of Information Technology
Shared Systems Services

The University of Tennessee
103C5 Kingston Pike Building
2309 Kingston Pk. Knoxville, TN 37996
Phone : 974-1599
Helpdesk 24/7 : 974-9900

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

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


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

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

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

RE: [Question] zone transfer issue with multiple views

[Lightner, Jeffrey]

When we did it here we setup separate notify-source and transfer-source within 
the views on both the master and the slave.
view "internal" {
match-clients { internaldns; };
notify-source 10.9.9.8.;
transfer-source 10.9.9.8;
allow-transfer { dnsservers; };
...then our zones for internal view
Internaldns acl is one that we specify servers inside our network.
dnsserrvers acl is one that specifies the primary internal facing IP of the 
master and the slave

view "external" {
match-clients { any; };
notify-source 10.9.9.9;
transfer-source 10.0.9.9;
allow-transfer { dswadnsalias; };
...then our zones for external view
any allows external locations to query us (we have recursion turned off)
dswadnsalias  acl is one that specifies the alias IPs on the same NIC as the 
internal facing IP of the master and the slave

The IPs above would be on the master - you'd have separate IPs (but the same 
ACLs) on the slave.

You can create an alias IP on your primary NIC so for example here we have:
eth1 = 10.9.9.8
eth1:1 = 10.0.9.9
(In our config eth0 is the one we use for external facing traffic - eth1 is 
used for internal including zone transfers)




From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Eoin Kim
Sent: Thursday, December 07, 2017 8:05 PM
To: bind-users@lists.isc.org
Subject: [Question] zone transfer issue with multiple views

Hi all,

I wonder if anyone can help me find the cause of the problem I am currently 
having. I am testing BIND with two views - internal, external. Everything seems 
okay except for one thing - zone transfer doesn't look happening for reverse 
zone for external view. On my slave server, I can see the following log message:

08-Dec-2017 10:55:59.247 general: info: zone 0.20.172.in-addr.arpa/IN/external: 
refresh: unexpected rcode (NXDOMAIN) from master 192.168.0.7#53 (source 
0.0.0.0#0)

Servers are using TSIG for zone transfer. It looks like zone transfer itself 
working for all other zones except for reverse zone for external view. Could I 
please get help if possible? I am using Debian Jessie and BIND was installed 
from its repository. I am willing to post BIND configurations if needed. Thanks 
a lot.

Eoin Kim
Systems Administrator

RCS Telecommunications
Level 1 - The Annexe
133 Mary Street
Brisbane, QLD, 4000
Office:   07 3228 0843
Mobile: 0419 726 231

[RCST logo drop shadow]

___
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: Issue with AT IPs?

[Lightner, Jeffrey]

I don't disagree with what you say about nameserver diversity but don't feel 
that is the issue here and is missing the point in my question.

I'd already eliminated "lookup" of the DNS servers by going straight to the IP 
they share.

Connections from locations outside our network to that IP port 53 and 
traceroute to that IP work (as they apparently did for both of you).  

Connections outbound from our QTS IPs also work.

It is only connections outbound from our AT IPs that seem to fail.

This makes it look like the issue is specifically something to do with AT 
IPs.There have been no attempts I've made that failed anywhere except from 
the AT IPs.   If it were some temporary "down" of their IP causing a timeout 
then going to second name server I'd expect that to affect the non AT 
outbound IPs or external lookups as well but as I said I'm not seeing it 
anywhere else.

When we do traceroute we are seeing multiple hops either way but once we get to 
the same hop on both the QTS based IPs proceed to the name server and the AT 
based IPs do not. Since paths either way do multiple hops outside our 
network it appears it isn't our network that is the issue but something with 
AT

I'd sent more detail but the mailing list as usual said "your message awaits 
moderator approval" because it is too large.  I've never yet seen any such 
moderator approval email either approved or denied in the past so doubt I'll 
see it this time.


___
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

Issue with AT IPs?

[Lightner, Jeffrey]

We're having issues send email to a user @SIDDHAFLOWERS.COM

Investigation here shows that the issue we have is querying your name servers 
(both by name and by IP) are refusing to respond to our name servers.

Their name servers:
NS1.QUICKFIX8.COM
NS2.QUICKFIX8.COM

Our name servers:
DSWADNS1.WATER.COM
DSWADNS2.WATER.COM

We find other name servers such as those as Google are able to query their name 
servers.   Based on that I determined their name server IP (for both) is 
74.124.202.236.   However, if I attempt to reach port 53 (DNS) on that IP from 
our name servers it simply fails to connect.   Our Network Security engineer 
did a capture and shows we send packets but never get a response.

Interestingly further testing shows this is an issue from any of our AT 
provided IPs:
12.44.84.194
12.44.84.213
12.44.84.214
12.44.84.216
But not from separate QTS Datacenter provided IPs:
209.10.103.136
209.10.103.148

I've reached out to the folks at QuickFix and am waiting to hear back but we've 
seen a similar issue on another domain using separate name servers.Is it 
possible there is some sort of blacklist for DNS (not email) that people might 
be subscribing to that would cause them to block AT IPs?  We can do queries 
from our DNS to most domains but have identified these 2 as problems so suspect 
there might be others.

By the way, I can reach their mail server via command line connection to port 
25 on its IP.   The issue here is purely in querying the DNS servers which of 
course means mail programs can't determine the MX records themselves.

Last night I did see some posts suggesting commenting out query-source but 
testing that didn't do anything.   We do have our query-source setup for random 
outbound ports and I verified last night that it still works based on the test 
site for that.

Most of what I find about blacklisting is about spam blacklisting of mail 
servers not blacklisting of DNS server queries and it is the latter we are 
experiencing.


CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential 
information and is for the sole use of the intended recipient(s). If you are 
not the intended recipient, any disclosure, copying, distribution, or use of 
the contents of this information is prohibited and may be unlawful. If you have 
received this electronic transmission in error, please reply immediately to the 
sender that you have received the message in error, and delete it. Thank you


___
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: named and use of resolv.conf? - how to "learn" this

[Lightner, Jeffrey]

On the server running BIND if you're trying to resolve addresses with many 
commands it will use /etc/nsswitch.conf which usually will say to go to "dns" 
first then to "files" if that doesn't work.   The "dns" tells it to use 
/etc/resolv.conf.   Therefore you'd want to add 127.0.0.1 to your list of 
servers in resolv.conf so the sever knows to resolve from "localhost" when 
you're running commands on the local host that is running BIND.   Other servers 
you'd add the public IP of the this server to resolv.conf.



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Darcy 
Kevin (FCA)
Sent: Tuesday, August 02, 2016 4:19 PM
To: bind-users@lists.isc.org
Subject: RE: named and use of resolv.conf? - how to "learn" this

Is it really necessary to document everything that *isn't* true? That could 
fill volumes...

named is the thing that resolves stuff; /etc/resolv.conf tells processes whom 
to talk to if they want to resolve stuff. Put those things together, why would 
named need /etc/resolv.conf? To talk to *itself*?


- Kevin



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Spumonti Spumonti
Sent: Tuesday, August 02, 2016 12:26 PM
To: bind-users@lists.isc.org
Subject: named and use of resolv.conf? - how to "learn" this

(I've done several searches for this first but the general nature of some of 
these terms returned way too many non-relevant responses)

I was recently told that named does not use resolv.conf when resolving names. 
This was not something I was aware of but at this point I accept that. The 
system in question is an authoritative only server, no recursion enabled, that 
for some zones it hosts, lists secondary name servers in other organizations 
(in other words these name servers are in zones NOT hosted on this server)

My real question is: where is this documented? I've read DNS books and scoured 
different sites but couldn't find anything stating this was how named behaved. 
Maybe I just suck at searching for things or was using imprecise terms.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

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

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

RE: Questions on how to setup Reverse DNS in bind 9

[Lightner, Jeffrey]

I haven't done it with GoDaddy but many providers WILL delegate reverse IPs to 
you if you request it.

Personal editorial comment:
Were it me I wouldn't use GoDaddy for anything.   I detest GoDaddy because 
their whole business model seems aimed at forcing you to leap through hoops to 
do anything useful.   They've recently started refusing external whois queries 
again so you must go to their website.   Often when we acquire companies and 
have to take on their domains if they're at GoDaddy they throw roadblocks in 
our way for transferring the domain to our preferred Registrar.   A new trick 
they started is denying transfers for 60 days if Registrant is updated.  They 
say they do all this to protect their customers but it seems obvious to me it 
is more to protect their bottom line.


From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of John W. 
Blue
Sent: Sunday, July 17, 2016 10:47 PM
To: bind-users@lists.isc.org
Subject: Re: Questions on how to setup Reverse DNS in bind 9

Ken,

You typically will not be delegated reverse DNS.  Honestly, I would contact 
godaddy support directly and see if they can adjust it for you.  As in, not on 
your server directly but either tell you how to do it in a control panel on 
your side of the fence or they just do it from their side.

Best regards,

John

Sent from Nine

From: Spork Schivago >
Sent: Jul 17, 2016 9:24 PM
To: bind-users@lists.isc.org
Subject: Questions on how to setup Reverse DNS in bind 9

Hello,

I'm new to operating a website and I'm leasing a virtual private server (VPS) 
from GoDaddy.   I'm paying for cPanel / WHM as well.   It's running CentOS 6.8 
Final.  I'd like to setup reverse DNS but I'm having trouble.   I'm not 100% 
sure how to do it.   I have my hostname, 
franklin.jetbbs.com   and there's two IP addresses 
assigned to that hostname, 104.238.117.105 and 132.148.11.44.   I was trying to 
setup a round robin kinda thing but I don't think I set it up correctly.

Anyway, I have ns1.jetbbs.com which has the IP of 
104.238.117.105   and then I have ns2.jetbbs.com that 
has the IP address of 132.148.11.44.   I wanted to know if someone could look 
over what I have so far and let me know if it's correct and how I should 
proceed.

So, in the /var/named directory, I create a file called: 
0.117.238.104.in-addr.arpa

The contents of 0.117.238.104.in-addr.arpa are as follows:
$TTL 1D
@   IN SOA  ns1.jetbbs.com. 
spork.jetbbs.com. (
2016071705  ; serial
1D  ; refresh
1H  ; retry
1W  ; expire
3H ); minimum

0.117.238.104.in-addr.arpa.IN  NS  
ns1.jetbbs.com.
0.11.148.132.in-addr.arpa. IN  NS  
ns2.jetbbs.com.

104 IN  PTR franklin.jetbbs.com.
44  IN  PTR franklin.jetbbs.com.


Does that look correct?   If not, how should I change it?   If so, what's the 
next step?   Thank you for your help!

Sincerely,
Ken
___
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: Questions on bind-chroot

[Lightner, Jeffrey]

Is this RHEL5?  RHEL6?  Something else?

On RHEL5 we had bind-chroot running and did all our edits directly in 
/var/named/chroot/etc for named.cocnf and /var/named/chroot/var/named for zone 
files.

In RHEL7 (which uses systemctl rather than service) they setup special mounting 
in the named-chroot systemd file so one has to be sure to restart that rather 
than just the named system file as the named by itself ignores your chroot 
setup.In this RHEL7 setup you edit the named.conf in /etc itself (i.e. the 
non-chroot "real" path) and the "systemctl restart named-chroot" puts the mount 
of that file into /var/named/chroot/etc.


-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Tony Finch
Sent: Monday, June 13, 2016 11:04 AM
To: Harshith Mulky
Cc: bind-users@lists.isc.org
Subject: Re: Questions on bind-chroot

Harshith Mulky  wrote:

> Is it necessary for named.conf in the chroot path and /etc path to be 
> same

If they aren't the same, at some point in the future you or your colleagues are 
going to get very confused about which one is the right one.

> I have 2 different named.conf in both the paths and when I am running 
> the, service named restart, I see the named service starting from the 
> chroot path. Is that correct?

There isn't much standardization of BIND init scripts. Some of them try to keep 
in-chroot and out-of-chroot configuration in sync, some don't, maybe depending 
on how the script is configured. So I can't give you a direct answer; you 
should read your init script carefully.

Tony.
--
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode 
Irish Sea: Cyclonic 3 or 4, increasing 5 at times. Smooth or slight, 
occasionally moderate in far south. Thundery showers, fog patches. Moderate or 
good, occasionally very poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
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