On 6/9/14, 9:05 PM, "Mark Andrews" <ma...@isc.org> wrote:
> >In message <cfbb81ad.184ed%ray.wal...@nau.edu>, Raymond Drew Walker >writes: >> >> Apologies, >> >> Our workaround was actually the addition of 2 lines: >> >> check-names master ignore; >> check-names response ignore; > >"check-names master ignore;" or "check-names ignore;" at the zone >level, is all that is required to have updates that would be block >by check-names accepted and returned. "check-names response ignore;" >is the default and has been in all release of BIND back to the >initial release where check-names was added in BIND 8. > >I suspect you were running a very out of date version of named on >the old master (pre-9.5.0). We¹ve been running current versions of NAMED on our master for at least the past year: 9.5.4 since Nov 2013 upgraded to 9.5.5 in April. Underscores in dynamic updates were not having any issue until our move to a hidden primary was just earlier this month. This is why I thought this behavior was interesting and worth getting to the bottom of. Currently if I remove either, updating fails for underscore hosts. >The correct fix is to stop using non-compliant names. As much as we¹d all love to live in a 1 RFC bubble, our customers do not allow us to. On the other hand, I don¹t like the idea of moving away from NAMED! I¹ll shortly tangent to explain: DNS-SD (DNS-Based Service Discovery): widely used here & requires underscores. ( RFC-6763 http://tools.ietf.org/html/rfc6763 ) Use of DNS-SD is quickly becoming inevitable for the modern enterprise DNS environment, as it gains support from many, many services that are becoming commonplace (SIP (VoIP), MS, Apple, etc.): http://www.dns-sd.org/ServiceTypes.html Coming full circle, my interest is more focused in what factors play into check-names behavior (why we were able to get away with this behavior for years,) and more importantly what best practices should be used for supporting DNS-SD. I¹m not too comfortable with the catch-all of not checking names being part of our main options section (or should I be?). I¹ve included some relevant information for debugging: (feel free to ask for more if applicable.) - Our old master (ns3.nau.edu) was reconfigured to run as an authoritative slave as the new hidden master was brought live. - The SOA MNAME record has stayed the same for zones we master (ns3.nau.edu). - Dynamic updates are made directly to the master, and are only granted via TSIG key based allow-update. - From my research, and how we do dynamic updates, we have not added any "allow-update-forwarding² clauses. Thanks much for your attention to this matter. > >Mark > >> Without the second `response' clause, the update does not error, but >>does >> not get applied to the record. >> - >> Raymond Walker >> Software Systems Engineer StSp. >> ITS - Northern Arizona University >> >> From: Ray Walker <ray.wal...@nau.edu<mailto:ray.wal...@nau.edu>> >> Date: Monday, June 9, 2014 at 3:18 PM >> To: "bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>" >> <bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>> >> Subject: Re: Bad owner name on hidden primary >> >> Our current workaround is to add the following to NAMED configuration: >> >> check-names master ignore; >> >> Is there a more preferred solution? >> >> ... >> or perhaps a different way of looking at this issue? >> - >> Raymond Walker >> Software Systems Engineer StSp. >> ITS - Northern Arizona University >> >> From: Ray Walker <ray.wal...@nau.edu<mailto:ray.wal...@nau.edu>> >> Date: Monday, June 9, 2014 at 11:47 AM >> To: "bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>" >> <bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>> >> Subject: Bad owner name on hidden primary >> >> Running BIND 9.9.5: >> >> On moving to a hidden primary setup, dynamic updates to zones we are >> master for with "unallowed characters" (underscores in our case) have >> started to fail with the error "bad owner name (check-names)" In the >>past >> (pre hidden primary) they did not fail. >> >> In the past we have not used the `check-names' option, so behavior >>should >> be default... >> odd since the default behavior is to fail for master zones. >> >> Could this have something to do with the SOA of the zone no longer being >> the actual primary? >> - >> Raymond Walker >> Software Systems Engineer StSp. >> ITS - Northern Arizona University >> > >-- >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
