Re: securing bind in todays hostile environment

[N. Max Pierson]

Ah, allow me to apologize then. Since I did not see any mention as to why you 
possibly didn’t think ansible would serve us well for this job I had wrongly 
assumed you to had maybe demo’d or just got handed the task of automating in 
your organization and didn’t have time to research or test it before go live, 
causing a bad experience from it possibly. 

The idea for ansible in this case would be to simply manage the zones for us on 
record changes which allowed me to come up with a front end so our customers 
would have self service for the ones that do not pay us to manage their zone 
for them. Trying not to have to re-invent the wheel and write some sort of API 
that did some sort of regex nightmare in shell against the zones, etc for 
simple changes. I can much more easily write a form that generates YML I need 
with the data. The next step is to actually interface with ansible at the API 
level to remove the having to generate YML and run cli commands all together, 
but I’m only one person and coding isn’t even more area of expertise, so in 
time lol.

Yes I have been a part of that same boat a few times myself elsewhere but 
fortunately where I am now, they seem to understand if I make them more money, 
it has to work both ways. They agreed so the arrangement is working quite well 
and I appreciate the remark. 

regards,
m

> On Jan 19, 2020, at 2:01 PM, John W. Blue  wrote:
> 
> Since it sounds like you have not had much experience with, I urge you to 
> check it out should you have anything in your environment that could benefit 
> from automation. Simply telling someone to chunk it and not have any 
> experience with it is a little misguided IMO.
>  
> We pay multiple different teams to play in the ansible, docker, kubernetes et 
> al sandbox so, yeah, I admittedly do *need* to have much experience.  My 
> comments are not an indictment against ansible itself because I observe it 
> being used to create basic servers on a regular basis.  It does a fantastic 
> job.  Rather I was questioning the use of ansible to specifically deploy DNS 
> servers.
> 
> Since you updated your comments to mention that you all are selling DNS 
> services, the choice of ansible now makes more sense.
> 
> I've worked in the MSP space in the past and my general observation is that 
> it is a sweat shop with no loyalty in a race to the bottom of how low of a 
> salary they can get away with paying.  I genuinely hope your experience will 
> be different.
> 
> John
> 
> Sent from Nine 
> 
> 
> ___
> 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: securing bind in todays hostile environment

[N. Max Pierson]

My terminology seems to be the issue here, so let me try and rephrase/elaborate 
: )

> I'm sure that you can get Ansible to add / remove / modify the list of zones 
> on the slave servers.  But is that the best solution when BIND has something 
> built in for doing the same thing?

I was not aware there was anything built in that would let you 
add/remove/change the zone itself from the master. Is this feature basically 
some sort of named.conf synchronization utility? The current setup needs to be 
touched should a new zone need to be added or removed today.

> At least I would evaluate if it's reasonably possible to do. Is the added 
> complexity of NAT /required/ -> /needed/ -> /desired/?

It’s certainly not required and not really wanted personally but having the 
master with a public IP (doing a no nat for that host in the FW policy) on the 
inside would be a snowflake as everything else has RFC1918 on it behind the 
firewall (IPv4 that is). Not that that’s a deal breaker, I just would have to 
get sign-off from others. The reason I had for having it in the DMZ is so that 
one would have to penetrate the FW to get to the master for any changes to be 
made. And this FW would next-gen with for high level of scrutiny which IPtables 
can’t give. 

> I'm failing to understand why the /reverse/ zones have more security than 
> /other/ zones.

So all of the slaves would be answering for public/external domains. No 
internal will exist on them nor the master. Very simple setup without any views 
currently, so the slaves are copies of the master. Forward and reverse would be 
treated the same, sorry if I mis-spoke.

> I would still expect the scope of access to be the same for forward and 
> reverse zones.

See previous. I think what I meant to say was that the recursive servers be 
locked down via ACL at 2 different layers. Not the authoritative, again my 
apologies.

Thanks for the quick and dirty on RPZ. I knew what it was and how it works 
somewhat but was not aware the scope of the vars and functions that act upon 
them to be so flexible. The functions allow me to return/manipulate the 
response at what seems like a pretty granular level. I need to read up on 
exactly what each response does in totality but I get a good guess from their 
name/description. 

Again I appreciate the detail in your response. It makes me feel a little 
better about managing our own instances versus handing it off to some other 
cloud provider. 

Regards,
m

> On Jan 19, 2020, at 11:23 AM, Grant Taylor via bind-users 
>  wrote:
> 
> On 1/19/20 3:25 AM, N. Max Pierson wrote:
>> Hi Grant,
> 
> Hi,
> 
>> I should have been a little more descriptive in the scenario by giving the 
>> purpose of these name servers. They are basically being deployed as a 
>> managed DNS service that we offer. We are a MSP for the most part and the 
>> DNS infrastructure was not being very well maintained when I got here. 
>> Knowing that and the fact we sell this as a service, it needs more attention 
>> that it has gotten in the past plus someone with more knowledge than the 
>> ones that originally set them up. Having that said, I have my work cut out 
>> for me.
> 
> Fair enough.
> 
> With that in mind, I'm speculating that the list of zones (in scope) will be 
> somewhat dynamic.  As such, I *STRONGLY* encourage you to take a look at 
> catalog zones.
> 
> I'm sure that you can get Ansible to add / remove / modify the list of zones 
> on the slave servers.  But is that the best solution when BIND has something 
> built in for doing the same thing?
> 
>> We do not use dynamic entries and as far as the hidden/shadow master, I do 
>> not have an issue with the master being on the public segment and part of 
>> the NS records. I was thinking of simply poking a hole in the firewall to a 
>> static NAT for the master (restricted by the slave IPs) so that it could be 
>> contacted from the outside. I would have the master in the DMZ. Since this 
>> isn’t being used for any internal name services, I guess it may not make 
>> much sense to have it in the DMZ.
> 
> If the master is functionally identical to the slaves, save for the master vs 
> slave configuration, then it probably can live with the slaves.  However, if 
> the master has any other data / configuration / internal DB access / etc, I 
> would recommend that it be separated.
> 
> I like to think of slave servers in the DMZ as a line of defense for the 
> master.  Sometimes it's appropriate, sometimes it isn't.
> 
> I don't know your network topology.  But I'd be tempted to see if I could use 
> standard routing in lieu of NAT between the slaves and the master.  At least 
> I would evaluate if it's reasonably possible to do. Is the added complexity 
> of NAT /required/ -&g

Re: securing bind in todays hostile environment

[N. Max Pierson]

cess has been proven and repeated many times over again saving the 
organization a ton of money by not having to hire additional help for my group 
as well as other groups (not to mention a little increase in my pay, but not 
really relevant to the conversation). 

Quite simply, it works if you deploy and utilize it correctly.

Thanks for the response!

Regards,
m



> On Jan 18, 2020, at 8:53 PM, John W. Blue  wrote:
> 
> Some things to think about ..
> 
> 1.  What is your/teams plan B to fix this type of ansible environment should 
> it get horked up?  There is a ton of stuff that is being configured for you 
> all under the hood and by your own admission your a novice.  The laws of 
> unintended consequences apply.
> 
> 2.  Why is the decision being made to go with a "solution" using ansible?  Is 
> it because software devs are being asked to do double duty as DDI admins?  I 
> know that "devops" is what all the cool kids are talking about these days but 
> are you all honestly willing to trust a core infrastructure to automation?
> 
> 3.  (slightly different phrasing) What problem does this plan solve?  
> Assuming the existing DNS servers are doing the job for the organization and 
> running the current BIND release why change?
> 
> 4.  When I read that they called DNSSEC an authentication method I checked 
> out.  They dont know what they are talking about.  DNSSEC is  a validation 
> method.
> 
> In the absence of more detailed design goals I would recommend that you all 
> chunk the ansible  plan and go with what works and is proven.
> 
> Using a hidden master either for external or internal or both is a good plan 
> to defend against cache poisoning (we do) but only enable DNSSEC on your 
> external zone(s).
> 
> If you use a split horizon consider naming your servers in such a manner so 
> that it obvious which is which when you all drive off into the 
> troubleshooting weeds.
> 
> Depending on the size of your organization, editing zone files to add remove 
> resource records by hand is a painful existence if there is daily changes.  
> Do yourself and everyone that comes after you a favor and invest in a legit 
> IPAM solution from either Infoblox or Bluecat.  I prefer Infoblox but both 
> can administrate BIND and Microsoft DNS servers.  Plus you get the ability to 
> tag up metadata which is good to recall why something was done.
> 
> Final word:  no way in the world would I ever sign off on a system that 
> leaves me/my team holding the email-is-down bag due to a DNS outage caused by 
> a poorly designed system.
> 
> Been there .. done that.  No bueno.
> 
> (final, final word: if you still want to live in ansible  I would suggest 
> that you add another NIC to each server and assume the IPs of the old servers 
> so you dont bring cruft forward into your new world order.)
> 
> 
> 
> John
> 
> Sent from Nine <http://www.9folders.com/>
> From: "N. Max Pierson" 
> Sent: Saturday, January 18, 2020 8:08 AM
> To: bind-users@lists.isc.org
> Subject: securing bind in todays hostile environment
> 
> Hi List,
> 
> First off, I should note that I am a novice with administering Bind, so 
> please bear with me. 
> 
> We are looking to be more pro-active and security minded in our network in 
> general and while we are getting ready to completely replace/upgrade our 
> current instances of Bind, I would like to hear of opinions of the following 
> ansible role that would install, setup, configure, etc our instances taking 
> security into account. I have read some of the common best practices on this 
> very list over time but wanted to ensure what was in this role wasn't missing 
> anything in terms of securing the deployment. 
> 
> So I am aware it’s preferred to split recursive and authoritative services 
> across different instances. I also understand it’s preferred to use one of 
> the “out of zone” (apologies for not knowing the proper terminology) master 
> methods (such as hidden or shadow master). It’s also a very good idea to 
> deploy TSIG for transaction signing. And of course, ACL recursive lookups as 
> well as AXFRs. Beyond that, what other best practices should be considered 
> when making a deployment such as the following scenario ….
> 
> ns1 - ns4: authoritative name servers - slaves
> ns0 - hidden/shadow master
> 
> old ns1- ns4: will be used as recursive as these were deployed doing both 
> authoritative and recursive many years ago and policy routing for these old 
> IPs is very ugly, so we would like to keep them there after an upgrade as 
> opposed to try and figure out who’s still using them to notify we’re changing 
> the IPs
> 
> 
> The ansible role can be seen here at https:

Re: securing bind in todays hostile environment

[N. Max Pierson]

Hi Grant,

A couple of things ….

I should have been a little more descriptive in the scenario by giving the 
purpose of these name servers. They are basically being deployed as a managed 
DNS service that we offer. We are a MSP for the most part and the DNS 
infrastructure was not being very well maintained when I got here. Knowing that 
and the fact we sell this as a service, it needs more attention that it has 
gotten in the past plus someone with more knowledge than the ones that 
originally set them up. Having that said, I have my work cut out for me.

> One thing that I couldn't tell from your description is if you need to 
> support dynamic updates from clients. 


We do not use dynamic entries and as far as the hidden/shadow master, I do not 
have an issue with the master being on the public segment and part of the NS 
records. I was thinking of simply poking a hole in the firewall to a static NAT 
for the master (restricted by the slave IPs) so that it could be contacted from 
the outside. I would have the master in the DMZ. Since this isn’t being used 
for any internal name services, I guess it may not make much sense to have it 
in the DMZ.

> Why do you want to ACL /recursive/ lookups? 

Paranoia I guess lol. I should have mentioned said servers will have proper 
IPtables configured but will not have a formal next-gen firewall appliance in 
front of it. Even though we do implement some sort of packet filter for access 
to the services, I also tell bind to only respond to certain sources as well. 
Possibly overkill and more administrative work but I always go back to the 
“security in layers” train off thought. And since we use ansible for 
management, the second argument is sort of moot.

> Another option to avoid PBR and mass client changes is to use traditional 
> routing to get to the ns1–ns4 IPs.


Your strategy for putting the old resolver IPs as loopbacks on the new servers 
is a spiffy idea that I had not thought of before. That would make life easier 
as it could be queried by the interface IP for new users should we want to use 
the new IP and the old users would still just work because of the loopback. And 
we actually have each server on it’s own /29 or /64 (due to VRRP) so the actual 
IPs are very easily movable.

> How are you doing the black hole if not with RPZ?


As or the RPZ, I understood how it works at a high level but have never had the 
experience in using it. I was not aware the blackhole mechanism was also 
provided by it ( i had assumed they could send responses to something like 
/dev/null which Im guessing is now wrong ), so I do need to correct my self and 
state that we will need them because I intend on implementing filtering at that 
level since it is available. 

As for the rest, some of them would not apply since these are public servicing 
name servers and not internal. The rest of the suggestions will certainly be 
researched more so that I can fully understand how to implement them should 
they apply to our deployment. 

Thanks for the lengthy and descriptive response. It gives me several things to 
think about and research.

Regards,
m


> On Jan 18, 2020, at 11:59 AM, Grant Taylor via bind-users 
>  wrote:
> 
> On 1/18/20 7:06 AM, N. Max Pierson wrote:
>> Hi List,
> 
> Hi M,
> 
>> First off, I should note that I am a novice with administering Bind, so 
>> please bear with me.
> 
> We all started somewhere.  Hopefully we all continue to learn new things.  ;-)
> 
>> We are looking to be more pro-active and security minded in our network in 
>> general and while we are getting ready to completely replace/upgrade our 
>> current instances of Bind, I would like to hear of opinions of the following 
>> ansible role that would install, setup, configure, etc our instances taking 
>> security into account. I have read some of the common best practices on this 
>> very list over time but wanted to ensure what was in this role wasn't 
>> missing anything in terms of securing the deployment.
> 
> «hat tip»
> 
>> So I am aware it’s preferred to split recursive and authoritative services 
>> across different instances.
> 
> Yes, that's the ideal design.  Unfortunately that doesn't always scale down 
> to where some people need it.  It quickly starts to be more complexity for 
> smaller networks, particularly SOHO networks.  :-/
> 
> My current understanding is that if the server is accessible from the 
> Internet, then it probably really should have the recursive and authoritative 
> roles separated.  If it's not accessible from the Internet, then it's more up 
> to your discretion of what makes sense for your network.
> 
> My preference for smaller networks that may have multiple servers but don't 
> warrant separate servers is to have multiple recursive servers slave internal 
> zones off of the int

securing bind in todays hostile environment

[N. Max Pierson]

Hi List,

First off, I should note that I am a novice with administering Bind, so please 
bear with me. 

We are looking to be more pro-active and security minded in our network in 
general and while we are getting ready to completely replace/upgrade our 
current instances of Bind, I would like to hear of opinions of the following 
ansible role that would install, setup, configure, etc our instances taking 
security into account. I have read some of the common best practices on this 
very list over time but wanted to ensure what was in this role wasn't missing 
anything in terms of securing the deployment. 

So I am aware it’s preferred to split recursive and authoritative services 
across different instances. I also understand it’s preferred to use one of the 
“out of zone” (apologies for not knowing the proper terminology) master methods 
(such as hidden or shadow master). It’s also a very good idea to deploy TSIG 
for transaction signing. And of course, ACL recursive lookups as well as AXFRs. 
Beyond that, what other best practices should be considered when making a 
deployment such as the following scenario ….

ns1 - ns4: authoritative name servers - slaves
ns0 - hidden/shadow master

old ns1- ns4: will be used as recursive as these were deployed doing both 
authoritative and recursive many years ago and policy routing for these old IPs 
is very ugly, so we would like to keep them there after an upgrade as opposed 
to try and figure out who’s still using them to notify we’re changing the IPs


The ansible role can be seen here at https://github.com/juju4/ansible-bind 
 . So you don’t have to click on the 
link, what this role does to secure bind in summary is as follows:

- Secure template from Team Cymru template 
(http://www.cymru.com/Documents/secure-bind-template.html). Please note than 
separated internal/external views are not implemented currently.
- DNSSEC for authentication,
- RPZ to whitelist/blacklist entries
- Malware domains list blackholed
- Eventual integration with MISP RPZ export
- Authoritative DNS (mostly for internal zones) Mostly as cache/forwarder but 
could be other roles.

Taking into consideration what I have already learned plus the few things above 
mentioned on GitHub (mainly the security template and malware domain blackhole 
as we do not use RPZ or Views), is there anything else that should be 
considered/added/changed/removed to/from the defaults of this role when we go 
to deploy the above scenario? 

TIA,
m___
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

RNDC Stats

[N. Max Pierson]

Hi List,

I am trying to pull some metrics from our bind servers and I don't quite
understand what some for the stats in the file really mean. What I am
looking for is total queries and then a breakdown of total queries for each
zone. Under Incoming Requests it has QUERY's among some other stats. Is
this the total queries across all zones? If it is, it doesn't seem to add
up to what the total of each zone added together in the per zone stats. Can
someone please educate me on this and let me know if I am just reading the
file incorrectly? There doesn't seem to be any documentation on the stats
file itself.

Regards,
Max
___
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: EDNS Compliance

[N. Max Pierson]

The 2 servers that pass the check are behind an old Cisco FWSM so I know it
at least works. Hopefully that code carried over to the ASA and won't give
us any problems but if it does, I have the option of moving these servers
directly to the internet and I can configure iptables for any filtering we
need.

As far as any option in the SRX, I do not see any configuration options to
disable the version check for EDNS as you suggested. I have a couple of
posts on Juniper forms/mailing lists to see if I get anyone familiar with
these options but for the moment we are just using the SRX as a packet
filter with no ALGs so we may be out of luck.

Regards,
Max

Regards,
Max

On Fri, Jan 18, 2019 at 3:07 PM Mark Andrews  wrote:

> I can’t remember if Cisco ASA has a similar issue.  Checkpoint does have
> similar
> issues (EDNS version != 0 and EDNS flags) last time I checked.  Checkpoint
> were
> thinking of changing the defaults.  You just need to turn off the setting
> on the
> Juniper.  It really shouldn’t be on by default as it doesn’t do anything
> useful.
>
> > On 19 Jan 2019, at 7:52 am, N. Max Pierson 
> wrote:
> >
> > I was just trying to figure out how I could log this but since the
> logging would only probably show if something didn't match udp 53 on the
> server IP it probably wouldn't match the block-any catch-all log I
> configured. I will certainly bring this up to our Juniper rep but in the
> meantime, I have a spare Cisco ASA I am going to migrate these subnets to
> and see if that fixes the timeouts we are experiencing.
> >
> >  Mark, thank you for your explanation. And if anyone knows someone at
> Juniper you may want to mention this to them as if they do not fix it
> before flag day, a lot of queries will be broken.
> >
> > Regards,
> > Max
> >
> > On Fri, Jan 18, 2019 at 2:42 PM Mark Andrews  wrote:
> > This is the signature of a Juniper firewall which drops EDNS version !=
> 0 and
> > packet with a NSID option present.  Dropping EDNS version != 0 just
> breaks
> > future interoperability and as already impacted of EDNS development as
> the
> > RFC 6891 would have included a EDNS version bump except for these stupid
> > firewalls dropping EDNS version != 0.  NSID is used to identify a server
> > in a anycast cluster and the information is not returned unless the
> operator
> > has configured the server to return it.  There is no need for a firewall
> to
> > drop queries with these properties.
> >
> > Please file a bug report with Juniper.
> >
> > Mark
> >
> > > On 19 Jan 2019, at 4:02 am, N. Max Pierson 
> wrote:
> > >
> > > Hi List,
> > >
> > > I am trying to ensure our Bind servers comply with EDNS for the
> upcoming Flag Day (https://dnsflagday.net/). I am somewhat ignorant to
> EDNS but from what I have read, the information is somewhat conflicting as
> some documentation states EDNS is not a record that you configure in your
> zone file then other sites refer to some sort of OPT record you can
> configure. So my first question is which of the documentation is correct
> from what I have read? Is it DNS server functionality that supports EDNS or
> do you also have to configure something in the zone files?
> > >
> > > Also, I have 4 (well 5 counting the master that isn't queryable)
> nameservers with multiple domains served on them. When I run one of my
> primary domains through the ISC EDNS tool, it comes back as 2 out of the 4
> are failing EDNS queries.They are all on the same version of Bind
> (9.8.2rc1) and they are all slaves of the master so they should all have
> the same records. Can anyone please explain what I need to do to resolve
> the timeouts listed on the ISC testing tool?
> > >
> > > Here is what the tool says ...
> > >
> > >
> > > venyu.com. @208.79.48.30 (ns4.venyu.com.): dns=ok edns=ok
> edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=ok
> docookie=ok edns512tcp=ok optlist=timeout
> > >
> > > venyu.com. @69.2.33.250 (ns1.venyu.com.): dns=ok edns=ok edns1=ok
> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
> edns512tcp=ok optlist=ok
> > > venyu.com. @2604:d800:12::250 (ns1.venyu.com.): dns=ok edns=ok
> edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok
> docookie=ok edns512tcp=ok optlist=ok
> > >
> > > venyu.com. @69.2.63.250 (ns3.venyu.com.): dns=ok edns=ok edns1=ok
> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
> edns512tcp=ok optlist=ok
> > > venyu.com. @2604:d800:13::250 (ns3.venyu.com.): dns=ok edns=ok
> edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok e

Re: EDNS Compliance

[N. Max Pierson]

I was just trying to figure out how I could log this but since the logging
would only probably show if something didn't match udp 53 on the server IP
it probably wouldn't match the block-any catch-all log I configured. I will
certainly bring this up to our Juniper rep but in the meantime, I have a
spare Cisco ASA I am going to migrate these subnets to and see if that
fixes the timeouts we are experiencing.

 Mark, thank you for your explanation. And if anyone knows someone at
Juniper you may want to mention this to them as if they do not fix it
before flag day, a lot of queries will be broken.

Regards,
Max

On Fri, Jan 18, 2019 at 2:42 PM Mark Andrews  wrote:

> This is the signature of a Juniper firewall which drops EDNS version != 0
> and
> packet with a NSID option present.  Dropping EDNS version != 0 just breaks
> future interoperability and as already impacted of EDNS development as the
> RFC 6891 would have included a EDNS version bump except for these stupid
> firewalls dropping EDNS version != 0.  NSID is used to identify a server
> in a anycast cluster and the information is not returned unless the
> operator
> has configured the server to return it.  There is no need for a firewall to
> drop queries with these properties.
>
> Please file a bug report with Juniper.
>
> Mark
>
> > On 19 Jan 2019, at 4:02 am, N. Max Pierson 
> wrote:
> >
> > Hi List,
> >
> > I am trying to ensure our Bind servers comply with EDNS for the upcoming
> Flag Day (https://dnsflagday.net/). I am somewhat ignorant to EDNS but
> from what I have read, the information is somewhat conflicting as some
> documentation states EDNS is not a record that you configure in your zone
> file then other sites refer to some sort of OPT record you can configure.
> So my first question is which of the documentation is correct from what I
> have read? Is it DNS server functionality that supports EDNS or do you also
> have to configure something in the zone files?
> >
> > Also, I have 4 (well 5 counting the master that isn't queryable)
> nameservers with multiple domains served on them. When I run one of my
> primary domains through the ISC EDNS tool, it comes back as 2 out of the 4
> are failing EDNS queries.They are all on the same version of Bind
> (9.8.2rc1) and they are all slaves of the master so they should all have
> the same records. Can anyone please explain what I need to do to resolve
> the timeouts listed on the ISC testing tool?
> >
> > Here is what the tool says ...
> >
> >
> > venyu.com. @208.79.48.30 (ns4.venyu.com.): dns=ok edns=ok edns1=timeout
> edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok
> edns512tcp=ok optlist=timeout
> >
> > venyu.com. @69.2.33.250 (ns1.venyu.com.): dns=ok edns=ok edns1=ok
> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
> edns512tcp=ok optlist=ok
> > venyu.com. @2604:d800:12::250 (ns1.venyu.com.): dns=ok edns=ok edns1=ok
> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
> edns512tcp=ok optlist=ok
> >
> > venyu.com. @69.2.63.250 (ns3.venyu.com.): dns=ok edns=ok edns1=ok
> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
> edns512tcp=ok optlist=ok
> > venyu.com. @2604:d800:13::250 (ns3.venyu.com.): dns=ok edns=ok edns1=ok
> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
> edns512tcp=ok optlist=ok
> >
> > venyu.com. @208.79.48.26 (ns2.venyu.com.): dns=ok edns=ok edns1=timeout
> edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok
> edns512tcp=ok optlist=timeout
> >
> >
> >
> > TIA!!
> >
> > Regards,
> >
> > Max
> >
> > ___
> > 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
>
> --
> 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: EDNS Compliance

[N. Max Pierson]

Good point as I did not think in terms of an IPS checking for that as well.
In our case the firewall in question is acting as a simple packet filter so
based on what you state, I should be able to allow for larger packet sizes
for DNS queries and hopefully that will resolve our issues.

Thank you for the replies!

Max

On Fri, Jan 18, 2019 at 11:38 AM Ben Croswell 
wrote:

> It more complicated than just packet size. I have seen FWs with IPS rules
> that were dropping the packets because the rule stated 0 was the only edns
> version and anything else was an attack.
>
> I would check the FW logs to find the log of the drop and work back from
> there.
>
> On Fri, Jan 18, 2019, 12:29 PM N. Max Pierson  wrote:
>
>> Thanks to the response Ben. After looking at the results, it seems we do
>> have a different firewall between the 4 servers and they have IPs out of
>> the same subnet for 2 of them which are failing. So this lets me know it is
>> firewall related and now I can check that.
>>
>> Do you know what type of rule (in general, not anything specific) needs
>> to be added to allow for larger EDNS packets? Is it as simple as allowing
>> the maximum size for payload specified in the RFC (
>> https://tools.ietf.org/html/rfc6891#section-6.2.5) which is 4096 bytes?
>>
>> Regards,
>> Max
>>
>> On Fri, Jan 18, 2019 at 11:07 AM Ben Croswell 
>> wrote:
>>
>>> As long as all 4 DNS servers are running the same version, my first
>>> suggestion would be to check firewalls for dropped packets.
>>>
>>> Some FW/IPS drop packets with edns versions other 0 because they see it
>>> as an attack.
>>>
>>> On Fri, Jan 18, 2019, 12:02 PM N. Max Pierson >> wrote:
>>>
>>>> Hi List,
>>>>
>>>> I am trying to ensure our Bind servers comply with EDNS for the
>>>> upcoming Flag Day (https://dnsflagday.net/). I am somewhat ignorant to
>>>> EDNS but from what I have read, the information is somewhat conflicting as
>>>> some documentation states EDNS is not a record that you configure in your
>>>> zone file then other sites refer to some sort of OPT record you can
>>>> configure. So my first question is which of the documentation is correct
>>>> from what I have read? Is it DNS server functionality that supports EDNS or
>>>> do you also have to configure something in the zone files?
>>>>
>>>> Also, I have 4 (well 5 counting the master that isn't queryable)
>>>> nameservers with multiple domains served on them. When I run one of my
>>>> primary domains through the ISC EDNS tool, it comes back as 2 out of the 4
>>>> are failing EDNS queries.They are all on the same version of Bind
>>>> (9.8.2rc1) and they are all slaves of the master so they should all have
>>>> the same records. Can anyone please explain what I need to do to resolve
>>>> the timeouts listed on the ISC testing tool?
>>>>
>>>> Here is what the tool says ...
>>>>
>>>>
>>>> venyu.com. @208.79.48.30 (ns4.venyu.com.): dns=ok edns=ok
>>>> *edns1=timeout* edns@512=ok ednsopt=ok *edns1opt=timeout* do=ok
>>>> ednsflags=ok docookie=ok edns512tcp=ok *optlist=timeout*
>>>>
>>>> venyu.com. @69.2.33.250 (ns1.venyu.com.): dns=ok edns=ok edns1=ok
>>>> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
>>>> edns512tcp=ok optlist=ok
>>>> venyu.com. @2604:d800:12::250 (ns1.venyu.com.): dns=ok edns=ok
>>>> edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok
>>>> docookie=ok edns512tcp=ok optlist=ok
>>>>
>>>> venyu.com. @69.2.63.250 (ns3.venyu.com.): dns=ok edns=ok edns1=ok
>>>> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
>>>> edns512tcp=ok optlist=ok
>>>> venyu.com. @2604:d800:13::250 (ns3.venyu.com.): dns=ok edns=ok
>>>> edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok
>>>> docookie=ok edns512tcp=ok optlist=ok
>>>>
>>>> venyu.com. @208.79.48.26 (ns2.venyu.com.): dns=ok edns=ok
>>>> *edns1=timeout* edns@512=ok ednsopt=ok *edns1opt=timeout* do=ok
>>>> ednsflags=ok docookie=ok edns512tcp=ok *optlist=timeout*
>>>>
>>>>
>>>> TIA!!
>>>>
>>>> Regards,
>>>>
>>>> Max
>>>> ___
>>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>>>> unsubscribe from thi

Re: EDNS Compliance

[N. Max Pierson]

Thanks to the response Ben. After looking at the results, it seems we do
have a different firewall between the 4 servers and they have IPs out of
the same subnet for 2 of them which are failing. So this lets me know it is
firewall related and now I can check that.

Do you know what type of rule (in general, not anything specific) needs to
be added to allow for larger EDNS packets? Is it as simple as allowing the
maximum size for payload specified in the RFC (
https://tools.ietf.org/html/rfc6891#section-6.2.5) which is 4096 bytes?

Regards,
Max

On Fri, Jan 18, 2019 at 11:07 AM Ben Croswell 
wrote:

> As long as all 4 DNS servers are running the same version, my first
> suggestion would be to check firewalls for dropped packets.
>
> Some FW/IPS drop packets with edns versions other 0 because they see it as
> an attack.
>
> On Fri, Jan 18, 2019, 12:02 PM N. Max Pierson  wrote:
>
>> Hi List,
>>
>> I am trying to ensure our Bind servers comply with EDNS for the upcoming
>> Flag Day (https://dnsflagday.net/). I am somewhat ignorant to EDNS but
>> from what I have read, the information is somewhat conflicting as some
>> documentation states EDNS is not a record that you configure in your zone
>> file then other sites refer to some sort of OPT record you can configure.
>> So my first question is which of the documentation is correct from what I
>> have read? Is it DNS server functionality that supports EDNS or do you also
>> have to configure something in the zone files?
>>
>> Also, I have 4 (well 5 counting the master that isn't queryable)
>> nameservers with multiple domains served on them. When I run one of my
>> primary domains through the ISC EDNS tool, it comes back as 2 out of the 4
>> are failing EDNS queries.They are all on the same version of Bind
>> (9.8.2rc1) and they are all slaves of the master so they should all have
>> the same records. Can anyone please explain what I need to do to resolve
>> the timeouts listed on the ISC testing tool?
>>
>> Here is what the tool says ...
>>
>>
>> venyu.com. @208.79.48.30 (ns4.venyu.com.): dns=ok edns=ok *edns1=timeout*
>>  edns@512=ok ednsopt=ok *edns1opt=timeout* do=ok ednsflags=ok
>> docookie=ok edns512tcp=ok *optlist=timeout*
>>
>> venyu.com. @69.2.33.250 (ns1.venyu.com.): dns=ok edns=ok edns1=ok
>> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
>> edns512tcp=ok optlist=ok
>> venyu.com. @2604:d800:12::250 (ns1.venyu.com.): dns=ok edns=ok edns1=ok
>> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
>> edns512tcp=ok optlist=ok
>>
>> venyu.com. @69.2.63.250 (ns3.venyu.com.): dns=ok edns=ok edns1=ok
>> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
>> edns512tcp=ok optlist=ok
>> venyu.com. @2604:d800:13::250 (ns3.venyu.com.): dns=ok edns=ok edns1=ok
>> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
>> edns512tcp=ok optlist=ok
>>
>> venyu.com. @208.79.48.26 (ns2.venyu.com.): dns=ok edns=ok *edns1=timeout*
>>  edns@512=ok ednsopt=ok *edns1opt=timeout* do=ok ednsflags=ok
>> docookie=ok edns512tcp=ok *optlist=timeout*
>>
>>
>> TIA!!
>>
>> Regards,
>>
>> Max
>> ___
>> 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

EDNS Compliance

[N. Max Pierson]

Hi List,

I am trying to ensure our Bind servers comply with EDNS for the upcoming
Flag Day (https://dnsflagday.net/). I am somewhat ignorant to EDNS but from
what I have read, the information is somewhat conflicting as some
documentation states EDNS is not a record that you configure in your zone
file then other sites refer to some sort of OPT record you can configure.
So my first question is which of the documentation is correct from what I
have read? Is it DNS server functionality that supports EDNS or do you also
have to configure something in the zone files?

Also, I have 4 (well 5 counting the master that isn't queryable)
nameservers with multiple domains served on them. When I run one of my
primary domains through the ISC EDNS tool, it comes back as 2 out of the 4
are failing EDNS queries.They are all on the same version of Bind
(9.8.2rc1) and they are all slaves of the master so they should all have
the same records. Can anyone please explain what I need to do to resolve
the timeouts listed on the ISC testing tool?

Here is what the tool says ...


venyu.com. @208.79.48.30 (ns4.venyu.com.): dns=ok edns=ok *edns1=timeout*
 edns@512=ok ednsopt=ok *edns1opt=timeout* do=ok ednsflags=ok docookie=ok
edns512tcp=ok *optlist=timeout*

venyu.com. @69.2.33.250 (ns1.venyu.com.): dns=ok edns=ok edns1=ok edns@512=ok
ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=ok
optlist=ok
venyu.com. @2604:d800:12::250 (ns1.venyu.com.): dns=ok edns=ok edns1=ok
edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
edns512tcp=ok optlist=ok

venyu.com. @69.2.63.250 (ns3.venyu.com.): dns=ok edns=ok edns1=ok edns@512=ok
ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=ok
optlist=ok
venyu.com. @2604:d800:13::250 (ns3.venyu.com.): dns=ok edns=ok edns1=ok
edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
edns512tcp=ok optlist=ok

venyu.com. @208.79.48.26 (ns2.venyu.com.): dns=ok edns=ok *edns1=timeout*
 edns@512=ok ednsopt=ok *edns1opt=timeout* do=ok ednsflags=ok docookie=ok
edns512tcp=ok *optlist=timeout*


TIA!!

Regards,

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