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
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
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
Richard Fuchs writes:
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"?
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
On 10/24/12 14:41, Juha Heinanen wrote:
Richard Fuchs writes:
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"?
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://%5B2620:0:2d0:200::8%5D/ vs http://2620:0:2d0:200::8:80/ vs http://%5B2620:0:2d0:200::8%5D:80/. See RFC 2732.
cheers
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://%5B2620:0:2d0:200::8%5D/ vs http://2620:0:2d0:200::8:80/ vs http://%5B2620:0:2d0:200::8%5D: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
On 10/24/12 14:51, Juha Heinanen wrote:
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://%5B2620:0:2d0:200::8%5D/ vs http://2620:0:2d0:200::8:80/ vs http://%5B2620:0:2d0:200::8%5D: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.
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
On 10/24/12 9:02 PM, Juha Heinanen wrote:
Richard Fuchs writes:
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.
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 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
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
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).
On 10/25/12 4:33 PM, Alex Hermann wrote:
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.
Cheers, Daniel
======== 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).
On Thursday 25 October 2012, Daniel-Constantin Mierla wrote:
On 10/25/12 4:33 PM, Alex Hermann wrote:
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.
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)
On 10/25/2012 05:33 PM, Alex Hermann wrote:
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. . .
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
. 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).
On 24.10.2012 20:41, Juha Heinanen wrote:
Richard Fuchs writes:
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"?
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
-
Alex Hermann -
Daniel-Constantin Mierla -
Juha Heinanen -
Klaus Darilion -
Marius Zbihlei -
Richard Fuchs