Bug 243565

Looks like regression between 9.3* and 9.4* series

I discuss this with upstream and problem is due "empty zones" feature in bind >=
9.4.0. (answer to empty zone records will be never send to other nameservers -
rfc1912, rfc3330) Please see into log. Messages like this could be there:

Jun 13 12:33:40 atkac named[12602]: automatic empty zone: 127.IN-ADDR.ARPA
Jun 13 12:33:40 atkac named[12602]: automatic empty zone: 254.169.IN-ADDR.ARPA
Jun 13 12:33:40 atkac named[12602]: automatic empty zone: 2.0.192.IN-ADDR.ARPA
Jun 13 12:33:40 atkac named[12602]: automatic empty zone:
255.255.255.255.IN-ADDR.ARPA
Jun 13 12:33:40 atkac named[12602]: automatic empty zone:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
Jun 13 12:33:40 atkac named[12602]: automatic empty zone:
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
Jun 13 12:33:40 atkac named[12602]: automatic empty zone: D.F.IP6.ARPA
Jun 13 12:33:40 atkac named[12602]: automatic empty zone: 8.E.F.IP6.ARPA
Jun 13 12:33:40 atkac named[12602]: automatic empty zone: 9.E.F.IP6.ARPA
Jun 13 12:33:40 atkac named[12602]: automatic empty zone: A.E.F.IP6.ARPA
Jun 13 12:33:40 atkac named[12602]: automatic empty zone: B.E.F.IP6.ARPA

I think that you declare IPv6 reverse loopback like this example:

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
       type master;
       file "named.ip6.local";
       allow-update { none; };
};

zone file:
@       IN      SOA     dhcp-lab-102.englab.brq.redhat.com. atkac.redhat.com.  (
                                     1997022700 ; Serial
                                     28800      ; Refresh
                                     14400      ; Retry
                                     3600000    ; Expire
                                     86400 )    ; Minimum
      IN      NS      dhcp-lab-102.englab.brq.redhat.com.
1      IN      PTR     localhost.

Only :: and ::1 (::/127) are carved out of ::/96.  You are attempting to
carve out ::/124. So named doesn't detect that you are going to declare empty
zone yourself and use his record. When you declared zone like this:

zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa"
{
}

@       SOA     ....
@	NS	....
@	PTR	localhost.

All works as expected. We discuss in upstream if something will be changed
around this.

Adam

In the end no change is needed. Current behavior is sufficient (named use record
which is more specific). You could disable empty zones with "empty-zones-enable"
parameter in your configfile or declare zone as written in comment #2

Adam

Please allow me to disagree.
The zone file in question is part of F7 distribution, not one of my creations.

Problem will remain until yourselves or BIND team apply some change still to be
determined.

First, we ought to agree what behaviour we require (setting aside any view of
how that is to be achieved or any apportionment of blame). IMHO this can be
summarised as follows:

1) Query LOCALHOST. for type ANY
LOCALHOST. IN A 127.0.0.1
LOCALHOST. IN AAAA ::1

2) Query 1.0.0.127.IN-ADDR.ARPA. for type PTR or ANY
1.0.0.127.IN-ADDR.ARPA. IN PTR LOCALHOST.

3) Query 1.0... ...0.IP6.ARPA. for type PTR or ANY
1.0... ...IP6.ARPA. IN PTR LOCALHOST.

4) Above queries must be resolvable without reference to any other nameserver.
This would seem to indicate either direct intervention within named or NS
records in zone file must refer to the loopback address.
@  IN NS LOCALHOST.
RFC3330 seems to say that any address within 127/8 is to be interpreted as a
loopback address. Using a wildcard PTR record may be a possible option. Design
decision about zone cuts can be deferred for the moment.

5) SOA MNAME field is defined to be the name of primary nameserver. As there is
only ever going to be one, that can only be LOCALHOST.
@ IN SOA LOCALHOST. <TBA> 2007061300, 3600, 600, 86400, 3600

If there are any other requirements to take account of, please let me know. I
will then attempt to package it in a way which will happily coexist with named 9.4.

Ok, I will release fixed configfiles in next release.
===================================================================
RCS file: /cvs/pkgs/rpms/bind/F-7/named.ip6.local,v
retrieving revision 1.1
diff -u -r1.1 named.ip6.local
--- named.ip6.local     7 Mar 2006 04:25:38 -0000       1.1
+++ named.ip6.local     14 Jun 2007 10:10:01 -0000
@@ -5,5 +5,5 @@
                                       14400      ; Retry
                                       3600000    ; Expire
                                       86400 )    ; Minimum
-       IN      NS      localhost.
-1      IN      PTR     localhost.
+@      IN      NS      localhost.
+@      IN      PTR     localhost.
Index: named.rfc1912.zones
===================================================================
RCS file: /cvs/pkgs/rpms/bind/F-7/named.rfc1912.zones,v
retrieving revision 1.3
diff -u -r1.3 named.rfc1912.zones
--- named.rfc1912.zones 5 Sep 2006 11:03:16 -0000       1.3
+++ named.rfc1912.zones 14 Jun 2007 10:10:01 -0000
@@ -30,7 +30,7 @@
        allow-update { none; };
 };
 
-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
+zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa"
IN {


This could be enough.

Adam

Created attachment 156981 [details]
Bug #243565 revised named config and zone files

Tarball containing revised named cache nameserver configuration plus test
script.

Supplied patch contains following:

1) New zone files for each of the three required behaviours.
named.localhost
named.loopback
named.empty
Existing zone files can be discarded.

2) Revised named.rfc1912.zones defining required namespaces using above elements.

3) Revised named.caching-nameserver.conf. Hints now part of base configuration.
This will allow rfc1912 zones to be abandoned if or when BIND named offers
similar behaviour auomatically.

4) Bourne shell script to demonstrate minimum required behaviour using dig.

Created attachment 156982 [details]
empty zone cleanup

Thanks for your template. I did more cleanup of "empty" zones. I remove zones
whose named (>= 9.4.0) declare implicitly as empty so we don't declare it
explicitly. Is it acceptable for you?

Adam

Adam,

Problem is that BIND does not do all of this properly at present.
What I sent you provides, IMHO, minimum acceptable behaviour, with no attempt
made to correct all the automatic empty zones listed in the log. I would argue
strongly for incorporating the patch verbatim. It has been well tested in that
form, so tinkering with it could risk introducing a bug. 

The best long-term solution would be for BIND named to provide same behaviour.
I fully expect that to happen eventually, at which point named.rfc1912.zones can
disappear entirely.

If you require convincing, compare (with patch in place)
dig @::1 127.in-addr.arpa. ANY
with
dig @::1 2.0.192.in-addr.arpa. ANY

Note the NS records and MNAME field of SOA records. Putting zone name on RHS of
NS record is a violation of RFC1034 which says it must resolve to an A record
(and by extension AAAA).

Apologies, it is RFC2181 section 7.3 which says unequivocally that zone name
must not appear in MNAME field of SOA record.

(In reply to comment #9)
> Adam,
> 
> Problem is that BIND does not do all of this properly at present.
> What I sent you provides, IMHO, minimum acceptable behaviour, with no attempt
> made to correct all the automatic empty zones listed in the log. I would argue
> strongly for incorporating the patch verbatim. It has been well tested in that
> form, so tinkering with it could risk introducing a bug.

I don't think that we could bring bug. Please see what I removed from
configfiles and try send queries to that zones to BIND >= 9.4 (FC-7). All
queries are replied as expected (from queried server, not root DNS). Of course
that you can't specify "empty-zones-enable no" option. I think if we're doing
config cleanup we could do it as much as it possible

-A-

Created attachment 157056 [details]
post cleanup agreed final text

Removing most of the empty zones is a good idea.

However, RFC3330 describes IPv4 loopback address as 127/8 rather than the
single address 127.0.0.1. There are also other inhabitants of this address
space, the 127.127/16 prefix is used by ntpd for example. The 127/8 empty space
has been reinstated, grouped with 127.0.0.1 so it is a little more obvious what
we are doing.

The only other issue concerns the IPv6 unspecified address. The desire for
consistency outweighs my minimalist instincts. Reverse lookups for ::0, ::1 and
0.0.0.0 should provide directly comparable results. Someone, somewhere, is
certain to file a bug report if they are not :-(

Tarball contains final version of complete patch. Revised named.rfc1912.zones,
all other files unmodified.

I still have some reservation about proposed solution. These zones named
implicitly declare as empty:

127.IN-ADDR.ARPA
254.169.IN-ADDR.ARPA
2.0.192.IN-ADDR.ARPA
255.255.255.255.IN-ADDR.ARPA
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
D.F.IP6.ARPA
8.E.F.IP6.ARPA
9.E.F.IP6.ARPA
A.E.F.IP6.ARPA
B.E.F.IP6.ARPA

So it's no argument why explicitly declare this zones as empty in
named.rfc1912.zones configfile. I'm going to remove these zones from
named.rfc1912.zones:

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
127.in-addr.arpa

-A-

Adam,

We have already agreed your proposal to delete 254.169.in-addr.arpa. and
255.255.255.255.in-addr.arpa. from the first draft of the patch. The other zones
listed at #13 have never been part of the proposal.

Your solution and mine now differ only with respect to 127.in-addr.arpa. and
0.0....ip6.arpa. These are the only areas left open for discussion.


Eventual solution needs to take full account of the following:

1) Loopback address space is specified in RFC3330 to be 127/8. Standards track
RFC, so nothing to argue about.

2) Reverse query of any part of 127/8 space should be consistent with reverse
query of the 127.0.0.1/32 subdomain.

Observe:
    dig @localhost. 1.0.0.127.in-addr.arpa. NS
gives:
    1.0.0.127.in-addr.arpa. 86400 IN NS localhost.     (as previously agreed)

but (BIND 9.4 automatic empty zone)
    dig @localhost. 127.in-addr.arpa. NS
gives
    127.in-addr.arpa. 0 IN NS 127.in-addr.arpa.

RHS of NS record must name an A record (or AAAA).
Clear violation of RFC1035(3.3.11) as clarified by RFC2181(10.3).
Standards track RFCs, BIND named behaviour is incorrect.

also
    dig @localhost. 2.0.0.127.in-addr.arpa. PTR
gives
    NXDOMAIN
    ;; AUTHORITY SECTION:
    127.in-addr.arpa. 86400 IN SOA 127.in-addr.arpa. . 0 28800 7200 604800 86400

Mistaken view of nameserver identity applies to SOA record as well. RFC2181(7.3)
explicity states that zone name must not appear in SOA MNAME field.

3) Reverse query of ::0 and ::1 should be consistent with each other.

    dig @localhost. 1.0. ...ip6.arpa. NS
gives
    1.0. ...ip6.arpa. 86400 IN NS localhost.           (as previously agreed)

whereas
    dig @localhost. 0.0. ...ip6.arpa. NS
gives
    0.0. ...ip6.arpa. 0 IN NS 0.0. ...ip6.arpa.

The standards arguments in 2) above also apply to this result.

None of the above behaviour is acceptable.

The supplied tarball dated 2007-06-14 20:48 EST addresses all the above issues
in a complete and consistent manner. I believe this to be a reasonable
engineering response to the problem at hand.

This represents my final position on this matter, and I fully intend to defend
it against arbitrary changes which destroy the essential character of the
solution.   Proposed deletions are such a change and therefore unacceptable.

There being no ground remaining to argue over, the patch should now be applied
verbatim or not at all.

(In reply to comment #14)
> 2) Reverse query of any part of 127/8 space should be consistent with reverse
> query of the 127.0.0.1/32 subdomain.

Could be quite hard in current BIND. It exists $GENERATE directive
(http://www.isc.org/sw/bind/arm94/Bv9ARM.ch06.html#id2591803) but it now only
support /24 addresses. I'm going to discuss in upstream how this could be solved.

> Observe:
>     dig @localhost. 1.0.0.127.in-addr.arpa. NS
> gives:
>     1.0.0.127.in-addr.arpa. 86400 IN NS localhost.     (as previously agreed)
> 
> but (BIND 9.4 automatic empty zone)
>     dig @localhost. 127.in-addr.arpa. NS
> gives
>     127.in-addr.arpa. 0 IN NS 127.in-addr.arpa.
>

Looks you're right. If I understand what you care about - instead
;; AUTHORITY SECTION:
127.in-addr.arpa.       86400   IN      SOA     127.in-addr.arpa. .
this record we could get
;; AUTHORITY SECTION:
127.in-addr.arpa.       86400   IN      SOA     localhost. .

> 
> 3) Reverse query of ::0 and ::1 should be consistent with each other.
Could you please point
I could remember that I've read somewhere that ::0 and ::1 could be same. But
I'm not sure what rfc specified this. Also looks that ping6 utility doesn't
honor this standard. Could you please point me which rfc cares about this one?

In the end I used your configuration written in comment #12. You could test
proposed update - http://people.redhat.com/atkac/bind/bind-9.4.1-5.1.fc7.src.rpm

Thanks much, Adam

I've pushed bind-9.4.1-6.fc7 into testing updates. Could you please verify all
works as expected?

A

Before making more comments please read and understand why empty zones are the
way they are.

http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt

bind-9.4.1-6.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

Thanks

I will install rpm and report back asap.

Dick

bind-9.4.1-6.fc7 rpm installs and works as expected.

However, that does not mean it is the right thing to do.

Internet draft cited by Mark Andrews effectively repeals RFC2181 para7.3 in
respect of local zones. This leaves my earlier argument holed below the waterline.

Propose to revise proposal removing 2 empty zones as suggested by Adam, then
recasting named.localhost and named.loopback as local zones in the style of MA's
dsnop draft.

Tarball follows

Created attachment 157474 [details]
tarball: revised  named.rfc1912.zones + zone files

(In reply to comment #20)

Yes, your tarball looks fine. I'm going to release it as final update. Thanks
for your cooperation on configuration bits

Regards, Adam

Adam,

Thanks for your help in pulling it all together.

Regards, Dick

bind-9.4.1-6.1.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.