dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers
I'm using dig to perform health checks on DNS servers. I've recently noticed that I'm unable to complete a full zone transfer from Windows DC when using a version of dig 9.9.2 or newer (I haven't tried older revisions of dig 9.9.x). Dig starts to pull the records from Microsoft Windows DC but fails around the same SRV record with a message ";; Got bad packet: extra input data". I had the SRVs record re-created but this did not solve the issue. There are over 40,000 records on this zone. I can perform full zone transfers from the Windows DC if I use older versions of dig. I've tested with 9.3.6 and 9.7.0 and they all worked fine. I only seem to be having an issue with dig 9.9.x and the Windows DC controllers. I can transfer the same zone from Unix and Linux based BIND servers without any issues. Bind 9.9.x is able to perform zone transfers from the Windows DC without any issue. Performing a named-checkzone against the zone file with bind 9.9.4 and bind 9.9.2 returns no errors. It looks like the issue is just with DIG 9.9.2 and 9.9.4 (possibly other versions of dig 9.9). Has anyone ran into a similar issue? Any help would be greatly appreciated. Thank you. ___ 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
Caching and upper case issue with BIND 9.9.7-P3
After upgrading BIND from BIND 9.9.7-P2 to BIND 9.9.7-P3 on about a dozen authoritative + recursive servers, we noticed a strange caching issue on one of the servers. The server is authoritative for our main domain (let's assume example.com). There are multiple subdomains under example.com that have been NS delegated to other servers. Whenever the DNS server would respond to a recursive "A" record query from its cache, the "Answers" part of the request would always be in upper case - such as foo.bar.EXAMPLE.COM. More details below I noted the following behavior using a packet capture -A client requests for "foo.bar.example.com" "A" record. -Our server then does a lookup against bar.example.com authoritative server for "A" record "foo.bar.exampe.com" -Our server gets a response from bar.example.com authoritative server: ; ANSWER SECTION: foo.bar.example.com. 10 INA 192.168.0.1 -Our server responds to the clients request for foo.bar.example.com and stores the response for 10 seconds (the TTL of the record). At this point the answer section is still in all lower case - the clients gets the following: ; ANSWER SECTION: foo.bar.example.com. 10 INA 192.168.0.1 -The next time the client queries for foo.bar.exmaple.com, our server responds from the cache and changes the case from example.com to EXAMPLE.COM. It continues to serve EXAMPLE.COM in upper case as part of the answer while the TTL is still valid. ; ANSWER SECTION: foo.bar.EXAMPLE.COM. 9 INA 192.168.0.1 -This behavior was observed for "A" record responses for queries under any subdomain of example.com. The case was only change to upper case on the answer section. Example.com also appeared under the question, authority, and additional sections but only in the answer section was the case changed. We eventually restarted BIND and the issue went away. After restarting BIND all responses served from cache are now lower case, as expected. Has anyone seen this behavior before ? Is this a bug ? This caused issues for certain applications on our network that did string comparison and expected the answer section to be in lower case. ___ 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: Caching and upper case issue with BIND 9.9.7-P3
On Wednesday, September 23, 2015 at 12:01:15 PM UTC-4, Tony Finch wrote: > > That's a bug in those applications. I agree that this a bug on their application code. We've asked the application owners to fix their code. ___ 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: Caching and upper case issue with BIND 9.9.7-P3
On Wednesday, September 23, 2015 at 12:18:37 PM UTC-4, Evan Hunt wrote: > ... that's odd, the new case compression behavior was introduced a fair > bit earlier than that; are you sure you weren't upgrading a few servers > older than 9.9.7-P2? > We've ran 9.9.4, 9.9.6, 9.9.7, and 9.9.7-P2. We never had an issue until upgrading to 9.9.7-p3. Only one of the dozen severs we updated to experience this case issue. The issue cleared up once BIND was stopped and then restarted. > Those applications should be changed to use strcasecmp() not strcmp(). Application owners have been asked to update their code. However, restarting BIND seem to have corrected the issue we were seeing. > However, if that's not practical, you can configure named to work the way > it used to for selected clients, or for all clients. > > The case of the question is preserved in responses, but the case of the > answer can change. BIND (and most other DNS implementations) used to > compress names in responses in a way that forced the the answer to > conform to the case of the question. But the specification actually > says to preserve the original owner's case whenever possible, so we > changed it. Thanks for clarifying. It seems like our server in question was actually changing the case to upper case for just one domain. This behavior stopped once we bounced the server. However, I feel that the application should account for different case in DNS names. ___ 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: Caching and upper case issue with BIND 9.9.7-P3
On Wednesday, September 23, 2015 at 11:18:59 AM UTC-4, cypher Nix wrote: > After upgrading BIND from BIND 9.9.7-P2 to BIND 9.9.7-P3 on about a dozen > authoritative + recursive servers, we noticed a strange caching issue on one > of the servers. > > The server is authoritative for our main domain (let's assume example.com). > There are multiple subdomains under example.com that have been NS delegated to > other servers. Whenever the DNS server would respond to a recursive "A" > record query from its > cache, the "Answers" part of the request would always be in upper case - such > as foo.bar.EXAMPLE.COM. > More details below > I noted the following behavior using a packet capture > > -A client requests for "foo.bar.example.com" "A" record. > > -Our server then does a lookup against bar.example.com authoritative server > for "A" record "foo.bar.exampe.com" > > -Our server gets a response from bar.example.com authoritative server: > ; ANSWER SECTION: > foo.bar.example.com. 10 INA 192.168.0.1 > > -Our server responds to the clients request for foo.bar.example.com and stores > the response for 10 seconds (the TTL of the record). At this point the > answer section is still in all lower case - the clients gets the following: > ; ANSWER SECTION: > foo.bar.example.com. 10 INA 192.168.0.1 > > -The next time the client queries for foo.bar.exmaple.com, our server responds > from the cache and changes the case from example.com to EXAMPLE.COM. It > continues to serve EXAMPLE.COM in upper case as part of the answer while the > TTL is still valid. > ; ANSWER SECTION: > foo.bar.EXAMPLE.COM. 9 INA 192.168.0.1 > > -This behavior was observed for "A" record responses for queries under any > subdomain of example.com. The case was only change to upper case on the > answer section. Example.com also appeared under the question, authority, and > additional sections but only in the answer section was the case changed. > > We eventually restarted BIND and the issue went > away. After restarting BIND all responses served from cache are now lower > case, as expected. > > Has anyone seen this behavior before ? Is this a bug ? > This caused issues for certain applications on our network that did string > comparison and expected the answer section to be in lower case. Thank you all for your help. I was able to reproduce this behavior in the lab using older versions of BIND (9.9.7 P2 and 9.9.6 P1). I setup two servers in the lab: 1. A recursive server that's also authoritative for example.com and 2. an non recursive server that's authoritative for foo.example.com. The zone foo.example.com was delegated to server number 2. I added multiple sample records to both zones including a.foo.EXAMPLE.COM. I first started BIND on server number 2. Upon starting BIND on server number 1, the first query I looked up was a.foo.EXAMPLE.COM. All other responses served from cache had EXAMPLE and COM in upper case. I will use your responses along with my lab findings to convince the application owners that they must update their code in order to prevent issues in the future. ___ 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
