RE: DNS Flag Day: I had to open the TCP/53 port
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
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
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
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
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
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
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
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
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
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
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
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 ?
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's....may 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 ?
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 ?
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
> 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
Re: DNS flag day
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 >>>> >>>> >>>> &g
Re: DNS flag day
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. >>> >>> >
Re: DNS flag day
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
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
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
> 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
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
> 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
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 ?
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 ?
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
