More help please.
Ken is now claiming other servers are broken, not his. He wants all
bind users to use allow-v6-synthesis to resolve the problem. So all
other DNS servers are broken, not his.
I am at a loss as to what to do and they throw the FUD back at the
political leadership.
Why the direct dig work and the indirect resolution not?
Ideas?
--
Joseph T. Klein
PSTN: +1 414 961 1690 VoIP: +1 414 431 4231 Mobile: +1 414 628 3380
Begin forwarded message:
> From: Ken Walker <kwalke@mpw.net>
> Date: July 8, 2005 10:27:28 AM CDT
> To: "Joseph T. Klein" <josephtklein@mac.com>
> Cc: Guyer Randolph <rguyer@milwaukee.gov>, Brousseau Dan
> <dbrous@mpw.net>, Froh Gerard J <gfroh@mpw.net>, Craig Hapanovich
> <CHAPAN@milwaukee.gov>
> Subject: Re: please fix your broken DNS server
>
> Joe,
> You missed the point of what I was trying to tell you. MY dns
> servers DO
> respond with the proper response. (Please see dig result below). What
> I was
> trying to offer was a possible reason why other sites are having
> trouble.
>
> I never said it was an AAAA v A6 problem. If you read the whole
> section on
> synthectic response, (see below) It also states it will try a lookup
> using A6
> records, if that fails then AAAA. The allow-v6-synthesis ALSO allows a
> server
> to return a correctly formated response when there are NO AAAA records
> to be
> found for a host. Your testing is flawed in the fact that there are
> either
> CNAME or AAAA records you are querying uwm for, in otherwords SOME
> sort of
> response, but not an unknown one. That's where this paramter would
> help a BIND
> server anyway. I can't help you fix other servers that do not belong
> to DPW.
> Mine work correctly.
>
> The security of our data and our network is of paramount
> importance to us
> and I WILL NOT discuss intiment details with anyone that is not a
> trusted city
> employee. There are over 500,000 people in milwaukee and they all have
> needs
> I have many many many concerns to deal with during the day and it
> is not
> fair for 1 person to monopolize my time for something that isn't our
> problem.
>
> I will not respond further to any future letters you write about
> this
> subject.
>
> Ken
>
> dig @charon.mpw.net AAAA gwise.ci.mil.wi.us
>
> ; <<>> DiG 9.2.3 <<>> @charon.mpw.net AAAA gwise.ci.mil.wi.us
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46769
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;gwise.ci.mil.wi.us. IN AAAA
>
> ;; Query time: 13 msec
> ;; SERVER: 216.54.131.130#53(charon.mpw.net)
> ;; WHEN: Fri Jul 8 10:10:29 2005
> ;; MSG SIZE rcvd: 36
>
> 6.2.14.13. Synthetic IPv6 responses
>
> Many existing stub resolvers support IPv6 DNS lookups as defined in
> RFC1886,
> using AAAA records for forward lookups and "nibble labels" in the
> IP6.INT
> domain for reverse lookups, but do not support RFC2874-style lookups
> (using A6
> records and binary labels in the IP6.ARPA domain).
>
> For those who wish to continue to use such stub resolvers rather than
> switching
> to the BIND 9 lightweight resolver, BIND 9 provides a way to
> automatically
> convert RFC1886-style lookups into RFC2874-style lookups and return
> the results
> as "synthetic" AAAA and PTR records.
>
> This feature is disabled by default and can be enabled on a per-client
> basis by
> adding a allow-v6-synthesis { address_match_list }; clause to the
> options or
> view statement. When it is enabled, recursive AAAA queries cause the
> server to
> first try an A6 lookup and if that fails, an AAAA lookups. No matter
> which one
> succeeds, the results are returned as a set of synthetic AAAA records.
> Similarly, recursive PTR queries in IP6.INT will cause a lookup in
> IP6.ARPA
> using binary labels, and if that fails, another lookup in IP6.INT. The
> results
> are returned as a synthetic PTR record in ip6.int.
>
>
Ken is now claiming other servers are broken, not his. He wants all
bind users to use allow-v6-synthesis to resolve the problem. So all
other DNS servers are broken, not his.
I am at a loss as to what to do and they throw the FUD back at the
political leadership.
Why the direct dig work and the indirect resolution not?
Ideas?
--
Joseph T. Klein
PSTN: +1 414 961 1690 VoIP: +1 414 431 4231 Mobile: +1 414 628 3380
Begin forwarded message:
> From: Ken Walker <kwalke@mpw.net>
> Date: July 8, 2005 10:27:28 AM CDT
> To: "Joseph T. Klein" <josephtklein@mac.com>
> Cc: Guyer Randolph <rguyer@milwaukee.gov>, Brousseau Dan
> <dbrous@mpw.net>, Froh Gerard J <gfroh@mpw.net>, Craig Hapanovich
> <CHAPAN@milwaukee.gov>
> Subject: Re: please fix your broken DNS server
>
> Joe,
> You missed the point of what I was trying to tell you. MY dns
> servers DO
> respond with the proper response. (Please see dig result below). What
> I was
> trying to offer was a possible reason why other sites are having
> trouble.
>
> I never said it was an AAAA v A6 problem. If you read the whole
> section on
> synthectic response, (see below) It also states it will try a lookup
> using A6
> records, if that fails then AAAA. The allow-v6-synthesis ALSO allows a
> server
> to return a correctly formated response when there are NO AAAA records
> to be
> found for a host. Your testing is flawed in the fact that there are
> either
> CNAME or AAAA records you are querying uwm for, in otherwords SOME
> sort of
> response, but not an unknown one. That's where this paramter would
> help a BIND
> server anyway. I can't help you fix other servers that do not belong
> to DPW.
> Mine work correctly.
>
> The security of our data and our network is of paramount
> importance to us
> and I WILL NOT discuss intiment details with anyone that is not a
> trusted city
> employee. There are over 500,000 people in milwaukee and they all have
> needs
> I have many many many concerns to deal with during the day and it
> is not
> fair for 1 person to monopolize my time for something that isn't our
> problem.
>
> I will not respond further to any future letters you write about
> this
> subject.
>
> Ken
>
> dig @charon.mpw.net AAAA gwise.ci.mil.wi.us
>
> ; <<>> DiG 9.2.3 <<>> @charon.mpw.net AAAA gwise.ci.mil.wi.us
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46769
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;gwise.ci.mil.wi.us. IN AAAA
>
> ;; Query time: 13 msec
> ;; SERVER: 216.54.131.130#53(charon.mpw.net)
> ;; WHEN: Fri Jul 8 10:10:29 2005
> ;; MSG SIZE rcvd: 36
>
> 6.2.14.13. Synthetic IPv6 responses
>
> Many existing stub resolvers support IPv6 DNS lookups as defined in
> RFC1886,
> using AAAA records for forward lookups and "nibble labels" in the
> IP6.INT
> domain for reverse lookups, but do not support RFC2874-style lookups
> (using A6
> records and binary labels in the IP6.ARPA domain).
>
> For those who wish to continue to use such stub resolvers rather than
> switching
> to the BIND 9 lightweight resolver, BIND 9 provides a way to
> automatically
> convert RFC1886-style lookups into RFC2874-style lookups and return
> the results
> as "synthetic" AAAA and PTR records.
>
> This feature is disabled by default and can be enabled on a per-client
> basis by
> adding a allow-v6-synthesis { address_match_list }; clause to the
> options or
> view statement. When it is enabled, recursive AAAA queries cause the
> server to
> first try an A6 lookup and if that fails, an AAAA lookups. No matter
> which one
> succeeds, the results are returned as a set of synthetic AAAA records.
> Similarly, recursive PTR queries in IP6.INT will cause a lookup in
> IP6.ARPA
> using binary labels, and if that fails, another lookup in IP6.INT. The
> results
> are returned as a synthetic PTR record in ip6.int.
>
>