Bad owner name on hidden primary

[Mark Andrews]

In message <CFBC984D.185DB%ray.walker at nau.edu>, Raymond Drew Walker writes:
> On 6/9/14, 9:05 PM, "Mark Andrews" <marka at isc.org> wrote:
Input error
>
>
> >
> >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.

Named only knows it is a master or a slave for a zone.  It does not know
whether it is a hidden master or not.  There have been no check-names
related changes between BIND 9.5.4 and BIND 9.9.5.

> >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:

Host names have been letter-digit-hyphen (LDH) since the very
beginning.  Even IDN names are letter-digit-hyphen at the DNS level.
Sometimes one needs to push back.  The customer is not always right
especially when the standards are trying to make non overlapping
namespaces to prevent even bigger problems.

> 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

DNS-SD works with check-names turned on.  Named only blocks specific
name type combinations none of which impact on DNS-SD.

Check-names checks the following:

		A	Owner name
		AAAA	Owner name
		MX	Owner name and RDATA
		SRV	RDATA
		NS	RDATA
		RT	RDATA
		IN-ADDR.ARPA PTR RDATA
		IP6.ARPA PTR RDATA

Underscores where chosen for SRV owner names and DNS-SD because
they were *not* LHD so they exist in a seperate namespace to
hostnames.  Jon got this wrong when he edited the initial SRV RFC.
He dropped the underscores.  This got corrected.

Below is a list of all the check-name related changes over the history
of BIND 9.

2545.   [doc]           ARM: Legal hostname checking (check-names) is
                        for SRV RDATA too. [RT #19304]

1822.   [bug]           check-names test for RT was reversed. [RT #13382]

1749.   [bug]           'check-names response ignore;' failed to ignore.
                        [RT #12866]

1729.   [func]          Improve check-names error messages.

1728.   [doc]           Update check-names documentation.

1727.   [bug]           named-checkzone: check-names support didn't match
                        documentation.

1641.   [bug]           Update the check-names description in ARM. [RT #11389]

1612.   [bug]           check-names at the option/view level could trigger
                        an INSIST. [RT# 11116]

1586.   [func]          "check-names" is now implemented.

Mark

> 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<B2> clauses.
>
> Thanks much for your attention to this matter.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org