Closed Bug 1563886 Opened 6 years ago Closed 6 years ago

ipv4OnlyDomains breaks ipv6

Categories

(Core :: Networking: DNS, defect)

Product:
Core
Component:
Networking: DNS
Version:
67 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: k, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

About:config
enter any domain in network.dns.ipv4OnlyDomains

Actual results:

now everything connects only using ipv4
set network.dns.ipv4OnlyDomains to blank, and sites again connect using ipv6
found it looking at F12->Network

Expected results:

only listed domains should connect ipv4 only

Hi @K, for now what can I do for this issue is only setting a component, further someone from dev's team could give us a hand.
Thanks.

Blocks: IPv6
Component: Untriaged → Networking
Product: Firefox → Core

I can't reproduce this at my side.
Could you share how did you set network.dns.ipv4OnlyDomains? Maybe we have a bug regarding parsing the ipv4OnlyDomains string.

Component: Networking → Networking: DNS
Flags: needinfo?(k)

I can reproduce it on windows and linux with FF 67
Set anything
For example, it reproduces with "vk.com,vk.me,youtube.com,googlevideo.com"
After setting/unsetting the value clear cache and close tab with the test site or restart browser

Flags: needinfo?(k)

After additional tests it looks like only http is affected, not https
Test it on http://afraid.org
this domain has both A and AAAA
check unsecure requests in F12->Network page

(In reply to k from comment #4)

After additional tests it looks like only http is affected, not https
Test it on http://afraid.org
this domain has both A and AAAA
check unsecure requests in F12->Network page

I think this should has nothing to do with http and https.
Could you use about:networking to reproduce again? Please see my steps below.

  1. In address bar, type about:networking.
  2. Go to DNS Lookup
  3. Type afraid.org and do resolve.
  4. I see one ipv6 address (2604:8b80:2:8::2) and one ipv4 address (204.140.20.21).
  5. Go to about:config and set network.dns.ipv4OnlyDomains to afraid.org.
  6. Go back to about:networking and do resolve again.
  7. You should only see one ipv4 address.
  8. Change the domain to google.com and do resolve again.
  9. I can see both ipv6 and ipv4 address.
Flags: needinfo?(k)

May be UB causes something impossible?
https://searchfox.org/mozilla-central/rev/f372470e10c8cb0691681603a1d6324dee5b3b8a/netwerk/dns/nsDNSService2.cpp#1175,1182
hostTail - 1 will point before hostStart if hostLen == domainLen and domain will point after domainEnd if it is the last element of the mIPv4OnlyDomains list. Both are UB.

hostTail - 1 will point before hostStart if hostLen == domainLen

Sorry, hostTail - 1 will never be evaluated when hostLen == domainLen due to short-circuit evaluation. But the latter is still UB.

(In reply to Masatoshi Kimura [:emk] from comment #8)

hostTail - 1 will point before hostStart if hostLen == domainLen

Sorry, hostTail - 1 will never be evaluated when hostLen == domainLen due to short-circuit evaluation. But the latter is still UB.

So you suggest a parser error? Rewrite with Tokenizer then?

Flags: needinfo?(VYV03354)

@k, Could you test whether this build fixes your issue?
https://tools.taskcluster.net/groups/SmTPWv4dS7iX5iskDXza0A/tasks/AjVr9FJbRl69RvSzQ3Y0yA/runs/0/artifacts

Flags: needinfo?(VYV03354) → needinfo?(k)

(In reply to Masatoshi Kimura [:emk] from comment #10)

@k, Could you test whether this build fixes your issue?
https://tools.taskcluster.net/groups/SmTPWv4dS7iX5iskDXza0A/tasks/AjVr9FJbRl69RvSzQ3Y0yA/runs/0/artifacts

Nothing changed

Flags: needinfo?(k)

Hi @Kershaw Chang, I've followed your scenario(using ff 67.0 version) but still cannot reproduce the issue. On my end at step 4 it shows only ipv4 address.
Thanks

If I understand comment #6 correctly, the string parser works as expected. The reporter said that both ipv6 and ipv4 addresses can be seen in about:networking.

@k, I think maybe http log can help us figure out the problem.
Could you try to capture the log after you set the ipv4OnlyDomains?
Thanks.

Flags: needinfo?(k)

(In reply to Kershaw Chang [:kershaw] from comment #13)

If I understand comment #6 correctly, the string parser works as expected. The reporter said that both ipv6 and ipv4 addresses can be seen in about:networking.

@k, I think maybe http log can help us figure out the problem.
Could you try to capture the log after you set the ipv4OnlyDomains?
Thanks.

https://www.sendspace.com/file/or6kkv

Flags: needinfo?(k)

Kershaw, will you find time to look at the log?

Flags: needinfo?(kershaw)

(In reply to Honza Bambas (:mayhemer) from comment #15)

Kershaw, will you find time to look at the log?

The log looks all correct to me.
The log shows that we get both ipv6 and ipv4 addresses for afraid.org.

  • 2019-07-15 08:52:50.909000 UTC - [Parent 5244: DNS Resolver #14]: D/nsHostResolver CompleteLookup: afraid.org has 2604:8b80:2:8::2
  • 2019-07-15 08:52:50.909000 UTC - [Parent 5244: DNS Resolver #14]: D/nsHostResolver CompleteLookup: afraid.org has 204.140.20.21

The socket uses the address 2604:8b80:2:8::2 to connect.

  • 2019-07-15 08:52:50.909000 UTC - [Parent 5244: Socket Thread]: E/nsSocketTransport nsSocketTransport::SendStatus [this=000001B0CC24F000 status=804b0007]
  • 2019-07-15 08:52:50.909000 UTC - [Parent 5244: Socket Thread]: V/nsHttp nsHalfOpenSocket::SetupBackupTimer() [this=000001B0C9D546B0]
  • 2019-07-15 08:52:50.909000 UTC - [Parent 5244: Socket Thread]: D/nsSocketTransport trying address: 2604:8b80:2:8::2

The socket connects to the server successfully.

  • 2019-07-15 08:52:51.086000 UTC - [Parent 5244: Socket Thread]: E/nsSocketTransport nsSocketTransport::OnSocketReady [this=000001B0CC24F000 outFlags=2]
  • 2019-07-15 08:52:51.086000 UTC - [Parent 5244: Socket Thread]: D/nsSocketTransport advancing to STATE_TRANSFERRING
  • 2019-07-15 08:52:51.086000 UTC - [Parent 5244: Socket Thread]: E/nsSocketTransport nsSocketTransport::SendStatus [this=000001B0CC24F000 status=804b0004]

The log shows that firefox did use address 2604:8b80:2:8::2 to connect to afraid.org.

Honza, what do you think? Is there any points that I need to check?
Thanks.

Flags: needinfo?(kershaw) → needinfo?(honzab.moz)

(In reply to k from comment #14)

(In reply to Kershaw Chang [:kershaw] from comment #13)

If I understand comment #6 correctly, the string parser works as expected. The reporter said that both ipv6 and ipv4 addresses can be seen in about:networking.

@k, I think maybe http log can help us figure out the problem.
Could you try to capture the log after you set the ipv4OnlyDomains?
Thanks.

https://www.sendspace.com/file/or6kkv

And what was the value of the prefence?

Flags: needinfo?(honzab.moz) → needinfo?(k)

I see nothing wrong in the log. We try the first address the resolver (apparently native) returns. First attempts per-host are w/o family restrictions:

2019-07-15 08:52:50.907000 UTC - [Parent 5244: DNS Resolver #14]: D/nsHostResolver CompleteLookup: afraid.org has 2604:8b80:2:8::2
2019-07-15 08:52:50.907000 UTC - [Parent 5244: DNS Resolver #14]: D/nsHostResolver CompleteLookup: afraid.org has 204.140.20.21

ipv6 wins here. Note that we don't re-sort (afaik) the records we get. then, we have a racy and kinda non-deterministic algorithm that tries the first address in the list and if there is no SYN/ACK in 250ms, we try (in parallel) IP from the opposite family. If the second conn attempt wins over the first one, we remember the ip family preference and all other connection attempts go via that preferred family.

then note that http2 (=https + http/2.0) connections are coalesced when the certificate provided is also valid for different hosts. so if vk.com and afraid.org happen to share servers, they may both go via the ipv4, if you already have https://vk.com connection.

I think this is INVALID unless I'm missing something or more resilient prove that this could be a firefox bug is presented.

Close this as INVALID, since the log shows that firefox actually did nothing wrong and ipv6 address can be also seen in about:networking.
Feel free to reopen this if you have more information to provide.

Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.