Help again please Fwd: please fix your broken DNS server

[Joseph T. Klein]

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 at mpw.net>
> Date: July 8, 2005 10:27:28 AM CDT
> To: "Joseph T. Klein" <josephtklein at mac.com>
> Cc: Guyer Randolph <rguyer at milwaukee.gov>, Brousseau Dan 
> <dbrous at mpw.net>, Froh Gerard J <gfroh at mpw.net>, Craig Hapanovich 
> <CHAPAN at 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.
>
>