EDNS Compliance

Crist Clark cjc+bind-users at pumpky.net
Sat Jan 19 03:22:47 UTC 2019


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 <nmaxpierson at 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 <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
>>
>> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190118/c950ff15/attachment-0001.html>


More information about the bind-users mailing list