Bad owner name on hidden primary

[Raymond Drew Walker]

On 6/9/14, 9:05 PM, "Mark Andrews" <marka at isc.org> wrote:


>
>In message <CFBB81AD.184ED%ray.walker at 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.walker at nau.edu<mailto:ray.walker at nau.edu>>
>> Date: Monday, June 9, 2014 at 3:18 PM
>> To: "bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>"
>> <bind-users at lists.isc.org<mailto:bind-users at 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.walker at nau.edu<mailto:ray.walker at nau.edu>>
>> Date: Monday, June 9, 2014 at 11:47 AM
>> To: "bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>"
>> <bind-users at lists.isc.org<mailto:bind-users at 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: marka at isc.org