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
. 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
or 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 serv
: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 U
r, 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.
Pleas
akenly 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
> 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
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
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
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 s
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
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 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.
> >
> >
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
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 be
://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
int
>> 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.
>>
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
t 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 s
lagday.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 respond
? 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 close
ported 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 ED
> 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
> w
.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
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
htt
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-
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
27 matches
Mail list logo
