Bug 128111 - dig, host do ipv6 nibble lookup by default
dig, host do ipv6 nibble lookup by default
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
rawhide
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-18 05:28 EDT by Ivan Gyurdiev
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-02 20:42:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ivan Gyurdiev 2004-07-18 05:28:46 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040706 Firefox/0.9.1

Description of problem:
Host and dig both do nibble lookups by default.
Why is that? I thought the nibble format was deprecated and going
away. The documentation in the man pages says dig and host are
supposed to do bitstring lookups by default.


[root@cobra phantom]# host -t PTR
\\[x00000000000000000000000000000001/128].ip6.arpa. localhost -n
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:
 
\[x00000000000000000000000000000001/128].ip6.arpa domain name pointer
localhost.

Here it does a bitstring lookup because I explictly typed out the
bitstring. That's good, right - it's supposed to do bitstring lookups
by default...but note it ignored the -n nibble option, which is bad.

[root@cobra phantom]# host -t PTR ::1 localhost
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:
 
Host
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
not found: 3(NXDOMAIN)

And here I used a regular IPV6 address and it did a nibble lookup.
Even though it's supposed to do bitstring by default. Using the -n
option has no effect. Dig does the same thing. 

Btw I see this everywhere:

v6 synthesis denied

I tried an option called allow-v6-synthesis documented online, but
this version of bind doesn't support it. Perhaps this is relevant.



Version-Release number of selected component (if applicable):
bind-utils-9.2.3-18

How reproducible:
Always

Steps to Reproduce:
1. See Summary
    

Additional info:
Comment 1 Jason Vas Dias 2004-07-27 14:01:34 EDT
 I cannot duplicate this problem with bind-9.2.4rc6 
 (the latest version).

 Perhaps the problem is in configuration - if the reporter would
 please attach the /etc/named.conf and zone files, I can investigate 
 further and will reopen. 
Comment 2 Ivan Gyurdiev 2004-08-02 02:03:25 EDT
Ok,

Here's a zone file:

$TTL 3D
@ IN      SOA     localhost. ivg2.cornell.edu. (
                                200308081       ; Serial
                                8H      ; Refresh
                                2H      ; Retry
                                4W      ; Expire
                                1D)     ; Minimum TTL
                                                        NS      localhost.
$ORIGIN \[x0000000000000000/64].ip6.arpa.
\[x0000000000000001/64]                               PTR     localhost.
                                                                     
                                                       
$ORIGIN 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                               PTR    
localhost.

This is a localhost IPv6 reverse zone file, with both bitstring and
nibble style PTRs in it. 

This is the config for it:

zone "\[x0000000000000000/64].ip6.arpa." {
        type master;
        file "zones/localhost6-reverse";
};
                                                                     
                                                       
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." {
      type master;
      file "zones/localhost6-reverse";
};
====================

When both entries are active I get this:

[root@cobra backend]# dig @localhost PTR -x ::1
 
; <<>> DiG 9.2.4rc6 <<>> @localhost PTR -x ::1
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37830
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
 
;; QUESTION SECTION:
;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 PTR
 
;; ANSWER SECTION:
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.
259200 IN PTR localhost.
 
;; AUTHORITY SECTION:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 259200 IN NS  localhost.
 
;; Query time: 113 msec
;; SERVER: 127.0.0.1#53(localhost)
;; WHEN: Sun Aug  1 23:49:38 2004
;; MSG SIZE  rcvd: 127

When the second entry is commented out I get this:

[root@cobra backend]# dig @localhost PTR -x ::1
 
; <<>> DiG 9.2.4rc6 <<>> @localhost PTR -x ::1
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13524
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
 
;; QUESTION SECTION:
;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 PTR
 
;; AUTHORITY SECTION:
ip6.arpa.               3392    IN      SOA     dns1.icann.org.
hostmaster.icann.org. 2004071900 3600 1800 604800 10800
 
;; Query time: 471 msec
;; SERVER: 127.0.0.1#53(localhost)
;; WHEN: Sun Aug  1 23:50:08 2004
;; MSG SIZE  rcvd: 151

Clearly the zone does not match in case 2. Why? 

This looks like a nibble-formatted address to me, even though
it looks in ip6.arpa and not ip6.int

;; QUESTION SECTION:
;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 PTR

Aug 01 23:50:07.851 createfetch:
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
PTR

Am I missing something?

As you can see the zone syntax is correct  :

[root@cobra ~]# named-checkzone "\[x0000000000000000/64].ip6.arpa."
/var/named/chroot/var/named/zones/localhost6-reverse
dns_master_load:
/var/named/chroot/var/named/zones/localhost6-reverse:13: ignoring
out-of-zone data
(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)
zone \[x0000000000000000/64].ip6.arpa/IN: loaded serial 200308081
OK
[root@cobra ~]# named-checkzone
"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa."
/var/named/chroot/var/named/zones/localhost6-reverse
dns_master_load:
/var/named/chroot/var/named/zones/localhost6-reverse:10: ignoring
out-of-zone data (\[x00000000000000000000000000000001/128].ip6.arpa)
zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 200308081
OK
[root@cobra ~]#











Comment 3 Jason Vas Dias 2004-08-02 20:42:14 EDT
It appears that it is the "Bit Label" format that is going away -
the following is a quote from the BIND Administrators Reference:
(file:/usr/share/doc/bind-9.2.4rc6/arm/Bv9ARM.ch04.html#AEN989):
"
For forward lookups, BIND 9 supports both A6 and AAAA records. The use
of A6 records has been moved to experimental (RFC 3363) and should be
treated as deprecated.

The use of "bitstring" labels for IPv6 has been moved to experimental
(RFC 3363) reverting to a nibble format. The suffix for the IPv6
reverse lookups has also changed from IP6.INT to IP6.ARPA (RFC 3152).

BIND 9 now defaults to nibble IP6.ARPA format lookups.
"

This issue is not due to a bug in Red Hat's distribution of BIND 9 -
if you don't like this behaviour, I suggest you direct your query
to the 'bind-users@isc.org' mailing list.
Comment 4 Ivan Gyurdiev 2004-08-02 22:31:11 EDT
> This issue is not due to a bug in Red Hat's distribution of BIND 9 -
> if you don't like this behaviour, I suggest you direct your query
> to the 'bind-users@isc.org' mailing list.

I have no opinion of any kind regarding this behavior.
I am trying to re-write system-config-bind, and in order to do 
that I have to understand perfectly what is going on in the bind
configuration. Thanks for pointing this out - I had read something
different elsewhere. May I suggest that the host and dig manpages be
updated to reflect this behavior, since they create confusion?

  

Note You need to log in before you can comment on or make changes to this bug.