RE: DNS Flag Day: I had to open the TCP/53 port

2019-02-04 Thread Stephan Lagerholm
Hi Roberto,

You are correct in that the DNS Flag day tester at https://dnsflagday.net/
is reporting the closed TCP port as a serious problem. Given that the TCP
port is closed, obviously the EDNS test over TCP fails too and the error
given by the site would be something like: edns512tcp=timeout

To be RFC compliant you should have both UDP and TCP. Timeouts over UDP
can happen due to natural causes and it is good to give a resolver the
opportunity to fallback to TCP if needed even if you never expect your
server to respond with the Truncate bit set. But I would say the flag day
site is a little bit misleading since the question if TCP should be open
or not is somewhat of an orthogonal problem to EDNS compliance.

Hope this helps explaining the error you are seeing.

Stephan






On Mon, 4 Feb 2019, Salih CIRGAN wrote:

> rfc6891 states that it uses TCP to avoid truncated UDP responses. It is all 
> about packet size,fragmentation and network load.
>
>
>
> EDNS(0) specifies a way to advertise additional features such as
>
>larger response size capability, which is intended to help avoid
>
>truncated UDP responses, which in turn cause retry over TCP.  It
>
>therefore provides support for transporting these larger packet sizes
>
>without needing to resort to TCP for transport.
>
>
>
> Announcing UDP buffer sizes that are too small may result in fallback
>
>to TCP with a corresponding load impact on DNS servers.  This is
>
>especially important with DNSSEC, where answers are much larger.
>
>
>
>
>
>
>
>
>
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
> Roberto Carna
> Sent: Monday, February 4, 2019 4:46 PM
> To: ML BIND Users 
> Subject: DNS Flag Day: I had to open the TCP/53 port
>
>
>
> Dear, I have a BIND 9.10 public server and I have delegated some public 
> domains.
>
>
>
> When I test these domains with the EDNS tool offered in the DNS Flag Day 
> webpage, the test was wrong wit just UDP/53 port opened to Internet.
>
>
>
> After that, when I opened also TCP/53 port, the test was succesful.
>
>
>
> Please can you explain me the reason I have to open TCP/53 port to Internet 
> from February 1st to the future???
>
>
>
> Really thanks, regards.
>
>

___
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: DNS Flag Day: I had to open the TCP/53 port

2019-02-04 Thread Salih CIRGAN
rfc6891 states that it uses TCP to avoid truncated UDP responses. It is all 
about packet size,fragmentation and network load.

 

EDNS(0) specifies a way to advertise additional features such as

   larger response size capability, which is intended to help avoid

   truncated UDP responses, which in turn cause retry over TCP.  It

   therefore provides support for transporting these larger packet sizes

   without needing to resort to TCP for transport.

 

Announcing UDP buffer sizes that are too small may result in fallback

   to TCP with a corresponding load impact on DNS servers.  This is

   especially important with DNSSEC, where answers are much larger.

 

 

 

 

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Roberto 
Carna
Sent: Monday, February 4, 2019 4:46 PM
To: ML BIND Users 
Subject: DNS Flag Day: I had to open the TCP/53 port

 

Dear, I have a BIND 9.10 public server and I have delegated some public domains.

 

When I test these domains with the EDNS tool offered in the DNS Flag Day 
webpage, the test was wrong wit just UDP/53 port opened to Internet.

 

After that, when I opened also TCP/53 port, the test was succesful.

 

Please can you explain me the reason I have to open TCP/53 port to Internet 
from February 1st to the future???

 

Really thanks, regards.

___
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: DNS Flag Day: I had to open the TCP/53 port

2019-02-04 Thread Jeronimo L. Cabral
Ben, thanks a lot !!!

Regards

On Mon, Feb 4, 2019 at 11:04 AM Ben Croswell  wrote:

> When a DNS response is too large to fit in a single UDP packet, 512 bytes
> up to 4k with edns, the DNS server will respond with as much as it can fit
> in the UDP packet. It will also set the truncate, TC, bit to let the client
> doing the query that the answer is truncated and the client should query
> again over TCP for the full answer.
>
> The TC bit is also used in conjunction with RRL.
>
> On Mon, Feb 4, 2019, 8:57 AM Roberto Carna  wrote:
>
>> Thanks Ben for your response, can you tell me the types of TCP traffic I
>> have to expect in BIND, excepting Zone Tansfer?
>>
>> Thans a lot again!!!
>>
>> El lun., 4 feb. 2019 a las 10:50, Ben Croswell ()
>> escribió:
>>
>>> BIND has always required UDP and TCP 53 for proper functionality. It
>>> sometimes mistakenly believed that TCP is only for zone transfers but that
>>> is not the case.
>>>
>>> On Mon, Feb 4, 2019, 8:46 AM Roberto Carna >> wrote:
>>>
>>>> Dear, I have a BIND 9.10 public server and I have delegated some public
>>>> domains.
>>>>
>>>> When I test these domains with the EDNS tool offered in the DNS Flag
>>>> Day webpage, the test was wrong wit just UDP/53 port opened to Internet.
>>>>
>>>> After that, when I opened also TCP/53 port, the test was succesful.
>>>>
>>>> Please can you explain me the reason I have to open TCP/53 port to
>>>> Internet from February 1st to the future???
>>>>
>>>> Really thanks, regards.
>>>> ___
>>>> 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
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: DNS Flag Day: I had to open the TCP/53 port

2019-02-04 Thread Ben Croswell
When a DNS response is too large to fit in a single UDP packet, 512 bytes
up to 4k with edns, the DNS server will respond with as much as it can fit
in the UDP packet. It will also set the truncate, TC, bit to let the client
doing the query that the answer is truncated and the client should query
again over TCP for the full answer.

The TC bit is also used in conjunction with RRL.

On Mon, Feb 4, 2019, 8:57 AM Roberto Carna  Thanks Ben for your response, can you tell me the types of TCP traffic I
> have to expect in BIND, excepting Zone Tansfer?
>
> Thans a lot again!!!
>
> El lun., 4 feb. 2019 a las 10:50, Ben Croswell ()
> escribió:
>
>> BIND has always required UDP and TCP 53 for proper functionality. It
>> sometimes mistakenly believed that TCP is only for zone transfers but that
>> is not the case.
>>
>> On Mon, Feb 4, 2019, 8:46 AM Roberto Carna > wrote:
>>
>>> Dear, I have a BIND 9.10 public server and I have delegated some public
>>> domains.
>>>
>>> When I test these domains with the EDNS tool offered in the DNS Flag Day
>>> webpage, the test was wrong wit just UDP/53 port opened to Internet.
>>>
>>> After that, when I opened also TCP/53 port, the test was succesful.
>>>
>>> Please can you explain me the reason I have to open TCP/53 port to
>>> Internet from February 1st to the future???
>>>
>>> Really thanks, regards.
>>> ___
>>> 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: DNS Flag Day: I had to open the TCP/53 port

2019-02-04 Thread Ron Hall

Just about anything (if it is large enough).


r

On 2019-02-04 08:56 AM, Roberto Carna wrote:
Thanks Ben for your response, can you tell me the types of TCP traffic I have 
to expect in BIND, excepting Zone Tansfer?

Thans a lot again!!!

El lun., 4 feb. 2019 a las 10:50, Ben Croswell 
(mailto:ben.crosw...@gmail.com>>) escribió:
BIND has always required UDP and TCP 53 for proper functionality. It sometimes 
mistakenly believed that TCP is only for zone transfers but that is not the 
case.

On Mon, Feb 4, 2019, 8:46 AM Roberto Carna 
mailto:robertocarn...@gmail.com> wrote:
Dear, I have a BIND 9.10 public server and I have delegated some public domains.

When I test these domains with the EDNS tool offered in the DNS Flag Day 
webpage, the test was wrong wit just UDP/53 port opened to Internet.

After that, when I opened also TCP/53 port, the test was succesful.

Please can you explain me the reason I have to open TCP/53 port to Internet 
from February 1st to the future???

Really thanks, regards.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org<mailto: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<mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users


--

Ron Hall
Senior System Administrator, NCS - Core Infrastructure Applications
IT Services
T: +1 514 398 3718
ron.h...@mcgill.ca<mailto:ron.h...@mcgill.ca> | 
www.mcgill.ca/it<https://mcgill.ca/it>

[cid:part7.AFA911F1.FD188252@mcgill.ca]
___
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: DNS Flag Day: I had to open the TCP/53 port

2019-02-04 Thread Roberto Carna
Thanks Ben for your response, can you tell me the types of TCP traffic I
have to expect in BIND, excepting Zone Tansfer?

Thans a lot again!!!

El lun., 4 feb. 2019 a las 10:50, Ben Croswell ()
escribió:

> BIND has always required UDP and TCP 53 for proper functionality. It
> sometimes mistakenly believed that TCP is only for zone transfers but that
> is not the case.
>
> On Mon, Feb 4, 2019, 8:46 AM Roberto Carna  wrote:
>
>> Dear, I have a BIND 9.10 public server and I have delegated some public
>> domains.
>>
>> When I test these domains with the EDNS tool offered in the DNS Flag Day
>> webpage, the test was wrong wit just UDP/53 port opened to Internet.
>>
>> After that, when I opened also TCP/53 port, the test was succesful.
>>
>> Please can you explain me the reason I have to open TCP/53 port to
>> Internet from February 1st to the future???
>>
>> Really thanks, regards.
>> ___
>> 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: DNS Flag Day: I had to open the TCP/53 port

2019-02-04 Thread Ben Croswell
BIND has always required UDP and TCP 53 for proper functionality. It
sometimes mistakenly believed that TCP is only for zone transfers but that
is not the case.

On Mon, Feb 4, 2019, 8:46 AM Roberto Carna  Dear, I have a BIND 9.10 public server and I have delegated some public
> domains.
>
> When I test these domains with the EDNS tool offered in the DNS Flag Day
> webpage, the test was wrong wit just UDP/53 port opened to Internet.
>
> After that, when I opened also TCP/53 port, the test was succesful.
>
> Please can you explain me the reason I have to open TCP/53 port to
> Internet from February 1st to the future???
>
> Really thanks, regards.
> ___
> 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


DNS Flag Day: I had to open the TCP/53 port

2019-02-04 Thread Roberto Carna
Dear, I have a BIND 9.10 public server and I have delegated some public
domains.

When I test these domains with the EDNS tool offered in the DNS Flag Day
webpage, the test was wrong wit just UDP/53 port opened to Internet.

After that, when I opened also TCP/53 port, the test was succesful.

Please can you explain me the reason I have to open TCP/53 port to Internet
from February 1st to the future???

Really thanks, regards.
___
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: DNS-FLAG-Day

2019-01-28 Thread Matus UHLAR - fantomas

On 28.01.19 13:28, Umut Arus wrote:

Don't forget check your IPS. Some IPS rules and tcp ACL can block the
requests. For example, our Checkpoint IPS stopped the requests.


were they requests from you as client or to you as server?


On Mon, Jan 28, 2019 at 1:14 PM Matus UHLAR - fantomas via bind-users <
bind-users@lists.isc.org> wrote:


On 28.01.19 09:25, MEjaz wrote:
>For the upcoming DNS Flag Day on February 1st, 2019.  Is there any
>impact on the user whose using bind name servers.
>
>
>
>As per the infoblox DNS service, they  will not be impacted on DNS Flag
>day.  So Do I need configure support for EDNS0 standards?  In bind if
>yes how to do that.

EDNS0 is compiled and supported in BIND by default.
You only need to check if your settings or firewalls don't block DNS
without
EDNS0

you can test your zones on https://ednscomp.isc.org/ednscomp

according to information https://dnsflagday.net/, your client should not
be blocked from sending EDNS queries.



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)
___
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: DNS-FLAG-Day

2019-01-28 Thread Umut Arus
Hi,

Don't forget check your IPS. Some IPS rules and tcp ACL can block the
requests. For example, our Checkpoint IPS stopped the requests.

regards.

On Mon, Jan 28, 2019 at 1:14 PM Matus UHLAR - fantomas via bind-users <
bind-users@lists.isc.org> wrote:

> On 28.01.19 09:25, MEjaz wrote:
> >For the upcoming DNS Flag Day on February 1st, 2019. Is there any impact
> on
> >the user whose using bind name servers.
> >
> >
> >
> >As per the infoblox DNS service, they  will not be impacted on DNS Flag
> day.
> >So Do I need configure support for EDNS0 standards? In bind if yes how to
> do
> >that.
>
> EDNS0 is compiled and supported in BIND by default.
> You only need to check if your settings or firewalls don't block DNS
> without
> EDNS0
>
> you can test your zones on https://ednscomp.isc.org/ednscomp
>
> according to information https://dnsflagday.net/, your client should not
> be
> blocked from sending EDNS queries.
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Windows 2000: 640 MB ought to be enough for anybody
> ___
> 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
>


-- 
*Umut Arus*
Information Technology
Sabancı University
___
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: DNS-FLAG-Day

2019-01-28 Thread Matus UHLAR - fantomas via bind-users

On 28.01.19 09:25, MEjaz wrote:

For the upcoming DNS Flag Day on February 1st, 2019. Is there any impact on
the user whose using bind name servers.



As per the infoblox DNS service, they  will not be impacted on DNS Flag day.
So Do I need configure support for EDNS0 standards? In bind if yes how to do
that.


EDNS0 is compiled and supported in BIND by default.
You only need to check if your settings or firewalls don't block DNS without
EDNS0 


you can test your zones on https://ednscomp.isc.org/ednscomp

according to information https://dnsflagday.net/, your client should not be
blocked from sending EDNS queries.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows 2000: 640 MB ought to be enough for anybody
___
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


DNS-FLAG-Day

2019-01-27 Thread MEjaz
Hello sir, 

 

For the upcoming DNS Flag Day on February 1st, 2019. Is there any impact on
the user whose using bind name servers.  

 

As per the infoblox DNS service, they  will not be impacted on DNS Flag day.
So Do I need configure support for EDNS0 standards? In bind if yes how to do
that. 

 

Thanks in advance..

 

Ejaz 

___
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: DNS Flag Day may cause any problem in private DNS servers ?

2019-01-25 Thread Roberto Carna
Thanks a lot!

El jue., 24 ene. 2019 a las 16:24, Evan Hunt () escribió:

> On Thu, Jan 24, 2019 at 10:53:49AM -0300, Roberto Carna wrote:
> > Dear, I've just worked around on my public BIND DNS's in order to solve
> the
> > problem of DNS Flag Day.
> >
> > But I have a pair of private DNS (BIND and Windows) that respond to
> > internal queries and also forward non authoritative queries to my public
> > DNS'smay my private DNS's become unstables after DNS Flag Day if I
> > don't any workaround on them ?
>
> DNS flag day is when vendors of recursive name servers will stop releasing
> new software that coddles ancient or broken authoritative servers and
> firewalls. Instead of trying over and over in different ways to coax some
> broken remote system to send back an answer, new resolver software will
> just declare the remote server to be broken, and give up.
>
> Nothing will stop working suddenly on February 1. However, the next time
> you upgrade your recursive name server to the latest version, you *might*
> have problems then.  My guess is that you won't, but I can't guarantee it.
>
> If you do have some legacy server running internally that can't be fixed to
> support EDNS properly, you can still configure your resolvers not to use
> EDNS when talking to that specific server. That option will still be
> available after flag day.
>
> An easy way to check would be to install the latest BIND development
> release (version 9.13.5) and see if it works. It already has all the flag
> day changes in it.
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
>
___
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: DNS Flag Day may cause any problem in private DNS servers ?

2019-01-24 Thread Evan Hunt
On Thu, Jan 24, 2019 at 10:53:49AM -0300, Roberto Carna wrote:
> Dear, I've just worked around on my public BIND DNS's in order to solve the
> problem of DNS Flag Day.
> 
> But I have a pair of private DNS (BIND and Windows) that respond to
> internal queries and also forward non authoritative queries to my public
> DNS'smay my private DNS's become unstables after DNS Flag Day if I
> don't any workaround on them ?

DNS flag day is when vendors of recursive name servers will stop releasing
new software that coddles ancient or broken authoritative servers and
firewalls. Instead of trying over and over in different ways to coax some
broken remote system to send back an answer, new resolver software will
just declare the remote server to be broken, and give up.

Nothing will stop working suddenly on February 1. However, the next time
you upgrade your recursive name server to the latest version, you *might*
have problems then.  My guess is that you won't, but I can't guarantee it.

If you do have some legacy server running internally that can't be fixed to
support EDNS properly, you can still configure your resolvers not to use
EDNS when talking to that specific server. That option will still be
available after flag day.

An easy way to check would be to install the latest BIND development
release (version 9.13.5) and see if it works. It already has all the flag
day changes in it.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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


DNS Flag Day may cause any problem in private DNS servers ?

2019-01-24 Thread Roberto Carna
Dear, I've just worked around on my public BIND DNS's in order to solve the
problem of DNS Flag Day.

But I have a pair of private DNS (BIND and Windows) that respond to
internal queries and also forward non authoritative queries to my public
DNS'smay my private DNS's become unstables after DNS Flag Day if I
don't any workaround on them ?

Thanks a lot,

Robert
___
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: DNS flag day

2019-01-18 Thread Mark Andrews


> On 19 Jan 2019, at 6:58 am, Ben Croswell  wrote:
> 
> I would say we had one provider go as far as saying this whole flag day thing 
> is a hoax. Not sure what option there is other than voting with your wallet 
> and moving to a different provider.

You can go read the source code and see where the work arounds have been 
removed.
There are a number of sites that will not be resolvable without manual 
configuration
after flag day.  As BIND also uses DNS COOKIE those sites that block DNS COOKIE 
option
will be in the list.  Also those running old versions of Windows DNS will be 
problematic
as they don’t consistently respond to EDNS queries with FORMERR.  They respond 
*once* then
stop responding for a short while.  If there is packet loss the server becomes 
non responsive.

> May even be worth looking at 2 providers. I see DNS provider redundancy as 
> being a huge priority after the Dyn DDoS event.
> 
> On Fri, Jan 18, 2019, 2:50 PM Lightner, Jeffrey  wrote:
> On checking I find that any of our domains that use Network Solutions’ 
> Worldnic.com nameservers are reporting failures when checked.  
> 
> For example this result:  https://ednscomp.isc.org/ednscomp/e30c6cf0ea
> 
> Other people online have posted about Network Solutions as they also saw 
> failures. 

Well the answers to the test queries are *wrong*.  The servers DO NOT implement 
EDNS
version negotiation.  This isn’t a DNS flag day issue but a future 
interoperability issue.

[beetle:~/git/bind9] marka% dig brewerrepair.com. @207.204.40.143 +edns=1 
+noednsne

; <<>> DiG 9.13.1+hotspot+add-prefetch+marka <<>> brewerrepair.com. 
@207.204.40.143 +edns=1 +noednsne
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37712
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 2800
;; QUESTION SECTION:
;brewerrepair.com.  IN  A

;; ANSWER SECTION:
brewerrepair.com.   7200IN  A   199.192.145.62

;; Query time: 836 msec
;; SERVER: 207.204.40.143#53(207.204.40.143)
;; WHEN: Sat Jan 19 07:48:28 AEDT 2019
;; MSG SIZE  rcvd: 61

[beetle:~/git/bind9] marka% 

You should see a answer like this one from the root servers which *do* 
implement EDNS fully.

[beetle:~/git/bind9] marka% dig brewerrepair.com. @a.root-servers.net +edns=1 
+noednsne

; <<>> DiG 9.13.1+hotspot+add-prefetch+marka <<>> brewerrepair.com. 
@a.root-servers.net +edns=1 +noednsne
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 31554
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; Query time: 184 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Sat Jan 19 07:49:20 AEDT 2019
;; MSG SIZE  rcvd: 23

[beetle:~/git/bind9] marka% 


> On calling Network Solutions today they told me they are compliant despite 
> what was reported by https://dnsflagday.net/   

Well they are mistaken.

> This issue is with domains registered at Network Solutions and using their 
> Advanced DNS (i.e. their Worldnic name servers).   Other domains we have 
> registered with them but pointing to other name servers (i.e. our own BIND 
> servers) displayed as compliant.   
> 
> When I sent them the links they saw what I saw but still claimed they are 
> compliant.   They refused to send me something in writing stating that so I 
> suggested they reach out to ISC regarding the checker’s results if they 
> believe they are compliant, but they said they don’t see the need.   I’ve 
> asked them to escalate and they say they have but I suspect I’ll not hear 
> back from them.
> 
> Is there a list of known edns compliant Registrar name severs for the larger 
> Registrars?
> 
> Is it possible the failures seen are false?   If so, are there alternate edns 
> compliance checkers that might show different responses than dnsflagday.net?  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> From: bind-users  On Behalf Of Ben Croswell
> Sent: Friday, January 18, 2019 12:19 PM
> To: bind-users@lists.isc.org
> Subject: Re: DNS flag day
> 
>  
> 
> I shouldn't have posted so closely to responding to the other user.
> 
>  
> 
> I am not running 9.8. I was replying to them about firewalls in regards to 
> their 9.8 issues.
> 
>  
> 
> Was just hoping for a statement of 9.x or greater supports the needed badvers 
> signaling etc.
> 
>  
> 
> On Fri, Jan 18, 2019, 12:15 PM Victoria Risk  
>  
> 
> On Jan 18, 2019, at 9:09 AM, Ben Croswell  wrote:
> 
>  
> 
> Has ISC released minimum viable BIND ve

Re: DNS flag day

2019-01-18 Thread Warren Kumari
On Fri, Jan 18, 2019 at 3:28 PM Ben Croswell  wrote:

> I would imagine "its a hoax" is code for we dont want to bother
> remediating.
>
>
yah, I get their "Don't want to do it" position, but "It's a hoax" seems
like a poor selection from the possible excuses -- when flag day occurs it
will be clear that this wasn't a hoax, being tricked simply makes you look
stupid / uninformed.

Much better excuses would be along the lines of "We are planning on
remediating" (and hoping the issue goes away), "We are philosophically
opposed to this", "We believe that we are compliant and the testing is
busticated", "This doesn't apply to us", "Nope, you misunderstood, this
only need to be mitigated by servers which process EDNS replies, and our
servers don't do that." or "That's a question for the architecture team,
I'll get them to call you back the week after next. Pardon? I didn't take
your phone number? Oh well", or even "sorry, I'm going through a tunnel and
my reception is poor... EDNS, yes .. comp..
mitiga.." :-P

W


> On Fri, Jan 18, 2019, 3:20 PM Warren Kumari 
>>
>>
>> On Fri, Jan 18, 2019 at 2:58 PM Ben Croswell 
>> wrote:
>>
>>> I would say we had one provider go as far as saying this whole flag day
>>> thing is a hoax.
>>>
>>
>> That's a weird stance / position. "The whole flag day thing is
>> [stupid|overblown|annoying|confusing|on a Friday]" are all positions I can
>> understand - not agree with (modulo the Friday one), but at least
>> understand. 'tis a hoax is just confusing...
>> Flag Day been discussed at length, and presented at multiple DNS events -
>> it seems that a DNS provider who hasn't seen any of the presentations and
>> recognized at least one person pushing this isn't well connected to the
>> community, and should probably be avoided...
>>
>> W
>> P.S: Unless they think it is simply a *very* subtle, long running,
>> widespread hoax... and now I'm wondering if I'm the patsy here :-P
>>
>>
>>
>>
>>> Not sure what option there is other than voting with your wallet and
>>> moving to a different provider.
>>>
>>
>>> May even be worth looking at 2 providers. I see DNS provider redundancy
>>> as being a huge priority after the Dyn DDoS event.
>>>
>>> On Fri, Jan 18, 2019, 2:50 PM Lightner, Jeffrey <
>>> jlight...@dsservices.com wrote:
>>>
>>>> On checking I find that any of our domains that use Network Solutions’
>>>> Worldnic.com nameservers are reporting failures when checked.
>>>>
>>>> For example this result:  https://ednscomp.isc.org/ednscomp/e30c6cf0ea
>>>>
>>>> Other people online have posted about Network Solutions as they also
>>>> saw failures.
>>>>
>>>> On calling Network Solutions today they told me they are compliant
>>>> despite what was reported by https://dnsflagday.net/
>>>>
>>>>
>>>>
>>>> This issue is with domains registered at Network Solutions and using
>>>> their Advanced DNS (i.e. their Worldnic name servers).   Other domains we
>>>> have registered with them but pointing to other name servers (i.e. our own
>>>> BIND servers) displayed as compliant.
>>>>
>>>> When I sent them the links they saw what I saw but still claimed they
>>>> are compliant.   They refused to send me something in writing stating that
>>>> so I suggested they reach out to ISC regarding the checker’s results if
>>>> they believe they are compliant, but they said they don’t see the need.
>>>> I’ve asked them to escalate and they say they have but I suspect I’ll not
>>>> hear back from them.
>>>>
>>>> Is there a list of known edns compliant Registrar name severs for the
>>>> larger Registrars?
>>>>
>>>> Is it possible the failures seen are false?   If so, are there
>>>> alternate edns compliance checkers that might show different responses than
>>>> dnsflagday.net?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From:* bind-users  * On Behalf Of *Ben
>>>> Croswell
>>>> *Sent:* Friday, January 18, 2019 12:19 PM
>>>> *To:* bind-users@lists.isc.org
>>>> *Subject:* Re: DNS flag day
>>>>
>>>>
>>>>
>>>> I shouldn't have posted so closely to responding to th

Re: DNS flag day

2019-01-18 Thread Ben Croswell
I would imagine "its a hoax" is code for we dont want to bother remediating.

On Fri, Jan 18, 2019, 3:20 PM Warren Kumari 
>
> On Fri, Jan 18, 2019 at 2:58 PM Ben Croswell 
> wrote:
>
>> I would say we had one provider go as far as saying this whole flag day
>> thing is a hoax.
>>
>
> That's a weird stance / position. "The whole flag day thing is
> [stupid|overblown|annoying|confusing|on a Friday]" are all positions I can
> understand - not agree with (modulo the Friday one), but at least
> understand. 'tis a hoax is just confusing...
> Flag Day been discussed at length, and presented at multiple DNS events -
> it seems that a DNS provider who hasn't seen any of the presentations and
> recognized at least one person pushing this isn't well connected to the
> community, and should probably be avoided...
>
> W
> P.S: Unless they think it is simply a *very* subtle, long running,
> widespread hoax... and now I'm wondering if I'm the patsy here :-P
>
>
>
>
>> Not sure what option there is other than voting with your wallet and
>> moving to a different provider.
>>
>
>> May even be worth looking at 2 providers. I see DNS provider redundancy
>> as being a huge priority after the Dyn DDoS event.
>>
>> On Fri, Jan 18, 2019, 2:50 PM Lightner, Jeffrey > wrote:
>>
>>> On checking I find that any of our domains that use Network Solutions’
>>> Worldnic.com nameservers are reporting failures when checked.
>>>
>>> For example this result:  https://ednscomp.isc.org/ednscomp/e30c6cf0ea
>>>
>>> Other people online have posted about Network Solutions as they also saw
>>> failures.
>>>
>>> On calling Network Solutions today they told me they are compliant
>>> despite what was reported by https://dnsflagday.net/
>>>
>>>
>>>
>>> This issue is with domains registered at Network Solutions and using
>>> their Advanced DNS (i.e. their Worldnic name servers).   Other domains we
>>> have registered with them but pointing to other name servers (i.e. our own
>>> BIND servers) displayed as compliant.
>>>
>>> When I sent them the links they saw what I saw but still claimed they
>>> are compliant.   They refused to send me something in writing stating that
>>> so I suggested they reach out to ISC regarding the checker’s results if
>>> they believe they are compliant, but they said they don’t see the need.
>>> I’ve asked them to escalate and they say they have but I suspect I’ll not
>>> hear back from them.
>>>
>>> Is there a list of known edns compliant Registrar name severs for the
>>> larger Registrars?
>>>
>>> Is it possible the failures seen are false?   If so, are there alternate
>>> edns compliance checkers that might show different responses than
>>> dnsflagday.net?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* bind-users  * On Behalf Of *Ben
>>> Croswell
>>> *Sent:* Friday, January 18, 2019 12:19 PM
>>> *To:* bind-users@lists.isc.org
>>> *Subject:* Re: DNS flag day
>>>
>>>
>>>
>>> I shouldn't have posted so closely to responding to the other user.
>>>
>>>
>>>
>>> I am not running 9.8. I was replying to them about firewalls in regards
>>> to their 9.8 issues.
>>>
>>>
>>>
>>> Was just hoping for a statement of 9.x or greater supports the needed
>>> badvers signaling etc.
>>>
>>>
>>>
>>> On Fri, Jan 18, 2019, 12:15 PM Victoria Risk >>
>>>
>>>
>>> On Jan 18, 2019, at 9:09 AM, Ben Croswell 
>>> wrote:
>>>
>>>
>>>
>>> Has ISC released minimum viable BIND version for flag day?
>>>
>>>
>>>
>>> Most versions of BIND authoritative servers, going back years, are EDNS
>>> compatible. Certainly ALL currently supported versions are compatible. I
>>> see you are running 9.8, which has been EOL since September, 2014.  I think
>>> that is probably fine, as far as EDNS, however.
>>>
>>>
>>>
>>> The change in BIND related to DNS Flag Day is removing workarounds from
>>> resolvers, that will retry without EDNS or otherwise try to proceed even
>>> when EDNS fails. This change came in the BIND 9.13 development version, and
>>> will be in BIND 9.14, which is not yet released.
>>>
>>>
>>>
>>> The problem 

Re: DNS flag day

2019-01-18 Thread Warren Kumari
On Fri, Jan 18, 2019 at 2:58 PM Ben Croswell  wrote:

> I would say we had one provider go as far as saying this whole flag day
> thing is a hoax.
>

That's a weird stance / position. "The whole flag day thing is
[stupid|overblown|annoying|confusing|on a Friday]" are all positions I can
understand - not agree with (modulo the Friday one), but at least
understand. 'tis a hoax is just confusing...
Flag Day been discussed at length, and presented at multiple DNS events -
it seems that a DNS provider who hasn't seen any of the presentations and
recognized at least one person pushing this isn't well connected to the
community, and should probably be avoided...

W
P.S: Unless they think it is simply a *very* subtle, long running,
widespread hoax... and now I'm wondering if I'm the patsy here :-P




> Not sure what option there is other than voting with your wallet and
> moving to a different provider.
>

> May even be worth looking at 2 providers. I see DNS provider redundancy as
> being a huge priority after the Dyn DDoS event.
>
> On Fri, Jan 18, 2019, 2:50 PM Lightner, Jeffrey  wrote:
>
>> On checking I find that any of our domains that use Network Solutions’
>> Worldnic.com nameservers are reporting failures when checked.
>>
>> For example this result:  https://ednscomp.isc.org/ednscomp/e30c6cf0ea
>>
>> Other people online have posted about Network Solutions as they also saw
>> failures.
>>
>> On calling Network Solutions today they told me they are compliant
>> despite what was reported by https://dnsflagday.net/
>>
>>
>>
>> This issue is with domains registered at Network Solutions and using
>> their Advanced DNS (i.e. their Worldnic name servers).   Other domains we
>> have registered with them but pointing to other name servers (i.e. our own
>> BIND servers) displayed as compliant.
>>
>> When I sent them the links they saw what I saw but still claimed they are
>> compliant.   They refused to send me something in writing stating that so I
>> suggested they reach out to ISC regarding the checker’s results if they
>> believe they are compliant, but they said they don’t see the need.   I’ve
>> asked them to escalate and they say they have but I suspect I’ll not hear
>> back from them.
>>
>> Is there a list of known edns compliant Registrar name severs for the
>> larger Registrars?
>>
>> Is it possible the failures seen are false?   If so, are there alternate
>> edns compliance checkers that might show different responses than
>> dnsflagday.net?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* bind-users  * On Behalf Of *Ben
>> Croswell
>> *Sent:* Friday, January 18, 2019 12:19 PM
>> *To:* bind-users@lists.isc.org
>> *Subject:* Re: DNS flag day
>>
>>
>>
>> I shouldn't have posted so closely to responding to the other user.
>>
>>
>>
>> I am not running 9.8. I was replying to them about firewalls in regards
>> to their 9.8 issues.
>>
>>
>>
>> Was just hoping for a statement of 9.x or greater supports the needed
>> badvers signaling etc.
>>
>>
>>
>> On Fri, Jan 18, 2019, 12:15 PM Victoria Risk >
>>
>>
>> On Jan 18, 2019, at 9:09 AM, Ben Croswell  wrote:
>>
>>
>>
>> Has ISC released minimum viable BIND version for flag day?
>>
>>
>>
>> Most versions of BIND authoritative servers, going back years, are EDNS
>> compatible. Certainly ALL currently supported versions are compatible. I
>> see you are running 9.8, which has been EOL since September, 2014.  I think
>> that is probably fine, as far as EDNS, however.
>>
>>
>>
>> The change in BIND related to DNS Flag Day is removing workarounds from
>> resolvers, that will retry without EDNS or otherwise try to proceed even
>> when EDNS fails. This change came in the BIND 9.13 development version, and
>> will be in BIND 9.14, which is not yet released.
>>
>>
>>
>> The problem you are seeing is most likely firewall-related.
>>
>>
>>
>> Vicky
>>
>>
>>
>>
>>
>> I looked around and couldn't find anything.
>>
>> ___
>> 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: DNS flag day

2019-01-18 Thread Ben Croswell
I would say we had one provider go as far as saying this whole flag day
thing is a hoax. Not sure what option there is other than voting with your
wallet and moving to a different provider.

May even be worth looking at 2 providers. I see DNS provider redundancy as
being a huge priority after the Dyn DDoS event.

On Fri, Jan 18, 2019, 2:50 PM Lightner, Jeffrey  On checking I find that any of our domains that use Network Solutions’
> Worldnic.com nameservers are reporting failures when checked.
>
> For example this result:  https://ednscomp.isc.org/ednscomp/e30c6cf0ea
>
> Other people online have posted about Network Solutions as they also saw
> failures.
>
> On calling Network Solutions today they told me they are compliant despite
> what was reported by https://dnsflagday.net/
>
>
>
> This issue is with domains registered at Network Solutions and using their
> Advanced DNS (i.e. their Worldnic name servers).   Other domains we have
> registered with them but pointing to other name servers (i.e. our own BIND
> servers) displayed as compliant.
>
> When I sent them the links they saw what I saw but still claimed they are
> compliant.   They refused to send me something in writing stating that so I
> suggested they reach out to ISC regarding the checker’s results if they
> believe they are compliant, but they said they don’t see the need.   I’ve
> asked them to escalate and they say they have but I suspect I’ll not hear
> back from them.
>
> Is there a list of known edns compliant Registrar name severs for the
> larger Registrars?
>
> Is it possible the failures seen are false?   If so, are there alternate
> edns compliance checkers that might show different responses than
> dnsflagday.net?
>
>
>
>
>
>
>
>
>
> *From:* bind-users  * On Behalf Of *Ben
> Croswell
> *Sent:* Friday, January 18, 2019 12:19 PM
> *To:* bind-users@lists.isc.org
> *Subject:* Re: DNS flag day
>
>
>
> I shouldn't have posted so closely to responding to the other user.
>
>
>
> I am not running 9.8. I was replying to them about firewalls in regards to
> their 9.8 issues.
>
>
>
> Was just hoping for a statement of 9.x or greater supports the needed
> badvers signaling etc.
>
>
>
> On Fri, Jan 18, 2019, 12:15 PM Victoria Risk 
>
>
> On Jan 18, 2019, at 9:09 AM, Ben Croswell  wrote:
>
>
>
> Has ISC released minimum viable BIND version for flag day?
>
>
>
> Most versions of BIND authoritative servers, going back years, are EDNS
> compatible. Certainly ALL currently supported versions are compatible. I
> see you are running 9.8, which has been EOL since September, 2014.  I think
> that is probably fine, as far as EDNS, however.
>
>
>
> The change in BIND related to DNS Flag Day is removing workarounds from
> resolvers, that will retry without EDNS or otherwise try to proceed even
> when EDNS fails. This change came in the BIND 9.13 development version, and
> will be in BIND 9.14, which is not yet released.
>
>
>
> The problem you are seeing is most likely firewall-related.
>
>
>
> Vicky
>
>
>
>
>
> I looked around and couldn't find anything.
>
> ___
> 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: DNS flag day

2019-01-18 Thread Lightner, Jeffrey
On checking I find that any of our domains that use Network Solutions’ 
Worldnic.com nameservers are reporting failures when checked.

For example this result:  https://ednscomp.isc.org/ednscomp/e30c6cf0ea

Other people online have posted about Network Solutions as they also saw 
failures.

On calling Network Solutions today they told me they are compliant despite what 
was reported by https://dnsflagday.net/

This issue is with domains registered at Network Solutions and using their 
Advanced DNS (i.e. their Worldnic name servers).   Other domains we have 
registered with them but pointing to other name servers (i.e. our own BIND 
servers) displayed as compliant.

When I sent them the links they saw what I saw but still claimed they are 
compliant.   They refused to send me something in writing stating that so I 
suggested they reach out to ISC regarding the checker’s results if they believe 
they are compliant, but they said they don’t see the need.   I’ve asked them to 
escalate and they say they have but I suspect I’ll not hear back from them.

Is there a list of known edns compliant Registrar name severs for the larger 
Registrars?

Is it possible the failures seen are false?   If so, are there alternate edns 
compliance checkers that might show different responses than dnsflagday.net?




From: bind-users  On Behalf Of Ben Croswell
Sent: Friday, January 18, 2019 12:19 PM
To: bind-users@lists.isc.org
Subject: Re: DNS flag day

I shouldn't have posted so closely to responding to the other user.

I am not running 9.8. I was replying to them about firewalls in regards to 
their 9.8 issues.

Was just hoping for a statement of 9.x or greater supports the needed badvers 
signaling etc.

On Fri, Jan 18, 2019, 12:15 PM Victoria Risk 
mailto:vi...@isc.org> wrote:

On Jan 18, 2019, at 9:09 AM, Ben Croswell 
mailto:ben.crosw...@gmail.com>> wrote:

Has ISC released minimum viable BIND version for flag day?

Most versions of BIND authoritative servers, going back years, are EDNS 
compatible. Certainly ALL currently supported versions are compatible. I see 
you are running 9.8, which has been EOL since September, 2014.  I think that is 
probably fine, as far as EDNS, however.

The change in BIND related to DNS Flag Day is removing workarounds from 
resolvers, that will retry without EDNS or otherwise try to proceed even when 
EDNS fails. This change came in the BIND 9.13 development version, and will be 
in BIND 9.14, which is not yet released.

The problem you are seeing is most likely firewall-related.

Vicky


I looked around and couldn't find anything.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org<mailto: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: DNS flag day

2019-01-18 Thread Victoria Risk


> On Jan 18, 2019, at 9:18 AM, Ben Croswell  wrote:
> 
> I shouldn't have posted so closely to responding to the other user.

Oh, my mistake.  How is this for a definitve statement?

BIND 9 was designed to be EDNS compliant from very beginning. All 
currently-supported branches of BIND 9 are EDNS-compliant. That includes 9.11, 
9.12 and 9.13.  We strongly advise running a version supported by ISC or the 
vendor as there could be bugs related to EDNS in earlier versions.

I realize a lot of ppl on bind-users are running eol versions anyway. 
We did poke around a bit here, and found we fixed some minor EDNS issue with 
change #3949 in 2014. That was also about the time we added dig +ednsopt. I 
don’t know what the issue was or if it is significant, but I am sure that any 
version issued since 2014 would be compliant vs the ednscomp tool.

 
> 
> I am not running 9.8. I was replying to them about firewalls in regards to 
> their 9.8 issues.
> 
> Was just hoping for a statement of 9.x or greater supports the needed badvers 
> signaling etc.
> 
> On Fri, Jan 18, 2019, 12:15 PM Victoria Risk  <mailto:vi...@isc.org> wrote:
> 
>> On Jan 18, 2019, at 9:09 AM, Ben Croswell > <mailto:ben.crosw...@gmail.com>> wrote:
>> 
>> Has ISC released minimum viable BIND version for flag day?
> 
> Most versions of BIND authoritative servers, going back years, are EDNS 
> compatible. Certainly ALL currently supported versions are compatible. I see 
> you are running 9.8, which has been EOL since September, 2014.  I think that 
> is probably fine, as far as EDNS, however.
> 
> The change in BIND related to DNS Flag Day is removing workarounds from 
> resolvers, that will retry without EDNS or otherwise try to proceed even when 
> EDNS fails. This change came in the BIND 9.13 development version, and will 
> be in BIND 9.14, which is not yet released.
> 
> The problem you are seeing is most likely firewall-related.
> 
> Vicky
> 
>> 
>> I looked around and couldn't find anything. 
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users 
>> <https://lists.isc.org/mailman/listinfo/bind-users> to unsubscribe from this 
>> list
>> 
>> bind-users mailing list
>> bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>
>> https://lists.isc.org/mailman/listinfo/bind-users 
>> <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

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@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: DNS flag day

2019-01-18 Thread Ben Croswell
I shouldn't have posted so closely to responding to the other user.

I am not running 9.8. I was replying to them about firewalls in regards to
their 9.8 issues.

Was just hoping for a statement of 9.x or greater supports the needed
badvers signaling etc.

On Fri, Jan 18, 2019, 12:15 PM Victoria Risk 
> On Jan 18, 2019, at 9:09 AM, Ben Croswell  wrote:
>
> Has ISC released minimum viable BIND version for flag day?
>
>
> Most versions of BIND authoritative servers, going back years, are EDNS
> compatible. Certainly ALL currently supported versions are compatible. I
> see you are running 9.8, which has been EOL since September, 2014.  I think
> that is probably fine, as far as EDNS, however.
>
> The change in BIND related to DNS Flag Day is removing workarounds from
> resolvers, that will retry without EDNS or otherwise try to proceed even
> when EDNS fails. This change came in the BIND 9.13 development version, and
> will be in BIND 9.14, which is not yet released.
>
> The problem you are seeing is most likely firewall-related.
>
> Vicky
>
>
> I looked around and couldn't find anything.
> ___
> 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: DNS flag day

2019-01-18 Thread Victoria Risk

> On Jan 18, 2019, at 9:09 AM, Ben Croswell  wrote:
> 
> Has ISC released minimum viable BIND version for flag day?

Most versions of BIND authoritative servers, going back years, are EDNS 
compatible. Certainly ALL currently supported versions are compatible. I see 
you are running 9.8, which has been EOL since September, 2014.  I think that is 
probably fine, as far as EDNS, however.

The change in BIND related to DNS Flag Day is removing workarounds from 
resolvers, that will retry without EDNS or otherwise try to proceed even when 
EDNS fails. This change came in the BIND 9.13 development version, and will be 
in BIND 9.14, which is not yet released.

The problem you are seeing is most likely firewall-related.

Vicky

> 
> I looked around and couldn't find anything. 
> ___
> 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


DNS flag day

2019-01-18 Thread Ben Croswell
Has ISC released minimum viable BIND version for flag day?

I looked around and couldn't find anything.
___
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: DNS Flag Day - options for EDNS behavior control before then ?

2018-12-19 Thread Mark Andrews
Correct, there are no knobs in 9.13/9.14 for automatic fallback. 

Apart from a few very old Microsoft Windows DNS servers that don’t respond 
consistently to EDNS queries (they respond with FORMERR to the first query then 
don’t respond for a while to subsequent EDNS queries) there aren’t many servers 
that don’t answer EDNS queries any more.  That said there is still a single TLD 
server that doesn’t respond to EDNS queries at all.

server  { edns no; };

More likely you will strike a server that doesn’t respond to queries with DNS 
COOKIE options present and you will want to turn off sending that option.  This 
can be tested for with “dig +nocookie”.

server  { send-cookie no; };

Most of the problems are with stupid firewall defaults.  The firewall vendors 
want to be seen to be doing “something” with DNS and to hell with planned 
incremental deployment and interoperability.  STD 13 said what nameservers 
should do with unknown flags in the DNS header (ignore) and other changes 
(return FORMERR).  EDNS says to ignore unknown EDNS flags and options and to 
return BADVERS with the currently supported EDNS version for unsupported EDNS 
versions in requests.  These behaviours allow clients to be updated without 
having to update servers.  Firewall that drop queries aren’t doing anyone a 
service.  All they do is break interoperability.

Mark



> On 20 Dec 2018, at 6:39 am, Brandon Applegate  wrote:
> 
> Hello,
> 
> I did some searching on the ML archives and didn’t see what I’m trying to ask.
> 
> Is there anything (i.e. a config knob) in any current version of BIND that 
> allows one to control this ?
> 
> My understanding is that on (around ?) the DNS Flag Day of 2/1/19 - BIND 
> won’t retry (with EDNS disabled) non-answered EDNS queries - rather it will 
> consider them failures ?
> 
> I see that as of now there is this knob:
> 
> --
> server a.b.c.d {
>edns no;
> };
> —
> 
> But I’m talking about the behavior described in the DNS Flag day materials.  
> Is that simply going to be changed in code sometime around/on 2/1/19 ?
> 
> --
> Brandon Applegate - CCIE 10273
> PGP Key fingerprint:
> 0641 D285 A36F 533A 73E5  2541 4920 533C C616 703A
> "For thousands of years men dreamed of pacts with demons.
> Only now are such things possible."
> 
> ___
> 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


DNS Flag Day - options for EDNS behavior control before then ?

2018-12-19 Thread Brandon Applegate
Hello,

I did some searching on the ML archives and didn’t see what I’m trying to ask.

Is there anything (i.e. a config knob) in any current version of BIND that 
allows one to control this ?

My understanding is that on (around ?) the DNS Flag Day of 2/1/19 - BIND won’t 
retry (with EDNS disabled) non-answered EDNS queries - rather it will consider 
them failures ?

I see that as of now there is this knob:

--
server a.b.c.d {
edns no;
};
—

But I’m talking about the behavior described in the DNS Flag day materials.  Is 
that simply going to be changed in code sometime around/on 2/1/19 ?

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
0641 D285 A36F 533A 73E5  2541 4920 533C C616 703A
"For thousands of years men dreamed of pacts with demons.
Only now are such things possible."



signature.asc
Description: Message signed with OpenPGP
___
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