24 Oct
2012
24 Oct
'12
2:14 p.m.
from the mailing list archives i have learned that
dns_try_ipv6=yes
in config file is supposed to prevent dns query on ipv6 address.
if i have it "no", i get to syslog:
Oct 24 14:07:35 siika /usr/sbin/sip-proxy[17958]: INFO: Request URI is
<sip:+35832345679@[2002:c062:670a::10]:4050;transport=udp>
Oct 24 14:07:35 siika pdns[4269]: Received a malformed qdomain from 127.0.0.1,
'[2002:c062:670a::10]': sending servfail
Oct 24 14:07:35 siika pdns[4269]: Received a malformed qdomain from 127.0.0.1,
'[2002:c062:670a::10]': sending servfail
Oct 24 14:07:35 siika pdns[4269]: Received a malformed qdomain from 127.0.0.1,
'[2002:c062:670a::10]': sending servfail
Oct 24 14:07:35 siika /usr/sbin/sip-proxy[17958]: ERROR: tm [ut.h:314]: ERROR: uri2dst:
failed to resolve "[2002:c062:670a::10]" :unresolvable A or AAAA request (-7)
Oct 24 14:07:35 siika /usr/sbin/sip-proxy[17958]: ERROR: tm [t_fwd.c:1530]: ERROR:
t_forward_nonack: failure to add branches
and sip proxy naturally does not send anything out.
if i have it "yes", request is sent out properly, but still sip proxy
makes dns queries on the ipv6 address:
Oct 24 14:08:35 siika /usr/sbin/sip-proxy[18196]: INFO: Request URI is
<sip:+35832345679@[2002:c062:670a::10]:4050;transport=udp>
Oct 24 14:08:35 siika pdns[4269]: Received a malformed qdomain from 127.0.0.1,
'[2002:c062:670a::10]': sending servfail
Oct 24 14:08:35 siika pdns[4269]: Received a malformed qdomain from 127.0.0.1,
'[2002:c062:670a::10]': sending servfail
Oct 24 14:08:35 siika pdns[4269]: Received a malformed qdomain from 127.0.0.1,
'[2002:c062:670a::10]': sending servfail
why is that? how to completely prevent dns queries on ipv6 addresses?
-- juha
24 Oct
24 Oct
5:38 p.m.
another question on this:
Oct 24 14:08:35 siika /usr/sbin/sip-proxy[18196]:
INFO: Request URI is <sip:+35832345679@[2002:c062:670a::10]:4050;transport=udp>
Oct 24 14:08:35 siika pdns[4269]: Received a malformed qdomain from 127.0.0.1,
'[2002:c062:670a::10]': sending servfail
Oct 24 14:08:35 siika pdns[4269]: Received a malformed qdomain from 127.0.0.1,
'[2002:c062:670a::10]': sending servfail
Oct 24 14:08:35 siika pdns[4269]: Received a malformed qdomain from 127.0.0.1,
'[2002:c062:670a::10]': sending servfail
i have dns_retr_no=3, which sort of explains why three of those bad
queries are made. but only "sort of", because according to wireshark
each time dns server does respond to the query with error response.
shouldn't retry be done only if there is no response at all?
-- juha
9:28 p.m.
if i add this test in the beginning of resolve.c/get_record function,
the bogus dns queries on bracketed ipv6 addresses can be prevented:
if (name[0] == '[') {
return 0;
}
this is not the real fix, but helps until someone figures out why dns
query on something that is not a name but wrongly formatted ipv6 address
is done in the first place.
-- juha
9:41 p.m.
Richard Fuchs writes:
the ipv6 address that is passed to dns server is surrounded by brackets
[address], which i think is not a valid formatted dns name. even if you
leave the brackets out, the ipv6 address does not look like a domain
name to me.
perhaps i'm wrong and domain names now can nowadays contain [, ], and :
chars?
-- juha
this is not
the real fix, but helps until someone figures out why dns
query on something that is not a name but wrongly formatted ipv6 address
is done in the first place.
What do you mean with "wrongly formatted"? 
9:46 p.m.
On 10/24/12 14:41, Juha Heinanen wrote:
Richard Fuchs writes:
the ipv6 address that is passed to dns server is surrounded by brackets
[address], which i think is not a valid formatted dns name. even if you
leave the brackets out, the ipv6 address does not look like a domain
name to me.
IPv6 addresses are supposed to be bracketed when used within an URI.
Otherwise a parser wouldn't be able to tell if an optional port was
given or not. Compare http://2620:0:2d0:200::8/ vs
http://[2620:0:2d0:200::8]/ vs http://2620:0:2d0:200::8:80/ vs
http://[2620:0:2d0:200::8]:80/. See RFC 2732.
cheers
this is
not the real fix, but helps until someone figures out why dns
query on something that is not a name but wrongly formatted ipv6 address
is done in the first place.
What do you mean with "wrongly formatted"?
9:51 p.m.
Richard Fuchs writes:
IPv6 addresses are supposed to be bracketed when used
within an URI.
Otherwise a parser wouldn't be able to tell if an optional port was
given or not. Compare http://2620:0:2d0:200::8/ vs
http://[2620:0:2d0:200::8]/ vs http://2620:0:2d0:200::8:80/ vs
http://[2620:0:2d0:200::8]:80/. See RFC 2732.
sure, when ipv6 address appears in URI, the brackets are needed to
surround it, but give me a reference where dns request can contain such
a bracketed name.
-- juha
9:55 p.m.
On 10/24/12 14:51, Juha Heinanen wrote:
Richard Fuchs writes:
Obviously the DNS requests shouldn't happen in the first place. It's
already an address and doesn't need to be resolved. The DNS resolver
code seems to use str2ip6() everywhere, which does support the bracketed
notation, so I'm not sure where the problem could be.
cheers
IPv6 addresses are supposed to be bracketed when
used within an URI.
Otherwise a parser wouldn't be able to tell if an optional port was
given or not. Compare http://2620:0:2d0:200::8/ vs
http://[2620:0:2d0:200::8]/ vs http://2620:0:2d0:200::8:80/ vs
http://[2620:0:2d0:200::8]:80/. See RFC 2732.
sure, when ipv6 address appears in URI, the brackets are needed to
surround it, but give me a reference where dns request can contain such
a bracketed name. 
25 Oct
25 Oct
10:33 a.m.
On 10/24/12 9:02 PM, Juha Heinanen wrote:
Richard Fuchs writes:
Is the query type A or AAAA when
dns for ipv6 is disabled? I guess that
if the query for AAAA is disabled, the internal function that detects if
it is an IPv6 address is not executed. The one for ipv4 fails to match
it as a valid v4 address, so it thinks is a hostname.
The better fix looking at the patch you proposed would be to use the
function that detects is valid ipv6, not just something starting with '['.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
Obviously the DNS requests shouldn't happen
in the first place.
exactly, that has been my point all the time. the patch that i
proposed
is like aspirin until the real bug has been fixed.
5:12 p.m.
Daniel-Constantin Mierla writes:
The better fix looking at the patch you proposed would
be to use the
function that detects is valid ipv6, not just something starting with
'['.
this has nothing to with what is valid ipv6, but rather, how does a
valid domain name look like. domain name consists of labels separated
by dots and my understanding is that each label consists of letters,
decimal digits and - chars. it makes sense to make a dns query only on
such a valid domain name.
an ipv6 address can thus never be a valid domain name. an ipv4 address,
on the other hand, is syntactically valid domain name and perhaps
someone has populated their local name server with such names.
-- juha
5:24 p.m.
i would like to add and when hostpart of r-uri is ipv4 address,
wireshark tells me that kamailio does NOT try to resolve it from dns,
but when hostpart is [ipv6 address] then (as i have shown earlier),
kamailio tries to resolve it.
if it would be possible to make treatment of ipv6 hostpart the same as
ipv4 hostpart, no addition checks would be needed.
-- juha
5:33 p.m.
On Thursday 25 October 2012, Juha Heinanen wrote:
an ipv6 address can thus never be a valid domain name.
an ipv4 address,
on the other hand, is syntactically valid domain name and perhaps
someone has populated their local name server with such names.
But the application (kamailio) should not attempt a DNS lookup if the hostname
is an IP(v4/v6) address, from RFC1123, section 2.1:
========
Whenever a user inputs the identity of an Internet host, it SHOULD
be possible to enter either (1) a host domain name or (2) an IP
address in dotted-decimal ("#.#.#.#") form. The host SHOULD check
the string syntactically for a dotted-decimal number before
looking it up in the Domain Name System.
.
.
.
However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.
========
It would be nice if Kamailio refuses to lookup both IPv4 and IPv6 addresses
independent of the address family of listening sockets (see my emails about
dispatcher and IPv6, where DNS lookups on IPv6 addressed are only skipped if
Kamailio is listening on an IPv6 address).
--
Greetings,
Alex Hermann
5:51 p.m.
On 10/25/12 4:33 PM, Alex Hermann wrote:
On Thursday 25 October 2012, Juha Heinanen wrote:
It does not if it is ipv4 and
the target would be an A record, as well
as when it is ipv6 and the target would be an AAAA record.
The thing here relates to disabling ipv6, resulting in only possible
target A record, for which ipv6 does not match an ipv4 format, resulting
in using the ipv6 for querying an A record.
So some extra validation has to be added when one address family is
disabled by config, but such addresses can actually occur.
Perhaps what Juha suggested with detecting an invalid hostname is the
best, avoiding querying for broken dns tokens.
Cheers,
Daniel
an ipv6 address can thus never be a valid domain
name. an ipv4 address,
on the other hand, is syntactically valid domain name and perhaps
someone has populated their local name server with such names.
But the application
(kamailio) should not attempt a DNS lookup if the hostname
is an IP(v4/v6) address, from RFC1123, section 2.1:
========
Whenever a user inputs the identity of an Internet host, it SHOULD
be possible to enter either (1) a host domain name or (2) an IP
address in dotted-decimal ("#.#.#.#") form. The host SHOULD check
the string syntactically for a dotted-decimal number before
looking it up in the Domain Name System.
.
.
.
However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.
========
It would be nice if Kamailio refuses to lookup both IPv4 and IPv6 addresses
independent of the address family of listening sockets (see my emails about
dispatcher and IPv6, where DNS lookups on IPv6 addressed are only skipped if
Kamailio is listening on an IPv6 address).
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
6:11 p.m.
On Thursday 25 October 2012, Daniel-Constantin Mierla wrote:
On 10/25/12 4:33 PM, Alex Hermann wrote:
Agreed, but simply detecting ip addresses may also be sufficient.
Maybe do str2ip _and_ str2ip6 always, independent of the listening sockets.
Even if the proxy doesn't use ipv6, doing an A lookup on a literal IPv6 or
IPv6 refrence should be avoided.
(Currently str2ip6 is skipped if the proxy doesn't listen on an IPv6 address)
--
Met vriendelijke groet,
Alex Hermann
SpeakUp BV
T: 088-SPEAKUP (088-7732587)
F: 088-7732588
On Thursday 25 October 2012, Juha Heinanen
wrote:
an ipv6 address can thus never be a valid domain
name. an ipv4 address,
on the other hand, is syntactically valid domain name and perhaps
someone has populated their local name server with such names.
But the application (kamailio) should not attempt a DNS lookup if the
hostname is an IP(v4/v6) address, from RFC1123, section
2.1:
It does not if it is ipv4 and the target would be an A record, as well
as when it is ipv6 and the target would be an AAAA record.
The thing here relates to disabling ipv6, resulting in only possible
target A record, for which ipv6 does not match an ipv4 format, resulting
in using the ipv6 for querying an A record.
So some extra validation has to be added when one address family is
disabled by config, but such addresses can actually occur.
Perhaps what Juha suggested with detecting an invalid hostname is the
best, avoiding querying for broken dns tokens. 
5:57 p.m.
On 10/25/2012 05:33 PM, Alex Hermann wrote:
On Thursday 25 October 2012, Juha Heinanen wrote:
Hello,
Didn't had time to check the RFCs (RFC 1123 is from 1989 so it might be
updated), but from what I know the rule of the thumb (and inet_pton(3)
is useful describing several cases where a string is considered an ip
address):
- if a string can represent a 32-bit number (ipv4), or a 128 bit number
(ipv6) than it represents and IP address of respective family (ping
0xdeadbeef in console to see that 0xdeadbeef is a correct ip address).
-quad doted formats (decimal, octal or hexa) are allowed for IPv4
(010.010.010.010 is actually 8.8.8.8)
-IPv6 addresses have several forms, eight groups or less, or the hybrid
notation (e.g. ::FFFF:192.168.0.2)
inet_pton(3), inet_aton(3), inet_addr(3) only handle part of these
types, the new resolver API getaddrinfo(3) handles all + a and quad-a
DNS request.
I think we should handle all as well...
Cheers,
Marius
an ipv6 address can thus never be a valid domain
name. an ipv4 address,
on the other hand, is syntactically valid domain name and perhaps
someone has populated their local name server with such names.
But the application
(kamailio) should not attempt a DNS lookup if the hostname
is an IP(v4/v6) address, from RFC1123, section 2.1:
========
Whenever a user inputs the identity of an Internet host, it SHOULD
be possible to enter either (1) a host domain name or (2) an IP
address in dotted-decimal ("#.#.#.#") form. The host SHOULD check
the string syntactically for a dotted-decimal number before
looking it up in the Domain Name System.
.
. .
However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.
========
It would be nice if Kamailio refuses to lookup both IPv4 and IPv6 addresses
independent of the address family of listening sockets (see my emails about
dispatcher and IPv6, where DNS lookups on IPv6 addressed are only skipped if
Kamailio is listening on an IPv6 address).
--
Zbihlei Marius
Head of
Linux Development Services Romania
1&1 Internet Development srl Tel KA: 754-9152
Str Mircea Eliade 18 Tel RO: +40-31-223-9152
Sect 1, Bucuresti mailto: marius.zbihlei(a)1and1.ro
71295, Romania
4:57 p.m.
On 24.10.2012 20:41, Juha Heinanen wrote:
Richard Fuchs writes:
the ipv6 address that is passed to dns server is surrounded by brackets
[address], which i think is not a valid formatted dns name. even if you
leave the brackets out, the ipv6 address does not look like a domain
name to me.
perhaps i'm wrong and domain names now can nowadays contain [, ], and :
chars?
I think they are generally allowed, but not for hostnames (e.g. A and
AAAA lookups)
klaus
this is
not the real fix, but helps until someone figures out why dns
query on something that is not a name but wrongly formatted ipv6 address
is done in the first place.
What do you mean with "wrongly formatted"?
4414
days inactive
4415
days old
16 comments
6 participants
participants (6)
-
Alex Hermann -
Daniel-Constantin Mierla -
Juha Heinanen -
Klaus Darilion -
Marius Zbihlei -
Richard Fuchs