EDNS Compliance

Fri Jan 18 21:14:09 UTC 2019

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 <marka at 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 <nmaxpierson at 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 <marka at 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
> >
> > > On 19 Jan 2019, at 4:02 am, N. Max Pierson <nmaxpierson at gmail.com>
> 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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: marka at isc.org
> >
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka at isc.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190118/a0e6dfba/attachment.html>