Mailing List Archive

> When doing some investigation for the upcoming DNS Flag Day (https://dnsflagday.net: February 1st 2019) I got some bad news from one of the service providers: they use Juniper SRX firewalls, and claim that they can't properly support EDNS because of a bug in their SRX firewalls. This seems outrageous to me. Is this just because they haven't upgraded their JunOS for years, they're running ancient DNS server software, or is there really a problem?

See

https://mailman.nanog.org/pipermail/nanog/2019-January/099180.html

"Juniper and Checkpoint have newer code that doesn't do this."

Steinar Haug, Nethelp consulting, sthaug@nethelp.no
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

What they told you sounds like bullshit to me. From 10.2 on there are no special settings required. Maybe they don’t know how to do it?

So I guess they are just very lazy or don’t know better and blame the firewall... I pray for you that they don’t run Code below 10.2...

https://kb.juniper.net/InfoCenter/index?page=content&id=KB23569&cat=SRX_5600_1&actp=LIST


CHS








Von meinem iPhone gesendet

Am 25.01.2019 um 12:53 schrieb sthaug@nethelp.no:

>> When doing some investigation for the upcoming DNS Flag Day (https://dnsflagday.net: February 1st 2019) I got some bad news from one of the service providers: they use Juniper SRX firewalls, and claim that they can't properly support EDNS because of a bug in their SRX firewalls. This seems outrageous to me. Is this just because they haven't upgraded their JunOS for years, they're running ancient DNS server software, or is there really a problem?
>
> See
>
> https://mailman.nanog.org/pipermail/nanog/2019-January/099180.html
>
> "Juniper and Checkpoint have newer code that doesn't do this."
>
> Steinar Haug, Nethelp consulting, sthaug@nethelp.no
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

It would mean that they run something older than 10.2 JunOS, that is a prehistoric release, which would be criminal in term of security.
Anyway, putting stateful firewalls in front of DNS servers is a nonsense from the beginning.

> Le 25 janv. 2019 à 13:06, Christian Scholz <chs@ip4.de> a écrit :
>
> What they told you sounds like bullshit to me. From 10.2 on there are no special settings required. Maybe they don’t know how to do it?
>
> So I guess they are just very lazy or don’t know better and blame the firewall... I pray for you that they don’t run Code below 10.2...
>
> https://kb.juniper.net/InfoCenter/index?page=content&id=KB23569&cat=SRX_5600_1&actp=LIST
>
>
> Am 25.01.2019 um 12:53 schrieb sthaug@nethelp.no:
>
>>> When doing some investigation for the upcoming DNS Flag Day (https://dnsflagday.net: February 1st 2019) I got some bad news from one of the service providers: they use Juniper SRX firewalls, and claim that they can't properly support EDNS because of a bug in their SRX firewalls. This seems outrageous to me. Is this just because they haven't upgraded their JunOS for years, they're running ancient DNS server software, or is there really a problem?
>>
>> See
>>
>> https://mailman.nanog.org/pipermail/nanog/2019-January/099180.html
>>
>> "Juniper and Checkpoint have newer code that doesn't do this."

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

> What they told you sounds like bullshit to me. From 10.2 on
> there are no special settings required. Maybe they don't know
> how to do it?
>
> So I guess they are just very lazy or don't know better and
> blame the firewall... I pray for you that they don't run Code
> below 10.2...
>
> https://kb.juniper.net/InfoCenter/index?page=content&id=KB23569&cat=SRX_5600_1&actp=LIST

I'm guessing this isn't it.

If you inspect the error report at

https://ednscomp.isc.org/ednscomp/704c5b6649

it's quite clear that the test probes for support for EDNS
version 1, and expects a "bad version" response, but is instead
met with a DNS query time-out, indicating that an intermediate
box has blocked either the query (most likely) or the response.

Not responding with "bad version" violates a MUST requirement of
section 6.1.3 in RFC 6891, and is likely to be an impediment to
actually develop & deploy EDNS version 1 (not yet standardized),
and makes efficient EDNS version support negotiation impossible.

It's conceivable this is PR1379433, "DNS requests with EDNS
options might be dropped by DNS ALG", fixed-in 15.1X49-D160
17.4R3 18.1R3 18.2R2 18.3R1 18.4R1.

Regards,

- H?vard
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

One of our SRXes was blocking EDNSv1, and so we disabled the DNS ALG to
resolve our issue; this might be a prudent approach depending on your
environment.
Not sure this will help the OP as the device(s) in question are outside
their administrative domain. :)

HTH,
Niall

-----Original Message-----
From: juniper-nsp [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of
Havard Eidnes
Sent: 25 January 2019 12:42
To: chs@ip4.de
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] DNS Flag Day

> What they told you sounds like bullshit to me. From 10.2 on there are
> no special settings required. Maybe they don't know how to do it?
>
> So I guess they are just very lazy or don't know better and blame the
> firewall... I pray for you that they don't run Code below 10.2...
>
> https://kb.juniper.net/InfoCenter/index?page=content&id=KB23569&cat=SR
> X_5600_1&actp=LIST

I'm guessing this isn't it.

If you inspect the error report at

https://ednscomp.isc.org/ednscomp/704c5b6649

it's quite clear that the test probes for support for EDNS version 1, and
expects a "bad version" response, but is instead met with a DNS query
time-out, indicating that an intermediate box has blocked either the query
(most likely) or the response.

Not responding with "bad version" violates a MUST requirement of section
6.1.3 in RFC 6891, and is likely to be an impediment to actually develop &
deploy EDNS version 1 (not yet standardized), and makes efficient EDNS
version support negotiation impossible.

It's conceivable this is PR1379433, "DNS requests with EDNS options might be
dropped by DNS ALG", fixed-in 15.1X49-D160
17.4R3 18.1R3 18.2R2 18.3R1 18.4R1.

Regards,

- H?vard
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Hi Melchior,

> Thanks for pointing this out. Please have a look at https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1379433 and let me know your ideas.

Yep, that sounds exactly like what's happening!

"Resolved In 15.1X49-D160 17.4R3 18.1R3 18.2R2 18.3R1 18.4R1" sounds hopeful :)

Thanks!
Sander

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp