Mailing List Archive

Misbehavior Against DNS Queries for IPv6 Addresses?
I would like a third party reality check on my conclusions regarding
the following logged error.

Up front questions:
- Possible sendmail work around?
- Other people could try and educate the city?
(the CIO is rgschw@milwaukee.gov)

Before I start making a fuss I would like third party verification
that it is a City problem.

I am also interested in what systems and conditions produce the bad
AAAA record reply.

Situation: I turned on IPv6 for sendmail and my correspondence with
my local city ended up generating the following log entries.

Jun 4 02:25:39 monet named[92610]: FORMERR resolving
'gwise.ci.mil.wi.us/AAAA/IN': 216.56.88.2#53
Jun 4 02:25:39 monet named[92610]: FORMERR resolving
'gwise.ci.mil.wi.us/AAAA/IN': 216.54.131.251#53
Jun 4 02:25:42 monet named[92610]: FORMERR resolving
'gwise.ci.mil.wi.us/AAAA/IN': 216.56.88.2#53
Jun 4 02:25:42 monet named[92610]: FORMERR resolving
'gwise.ci.mil.wi.us/AAAA/IN': 216.54.131.251#53
Jun 4 02:25:42 monet named[92610]: FORMERR resolving
'gwise.ci.mil.wi.us/AAAA/IN': 216.56.88.2#53
Jun 4 02:25:42 monet named[92610]: FORMERR resolving
'gwise.ci.mil.wi.us/AAAA/IN': 216.54.131.251#53
Jun 4 02:25:43 monet named[92610]: FORMERR resolving
'mhsgate.ci.mil.wi.us/AAAA/IN': 216.54.131.251#53
Jun 4 02:25:43 monet named[92610]: FORMERR resolving
'mhsgate.ci.mil.wi.us/AAAA/IN': 216.56.88.2#53
Jun 4 02:25:46 monet named[92610]: FORMERR resolving
'mhsgate.ci.mil.wi.us/AAAA/IN': 216.56.88.2#53
Jun 4 02:25:46 monet named[92610]: FORMERR resolving
'mhsgate.ci.mil.wi.us/AAAA/IN': 216.54.131.251#53
Jun 4 02:25:46 monet named[92610]: FORMERR resolving
'mhsgate.ci.mil.wi.us/AAAA/IN': 216.56.88.2#53
Jun 4 02:25:46 monet named[92610]: FORMERR resolving
'mhsgate.ci.mil.wi.us/AAAA/IN': 216.54.131.251#53

After some reading I concluded this was the problem discussed
in RFC 4074

A dig on the listed MX primary for milwaukee.gov (The City of Milwaukee)

monet# dig AAAA mhsgate.ci.mil.wi.us

; <<>> DiG 9.3.1 <<>> AAAA mhsgate.ci.mil.wi.us
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28136
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mhsgate.ci.mil.wi.us. IN AAAA

;; Query time: 70 msec
;; SERVER: 192.133.102.1#53(192.133.102.1)
;; WHEN: Sat Jun 4 05:12:13 2005
;; MSG SIZE rcvd: 38

Note how the header opcode returns status: SERVFAIL rather than
status: NOERROR. This is the same broken behavior as described
in RFC-4074.

Thank you for your help.
--
Joseph T. Klein

PSTN: +1 414 961 1690 VoIP: +1 414 431 4231 Mobile: +1 414 628 3380
Misbehavior Against DNS Queries for IPv6 Addresses? [ In reply to ]
On Thu, 2005-06-09 at 09:56 -0500, Joseph T. Klein wrote:
> I would like a third party reality check on my conclusions regarding
> the following logged error.
>
> Up front questions:
> - Possible sendmail work around?
> - Other people could try and educate the city?
> (the CIO is rgschw@milwaukee.gov)

$ dig +short milwaukee.gov soa
itmddns1.milwaukee.gov. chapan.milwaukee.gov. 64 7200 7200 604800 86400

Try chapan@milwaukee.gov that should work.

> Jun 4 02:25:39 monet named[92610]: FORMERR resolving
> 'gwise.ci.mil.wi.us/AAAA/IN': 216.56.88.2#53

$ dig +short @itmddns1x.milwaukee.gov milwaukee.gov ns
itmddns4x.milwaukee.gov.
itmddns1x.milwaukee.gov.
itmddns2x.milwaukee.gov.
itmddns3x.milwaukee.gov.

$ dig +short @itmddns1x.milwaukee.gov version.bind. ch txt
"9.3.1"
$ dig +short @itmddns2x.milwaukee.gov version.bind. ch txt
;; reply from unexpected source: 216.54.131.209#53, expected
216.56.88.112#53
$ dig +short @itmddns3x.milwaukee.gov version.bind. ch txt
"9.3.1"
$ dig +short @itmddns4x.milwaukee.gov version.bind. ch txt
;; reply from unexpected source: 216.54.131.210#53, expected
216.56.88.113#53

$ dig +short milwaukee.gov mx
10 gwise.milwaukee.gov.
20 mhsgate.ci.mil.wi.us.

Oh great, 0 TTL's:
mhsgate.ci.mil.wi.us. 0 IN A 216.54.131.208
mhsgate.ci.mil.wi.us. 0 IN A 216.56.88.111

and of course a MX pointing to a CNAME:

gwise.milwaukee.gov. 60 IN CNAME gwise.ci.mil.wi.us.
gwise.ci.mil.wi.us. 0 IN A 216.54.131.198
gwise.ci.mil.wi.us. 0 IN A 216.56.88.101

But those are almost the same boxes anyway.

My short conclusion 2x + 4x are broken. The claim to be 9.3.1 which
should handle IPv6. But I also recall 9.3.x doing weird things when
trying to serve AAAA records, but it suddenly vanished again.

The 'ddns' part in the hostname might indicate dynamic dns...

Greets,
Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050609/f9d0879e/attachment.bin
Misbehavior Against DNS Queries for IPv6 Addresses? [ In reply to ]
well AAAA are for ipv6 address. I run a prodcution ipv6 tunnel with bgp
on my server via occaid and i never had the problem.


resluts are below for wolfnix.net A if ipv4 and AAAA is ipv6


Josh

root@krypto [~]# dig A wolfnix.net

; <<>> DiG 9.3.1 <<>> A wolfnix.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24310
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4

;; QUESTION SECTION:
;wolfnix.net. IN A

;; ANSWER SECTION:
wolfnix.net. 3600 IN A 65.23.157.73

;; AUTHORITY SECTION:
wolfnix.net. 3600 IN NS ns0.wolfnix.net.
wolfnix.net. 3600 IN NS ns1.wolfnix.net.

;; ADDITIONAL SECTION:
ns0.wolfnix.net. 3600 IN A 65.23.157.73
ns0.wolfnix.net. 3600 IN AAAA 2001:4830:2380::2
ns1.wolfnix.net. 3600 IN A 65.23.157.73
ns1.wolfnix.net. 3600 IN AAAA 2001:4830:2380::2

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jun 9 22:58:16 2005
;; MSG SIZE rcvd: 169

root@krypto [~]# dig AAAA wolfnix.net

; <<>> DiG 9.3.1 <<>> AAAA wolfnix.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38077
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4

;; QUESTION SECTION:
;wolfnix.net. IN AAAA

;; ANSWER SECTION:
wolfnix.net. 3600 IN AAAA 2001:4830:2380::2

;; AUTHORITY SECTION:
wolfnix.net. 3600 IN NS ns1.wolfnix.net.
wolfnix.net. 3600 IN NS ns0.wolfnix.net.

;; ADDITIONAL SECTION:
ns0.wolfnix.net. 3600 IN A 65.23.157.73
ns0.wolfnix.net. 3600 IN AAAA 2001:4830:2380::2
ns1.wolfnix.net. 3600 IN A 65.23.157.73
ns1.wolfnix.net. 3600 IN AAAA 2001:4830:2380::2

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jun 9 22:58:21 2005
;; MSG SIZE rcvd: 181

root@krypto [~]#
Misbehavior Against DNS Queries for IPv6 Addresses? [ In reply to ]
The problem is that if you run sendmail with IPv6 enabled it gets
a DNS error due to DNS problems on the site that you are trying to
send mail to, then sendmail endlessly defers the mail.

This is because sendmail looks for a AAAA record before an A record.
The DNS at the receiving site sends a broken response.

Please - anyone have a fix other than turning off IPv6 on my sendmail,
which, as far as I can tell, is not the source of the problem.

Read RFC 4074 - I think the problem is explained in that RFC.

Note my example ...

; <<>> DiG 9.3.1 <<>> AAAA mhsgate.ci.mil.wi.us
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28136
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mhsgate.ci.mil.wi.us. IN AAAA

;; Query time: 70 msec
;; SERVER: 192.133.102.1#53(192.133.102.1)
;; WHEN: Sat Jun 4 05:12:13 2005
;; MSG SIZE rcvd: 38

Note how the header opcode returns status: SERVFAIL rather than
status: NOERROR. This is the same broken behavior as described
in RFC-4074.


--
Joseph T. Klein

PSTN: +1 414 961 1690 VoIP: +1 414 431 4231 Mobile: +1 414 628 3380

On Jun 9, 2005, at 9:58 PM, Joshua Ronne Altemoos wrote:

> well AAAA are for ipv6 address. I run a prodcution ipv6 tunnel with
> bgp on my server via occaid and i never had the problem.
>
>
> resluts are below for wolfnix.net A if ipv4 and AAAA is ipv6
>
>
> Josh
>
> root@krypto [~]# dig A wolfnix.net
>
> ; <<>> DiG 9.3.1 <<>> A wolfnix.net
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24310
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4
>
> ;; QUESTION SECTION:
> ;wolfnix.net. IN A
>
> ;; ANSWER SECTION:
> wolfnix.net. 3600 IN A 65.23.157.73
>
> ;; AUTHORITY SECTION:
> wolfnix.net. 3600 IN NS ns0.wolfnix.net.
> wolfnix.net. 3600 IN NS ns1.wolfnix.net.
>
> ;; ADDITIONAL SECTION:
> ns0.wolfnix.net. 3600 IN A 65.23.157.73
> ns0.wolfnix.net. 3600 IN AAAA 2001:4830:2380::2
> ns1.wolfnix.net. 3600 IN A 65.23.157.73
> ns1.wolfnix.net. 3600 IN AAAA 2001:4830:2380::2
>
> ;; Query time: 2 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu Jun 9 22:58:16 2005
> ;; MSG SIZE rcvd: 169
>
> root@krypto [~]# dig AAAA wolfnix.net
>
> ; <<>> DiG 9.3.1 <<>> AAAA wolfnix.net
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38077
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4
>
> ;; QUESTION SECTION:
> ;wolfnix.net. IN AAAA
>
> ;; ANSWER SECTION:
> wolfnix.net. 3600 IN AAAA 2001:4830:2380::2
>
> ;; AUTHORITY SECTION:
> wolfnix.net. 3600 IN NS ns1.wolfnix.net.
> wolfnix.net. 3600 IN NS ns0.wolfnix.net.
>
> ;; ADDITIONAL SECTION:
> ns0.wolfnix.net. 3600 IN A 65.23.157.73
> ns0.wolfnix.net. 3600 IN AAAA 2001:4830:2380::2
> ns1.wolfnix.net. 3600 IN A 65.23.157.73
> ns1.wolfnix.net. 3600 IN AAAA 2001:4830:2380::2
>
> ;; Query time: 1 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu Jun 9 22:58:21 2005
> ;; MSG SIZE rcvd: 181
>
> root@krypto [~]#
>
Misbehavior Against DNS Queries for IPv6 Addresses? [ In reply to ]
> On Jun 9, 2005, at 9:58 PM, Joshua Ronne Altemoos wrote:
>
> > well AAAA are for ipv6 address. I run a prodcution ipv6 tunnel with
> > bgp on my server via occaid and i never had the problem.

Please, you should assume that most people on this list know the
difference between A and AAAA, next to that most people here run
production IPv6 networks and some of them did encounter this problem, eg
with the bbc nameservers, which got fixed, and quite a number of others.

On Fri, 2005-06-10 at 02:41 -0500, Joseph T. Klein wrote:
> The problem is that if you run sendmail with IPv6 enabled it gets
> a DNS error due to DNS problems on the site that you are trying to
> send mail to, then sendmail endlessly defers the mail.
>
> This is because sendmail looks for a AAAA record before an A record.
> The DNS at the receiving site sends a broken response.
>
> Please - anyone have a fix other than turning off IPv6 on my sendmail,
> which, as far as I can tell, is not the source of the problem.
>
> Read RFC 4074 - I think the problem is explained in that RFC.

The thing here is though, that bind 9.3.1 should not be affected to
this, and as I showed with the version.bind chaos queries they are
running this version.

<SNIP>
> Note how the header opcode returns status: SERVFAIL rather than
> status: NOERROR. This is the same broken behavior as described
> in RFC-4074.

That is correct. But really, the only way you are going to get this
fixed is have them check and maybe upgrade their DNS servers.

Greets,
Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050610/d761eab0/attachment.bin
Misbehavior Against DNS Queries for IPv6 Addresses? [ In reply to ]
> -----Original Message-----
> From: Postmaster@milwaukee.gov [mailto:Postmaster@milwaukee.gov] On Behalf
> Of Craig Hapanovich
> Sent: 10. juni 2005 10:19
> To: jorgen@hovland.cx
> Subject: Re: FYI: Misbehavior Against DNS Queries for IPv6 Addresses
>
> I am on vacation until June 13.
Misbehavior Against DNS Queries for IPv6 Addresses? [ In reply to ]
On Fri, Jun 10, 2005 at 10:26:12AM +0200, J?rgen Hovland wrote:
> > -----Original Message-----
> > From: Postmaster@milwaukee.gov [mailto:Postmaster@milwaukee.gov] On Behalf
> > Of Craig Hapanovich
> > Sent: 10. juni 2005 10:19
> > To: jorgen@hovland.cx
> > Subject: Re: FYI: Misbehavior Against DNS Queries for IPv6 Addresses
> >
> > I am on vacation until June 13.

I'll take care of that. Won't be easy as I cannot find his subscription
address. Seems that it is some kind of forwarding.


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Misbehavior Against DNS Queries for IPv6 Addresses? [ In reply to ]
On Fri, 2005-06-10 at 10:39 +0200, Daniel Roesen wrote:
> On Fri, Jun 10, 2005 at 10:26:12AM +0200, J?rgen Hovland wrote:
> > > -----Original Message-----
> > > From: Postmaster@milwaukee.gov [mailto:Postmaster@milwaukee.gov] On Behalf
> > > Of Craig Hapanovich
> > > Sent: 10. juni 2005 10:19
> > > To: jorgen@hovland.cx
> > > Subject: Re: FYI: Misbehavior Against DNS Queries for IPv6 Addresses
> > >
> > > I am on vacation until June 13.
>
> I'll take care of that. Won't be easy as I cannot find his subscription
> address. Seems that it is some kind of forwarding.

*psst* that is the address of the pstmaster@ of the domain that has the
problem. Thus he is not on this list, but Jorgen (+slash through the
o ;) just mentions that this guy is on vacation thus that it might take
a couple of days till he will reply ;)

/me shares the large canister of coffee, jolt and tea for the others ;)

Greets,
Jeron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050610/12bc0344/attachment.bin
Misbehavior Against DNS Queries for IPv6 Addresses? [ In reply to ]
On Fri, Jun 10, 2005 at 02:41:23AM -0500, Joseph T. Klein wrote:
> This is because sendmail looks for a AAAA record before an A record.
> The DNS at the receiving site sends a broken response.

Do you already have something like:

define(`confBIND_OPTS',`WorkAroundBrokenAAAA')dnl

in your sendmail config? It is supposed to help with problems like
this. You should definitely complain to the zone maintainer though.

I've a script that is supposed to diagnose these problems:

http://www.cnri.dit.ie/cgi-bin/check_aaaa.pl

Unfortunately, it doesn't catch this one, because the problem occurs
further up the DNS tree than the script expects. It seems that the
servers for milwaukee.gov:

itmddns1x.milwaukee.gov
itmddns2x.milwaukee.gov
itmddns3x.milwaukee.gov
itmddns4x.milwaukee.gov

will only answer queries for records of type A and CNAME for
gwise.milwaukee.gov (they won't answer queries for MX, TXT, AAAA,
NS, ...). They don't have the same problem with www.milwaukee.gov,
which indicates that there is some weird internal problem.

As Jeroen points out, all these servers claim to be 9.3.1, which
shouldn't have any problems like this. Fpdns also thinks that they
are a recent version of bind. I'd guess that they are forwarding
the query to some other server, which is screwing things up.

David.