EDNS Compliance

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: EDNS Compliance

Ben Croswell
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 <[hidden email] 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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email] 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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: EDNS Compliance

Ben Croswell
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 <[hidden email] 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 <[hidden email]> 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 <[hidden email] 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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email] 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 <[hidden email]> 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 <[hidden email] 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: EDNS Compliance

Warren Kumari
In reply to this post by Ben Croswell


On Fri, Jan 18, 2019 at 12:07 PM Ben Croswell <[hidden email]> 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. 

This can be generalized to "Some FW/IPS drop packets".
A huge number of nameservers are running with their nameserver software directly exposed on the Internet (and the rest of their services protected by iptables / stateless ACLs) - this leads to better stability, performance, and predictability - the simplification usually also leads to better security - being able to understand the system and what the (lack of) firewall is doing make it simpler and easier to protect.

Either your "firewall" is doing really deep inspection and understanding of the DNS protocol (in which case you are relying on the ALG to be fully compliant with all behaviors), or you have disabled all ALG work, in which case the firewall is simply adding another point of failure (and likely building state, making troubleshooting harder,etc).

Roland Dobbins had some good articles about the fragility and security decrease caused by stateful devices in front of Internet service type protocols (such as DNS,etc).

Warren "Fully expecting FW vendor flames" Kumari.



On Fri, Jan 18, 2019, 12:02 PM N. Max Pierson <[hidden email] 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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: EDNS Compliance

Mark Andrews
In reply to this post by N. Max Pierson
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 <[hidden email]> 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
> [hidden email]
> 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: [hidden email]

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

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> 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: [hidden email]


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

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: EDNS Compliance

Mark Andrews
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> > [hidden email]
> > 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: [hidden email]
>

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]

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

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> > [hidden email]
> > 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: [hidden email]
>

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]


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

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: EDNS Compliance

Crist Clark
In SRX speak:

  # set security alg dns disable

To verify status of DNS and other ALGs:

  show security alg status

The DNS ALG is one of those enabled by default and must be explicitly disabled to turn it off.


On Fri, Jan 18, 2019 at 1:14 PM N. Max Pierson <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> > [hidden email]
> > 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: [hidden email]
>

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]

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

bind-users mailing list
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: EDNS Compliance

N. Max Pierson
I just reconfigured our SRX and everything seems to be working now. I wasn’t aware that some alg’s were enabled by default so thank you for pointing that out.

Regards,
Max
--
Sent via mobile

On Jan 18, 2019, at 9:22 PM, Crist Clark <[hidden email]> wrote:

In SRX speak:

  # set security alg dns disable

To verify status of DNS and other ALGs:

  show security alg status

The DNS ALG is one of those enabled by default and must be explicitly disabled to turn it off.


On Fri, Jan 18, 2019 at 1:14 PM N. Max Pierson <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> > [hidden email]
> > 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: [hidden email]
>

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]

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

bind-users mailing list
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users