[jitsi-dev] More DNS issues


#1

Hey

I found some more DNS issues:
- ProtocolProviderServiceSipImpl.resolveSipAddress
  String[][] naptrRecords = NetworkUtils.getNAPTRRecords(address);
  -> These naptrRecords are not necessarily SRV records, but might be an A, U or a chained NAPTR

- NetworkUtils.getSRVRecords
  - Returns only IP addresses, not hostnames (because the InetAddress of getARecord doesn't contain the hostname)
  - The retuned IP addresses are IPv4 only, although the target of the SRV might be IPv6 as well

- ProtocolProviderServiceSipImpl.resolveSRV
  -> Because of the missing hostname in the records returned from NetworkUtils.getSRVRecords there are again PTR queries. The resolveAddresses later on actually performs an A/AAAA on the PTR of the IP of the SRV-Host.
  -> This comment is therefore invalid
  //as these are already resolved addresses (the SRV res.)
  // lets get it without triggering a PTR

Possible solutions:
1) Return a sorted array of [hostname, port]
2) Query for IPv4 and IPv6 inside getSRVRecord and make getA[AAA]Record return InetAdresses with the hostname prefilled

Solution 2 makes further lookups of IP addresses after an SRV query superfluous

Example: Step through the lookup of sip2sip.info

@Emil: I need the correct hostname of the current proxy returned from NAPTR/SRV queries for the other off-list issue I'm working on.

Regards,
Ingo


#2

Hey Ingo,

На 16.03.11 20:34, Bauersachs Ingo написа:

Hey

I found some more DNS issues:
- ProtocolProviderServiceSipImpl.resolveSipAddress
  String[][] naptrRecords = NetworkUtils.getNAPTRRecords(address);
  -> These naptrRecords are not necessarily SRV records, but might be an A, U or a chained NAPTR

Correct. We should strip those and probably also rename the method to
reflect we are only interested in the SRVs

- NetworkUtils.getSRVRecords
  - Returns only IP addresses, not hostnames (because the InetAddress of getARecord doesn't contain the hostname)
  - The retuned IP addresses are IPv4 only, although the target of the SRV might be IPv6 as well

Correct again. If we want to continue returning socket addresses here
we'd have to make sure we do both the A and the AAAA resolution.
Alternately we could simply return name:port couples where "name" is a
String.

- ProtocolProviderServiceSipImpl.resolveSRV
  -> Because of the missing hostname in the records returned from NetworkUtils.getSRVRecords there are again PTR queries. The resolveAddresses later on actually performs an A/AAAA on the PTR of the IP of the SRV-Host.
  -> This comment is therefore invalid
  //as these are already resolved addresses (the SRV res.)
  // lets get it without triggering a PTR

Possible solutions:
1) Return a sorted array of [hostname, port]
2) Query for IPv4 and IPv6 inside getSRVRecord and make getA[AAA]Record return InetAdresses with the hostname prefilled

Oh, OK, hadn't seen this. Well agreed already, and at this point I am
not sure if I have a preference for 1 or 2 ... ok maybe a slight one for
keeping the socket addresses.

Solution 2 makes further lookups of IP addresses after an SRV query superfluous

Example: Step through the lookup of sip2sip.info

@Emil: I need the correct hostname of the current proxy returned from NAPTR/SRV queries for the other off-list issue I'm working on.

I don't really mind having our inet addresses prefilled with host names
when those are available. What I do mind, as I already mentioned to you,
is ever using InetAddress.getHostName() since it would trigger PTRs when
names are not available for one reason or another.

Is there a problem retrieving the name of the outbound proxy from the
provider as we discussed yesterday?

Cheers,
Emil

P.S. I believe Damian went through your DNS conf patch today. He'll
probably commit a modified version tomorrow and post his comments here.


#3

- ProtocolProviderServiceSipImpl.resolveSRV
[...]
Possible solutions:
1) Return a sorted array of [hostname, port]
2) Query for IPv4 and IPv6 inside getSRVRecord and make getA[AAA]Record

return InetAdresses with the hostname prefilled

Oh, OK, hadn't seen this. Well agreed already, and at this point I am
not sure if I have a preference for 1 or 2 ... ok maybe a slight one for
keeping the socket addresses.

I don't really mind having our inet addresses prefilled with host names
when those are available. What I do mind, as I already mentioned to you,
is ever using InetAddress.getHostName() since it would trigger PTRs when
names are not available for one reason or another.

If we want to ban the use of getHostName() completely we need to go with attempt 1.

Is there a problem retrieving the name of the outbound proxy from the
provider as we discussed yesterday?

These issues are inside the provider - and retrieving the outbound proxy means I need to have access to the hostname if it was one in the SRV originally. Currently only the resolved IP is stored. There is absolutely no problem when auto detection is turned off.

P.S. I believe Damian went through your DNS conf patch today. He'll
probably commit a modified version tomorrow and post his comments here.

If there's some work left on this - just tell me what needs to be fixed so I can adapt my coding style for further patches.

Ingo


#4

На 16.03.11 21:38, Bauersachs Ingo написа:

- ProtocolProviderServiceSipImpl.resolveSRV [...] Possible
solutions: 1) Return a sorted array of [hostname, port] 2) Query
for IPv4 and IPv6 inside getSRVRecord and make getA[AAA]Record

return InetAdresses with the hostname prefilled

Oh, OK, hadn't seen this. Well agreed already, and at this point I
am not sure if I have a preference for 1 or 2 ... ok maybe a slight
one for keeping the socket addresses.

I don't really mind having our inet addresses prefilled with host
names when those are available. What I do mind, as I already
mentioned to you, is ever using InetAddress.getHostName() since it
would trigger PTRs when names are not available for one reason or
another.

If we want to ban the use of getHostName() completely we need to go
with attempt 1.

Indeed.

I am having a doubt here though. When connecting to my account
emcho@a.com and if a.com's SRV points to b.com shouldn't I see a
certificate for a.com? As a user I never chose the name b.com and I'd be
surprised to see it.

Emil

···

Is there a problem retrieving the name of the outbound proxy from
the provider as we discussed yesterday?

These issues are inside the provider - and retrieving the outbound
proxy means I need to have access to the hostname if it was one in
the SRV originally. Currently only the resolved IP is stored. There
is absolutely no problem when auto detection is turned off.

P.S. I believe Damian went through your DNS conf patch today.
He'll probably commit a modified version tomorrow and post his
comments here.

If there's some work left on this - just tell me what needs to be
fixed so I can adapt my coding style for further patches.


#5

Hi Ingo, Emil,

···

Le 16/03/2011 21:38, Bauersachs Ingo a écrit :

Oh, OK, hadn't seen this. Well agreed already, and at this point I am
not sure if I have a preference for 1 or 2 ... ok maybe a slight one for
keeping the socket addresses.

I don't really mind having our inet addresses prefilled with host names
when those are available. What I do mind, as I already mentioned to you,
is ever using InetAddress.getHostName() since it would trigger PTRs when
names are not available for one reason or another.
     
If we want to ban the use of getHostName() completely we need to go with attempt 1.

I also need to retrieve the hostname from SRV record regarding stuff for Google Contacts support. I will make some changes soon (getSRVRecord will return a SRVRecord of our own that will contains hostname, port, InetSocketAddress, ...

Regards,
--
Seb


#6

Hi Ingo, Emil,

···

Le 16/03/2011 21:38, Bauersachs Ingo a écrit :

- ProtocolProviderServiceSipImpl.resolveSRV
[...]
Possible solutions:
1) Return a sorted array of [hostname, port]
2) Query for IPv4 and IPv6 inside getSRVRecord and make getA[AAA]Record
       

return InetAdresses with the hostname prefilled

Oh, OK, hadn't seen this. Well agreed already, and at this point I am
not sure if I have a preference for 1 or 2 ... ok maybe a slight one for
keeping the socket addresses.

I don't really mind having our inet addresses prefilled with host names
when those are available. What I do mind, as I already mentioned to you,
is ever using InetAddress.getHostName() since it would trigger PTRs when
names are not available for one reason or another.
     
If we want to ban the use of getHostName() completely we need to go with attempt 1.

I also need to retrieve the hostname from SRV record regarding stuff for Google Contacts support. I will make some changes soon (getSRVRecord will return a SRVRecord of our own that will contains hostname, port, InetSocketAddress, ...

Regards,
--
Seb