RE: Re: EDNS Compliance
Hi Max ALG seems to be managing sessions. Specifically, if the DNS query packet is the first packet After creating a session and receiving a DNS responce packet The session seems to be closed with ALG. It is thought that attention is needed when ALG is disable. If ALG is disable, the session will be maintained until UDP timeout (1 minute). I do not have any further information. If detailed information is necessary, I recommend that you contact Juniper support. -- Yoshibumi Suematsu QTnet, Inc. From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of nmaxpier...@gmail.com<mailto:nmaxpier...@gmail.com> Sent: Sunday, January 20, 2019 2:46 AM To: Crist Clark mailto:cjc+bind-us...@pumpky.net>> Cc: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> Subject: [社外から受信](送信者確認)Re: EDNS Compliance 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 mailto:cjc+bind-us...@pumpky.net>> 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 mailto:nmaxpier...@gmail.com>> 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 mailto:ma...@isc.org>> 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 > mailto:nmaxpier...@gmail.com>> 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 > mailto:ma...@isc.org>> 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 ___ 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
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 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 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 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 >>> > >
Re: EDNS Compliance
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 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 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 ednsflags=ok >> docookie=ok edns512tcp=ok optlist=ok >> > >
Re: EDNS Compliance
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 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 >
Re: EDNS Compliance
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 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 > -- 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
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
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
On Fri, Jan 18, 2019 at 12:07 PM 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. > 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 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 > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: EDNS Compliance
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 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 > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list
Re: EDNS Compliance
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 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
Re: EDNS Compliance
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
Re: EDNS Compliance
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 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
EDNS Compliance
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
