Note to self from reading TCP/IP Illustrated. Probably should verify w/ DNS server logs that explicit FQDNs work differently than FQDN's.

its worth noting here that URL BNF definitions in the first two URL RFCs (1630 nad 1738 by my recollection) do not contemplate this.

This test is also relevant to the various unsolved mysteries regarding resolution of "localhost".

NEW - 40082 proves this bug.

Another area this might be useful is an enhancement to the "No Proxy For:" list in Manual proxy. Currently, it seems like we do some generic string compare between the URL hostname and items in the "No Proxy" list. (I'm no programer, so somebody please correct my jargon about the strings...) So if you have "gram.com" blocked, it will also affect "packetgram.com". This is why the dialog says you should begin blocked domain suffixes w/ a dot. So I think there are lots of hostname is a superset of blocklist element problems (like blocking a country w/ .de or .tr). I need to test this further, but if this is a problem, the best solution might be to make sure we literalize the url hostname to an fqdn that is "." terminated and fully qualify the block list element with a trailing "." and or do a compare that matches last character to first in the strings.

I've set up a test DNS server, I'll be testing the behavior of URL's that have a "." at the end of the hostname soon.

QA futuring of various bugs to focus on remaning bugs. If you think your bug needs immediate attention for Mozilla 1.0, set the milestone to "--". I will review these bugs (again) later.

RFC 2396 says: The rightmost domain label of a fully qualified domain name will never start with a digit, thus syntactically distinguishing domain names from IPv4 addresses, and may be followed by a single "." if it is necessary to distinguish between the complete domain name and any local domain. To actually be "Uniform" as a resource locator, a URL hostname should be a fully qualified domain name. In practice, however, the host component may be a local domain literal. Darin and I have also had some discussion as to whether or the resolver should be sent the hostname as a FQDN rather than a possibly PQDN. Some resolvers will treat multi-label domain names as non-FQDN's, and if the initial request fails, they will use the search domains and search again. This would lengthen the time before a "hostname not found" error is returned. What we probably should do is: 1- If the domain name is a single hostname, send it to the resolver 2- If the domain name is two or more labels, send it to the resolver as an FQDN, since the RFC disallows PQDNs in the hostip field (and I have never heard of anyone doing his anyhow).

Example: Using: mozilla% more /etc/resolv.conf domain nscp.aoltw.net nameserver <anyDNSserver> A normal URL that points to a non-existent host searches twice: http://nonexistent.mozilla.org/ h-10-169-111-114.nscp.aoltw.net -> regress DNS C port=49156 0: 0b6e 6f6e 6578 6973 7465 6e74 076d 6f7a .nonexistent.moz 16: 696c 6c61 036f 7267 0000 0100 01 illa.org..... regress -> h-10-169-111-114.nscp.aoltw.net DNS R port=49156 0: 0b6e 6f6e 6578 6973 7465 6e74 076d 6f7a .nonexistent.moz 16: 696c 6c61 036f 7267 0000 0100 01 illa.org..... h-10-169-111-114.nscp.aoltw.net -> regress DNS C port=49156 0: 0b6e 6f6e 6578 6973 7465 6e74 076d 6f7a .nonexistent.moz 16: 696c 6c61 036f 7267 046e 7363 7005 616f illa.org.nscp.ao 32: 6c74 7703 6e65 7400 0001 0001 ltw.net..... regress -> h-10-169-111-114.nscp.aoltw.net DNS R port=49156 0: 0b6e 6f6e 6578 6973 7465 6e74 076d 6f7a .nonexistent.moz 16: 696c 6c61 036f 7267 046e 7363 7005 616f illa.org.nscp.ao 32: 6c74 7703 6e65 7400 0001 0001 ltw.net..... Make the hostip field an FQDN when sent to resolver: http://nonexistent.mozilla.org./ h-10-169-111-114.nscp.aoltw.net -> regress DNS C port=49156 0: 0b6e 6f6e 6578 6973 7465 6e74 076d 6f7a .nonexistent.moz 16: 696c 6c61 036f 7267 0000 0100 01 illa.org..... regress -> h-10-169-111-114.nscp.aoltw.net DNS R port=49156 0: 0b6e 6f6e 6578 6973 7465 6e74 076d 6f7a .nonexistent.moz 16: 696c 6c61 036f 7267 0000 0100 01 illa.org..... Only one request is sent. For every search domain, an additional, suprious query would go out each time you looked for a nonexistent domain.

gordon for investigation.

This is marked as a PC bug, but something very similar happens in Mac OS X. I find it happens in Mozilla 1.6 and apparently in Firefox 0.8 but not in Camino 0.7. The log below shows a trace of DNS packets to/from my DNS server while I do a load of a web page, file:///Users/tyson/Desktop/test.html with Mozilla. The html causes a CSS page to be loaded from a remote host (in this case, wmt.addr.com). It is that lookup of the remote host that is the problem. (The html and css files are included below.) Catesby2 5:23pm<2> 162: sudo tcpdump -n -i en1 -vv tcpdump: listening on en1, link-type EN10MB (Ethernet), capture size 96 bytes First, do a DNS address lookup on the host with the CSS file 17:24:16.039363 IP (tos 0x0, ttl 64, id 58701, offset 0, flags [none], length: 58) 192.168.1.11.54452 > 208.201.224.11.53: [udp sum ok] 41170+ A? wmt.addr.com. (30) 17:24:16.104214 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], length: 141) 208.201.224.11.53 > 192.168.1.11.54452: 41170 q: A? wmt.addr.com. 1/2/2 wmt.addr.com. A 209.249.147.15 ns: addr.com.[|domain] I don't understand why this DNS query is done. Apparently this is a SOA query. It is probably done in error. 17:24:16.105044 IP (tos 0x0, ttl 64, id 58702, offset 0, flags [none], length: 58) 192.168.1.11.54453 > 208.201.224.11.53: [udp sum ok] 17898+ AAAA? wmt.addr.com. (30) 17:24:16.134851 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], length: 102) 208.201.224.11.53 > 192.168.1.11.54453: 17898 q: AAAA? wmt.addr.com. 0/1/0 ns: addr.com. SOA[|domain] This query is bogus. Apparently the Search Domain "ai.sri.com" is appended to the host name and another query is done. This would be appropriate if the previous A query had failed. 17:24:16.135339 IP (tos 0x0, ttl 64, id 58703, offset 0, flags [none], length: 69) 192.168.1.11.54454 > 208.201.224.11.53: [udp sum ok] 27861+ AAAA? wmt.addr.com.ai.sri.com. (41) 17:24:16.164724 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], length: 115) 208.201.224.11.53 > 192.168.1.11.54454: 27861 NXDomain q: AAAA? wmt.addr.com.ai.sri.com. 0/1/0 ns: ai.sri.com. SOA[|domain] Now we see the CSS file being looked up and returned by the web server. 17:24:16.180587 IP (tos 0x0, ttl 64, id 58756, offset 0, flags [DF], length: 60) 192.168.1.11.54338 > 209.249.147.15.80: S [tcp sum ok] 867152129:867152129(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 2431735143 0> ================ test.html: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <link rel="stylesheet" type="text/css" href="http://wmt.addr.org/foo.css"> </HEAD> <BODY> <span class="fanpoll">Test</span> </BODY> </HTML> ================ foo.css .fanpoll {color:#990000; font-size: 16px; font-weight: bold;} ================

i actually think this threatens webcompat and doesn't have upside at this point