Re: [IPCop-devel] Regarding local (green) DNS and global (red) DNS suffixes

[Harry G. <ha...@hg...>]

There's an easy way to diagnose what's happening.  Login to IPCop as 
root via ssh or via a real console and issue the command:

tcpdump -s 0 -i eth0 port 53

tcpdump will dump the full (-s 0) packets received or sent on (port 
53) - DNS at its interface (-i eth0).  If your green network is not 
on eth0, you may have to change the -i option.

Then bring up IE or whatever and try to go to www or whatever and see 
what the resulting domain name is.  Use Ctl-C to kill tcpdump.

Harry
At 1:14 AM +0100 6/30/03, Matthew Dale wrote:
>  > At 5:19 PM +0100 6/29/03, st...@wo... wrote:
>>  >On 29.06.2003 16:35 Matthew Dale wrote:
>>  >>Issue number 1: Local DNS
>>  >>Many people seem to have difficulty in getting to ipcop via
>>  >>http://ipcop:81 as stated in the manual - I am among these people.
>>  >>I'm using DHCP to set clients up - and the dns server is set as IPCop
>>  >>as it should be. However, all I get is 404s trying to access like
>>  >>that, and ping can't ping it either - leaving me with
>>  >>http://192.168.0.1:81 as the only surefire way to access it.
>>  >>I have recieved a couple of workaround, one of which in particular
>>  >>poses questions about how the lookup is handled.
>>  >>The first workaround is to set the DNS Suffix to mydomain.home (or
>>  >>something similar) and add a line "192.168.0.1 ipcop.mydomain.home" to
>>  >>/etc/hosts on the IPCop box. This works fine - it pings, and the
>>  >>browser can see it.
>>  >
>>  >I would have thought that you should be doing this anyway. I always have
>
>Maybe I should. I was just curious as to why it didn't work "as advertised".
>
>>  Both Windows and Mac OS X have a different way they do DNS lookups
>>  from the Unix/Linux systems of the world, if they see a name with no
>>  periods.  Unix/Linux will try any name with or without periods before
>>  they append the DNS suffix to it while Windows and Mac OS X
>>  immediately append the suffix.  In other words, a Unix box will first
>>  send a query for "ipcop" and then for "ipcop.mydomain.home", while
>>  Windows and Mac will never send the query for ipcop.  Adding a period
>>  makes everyone happy.
>>
>>  BTW, if you make a typo and try to browse "www.ipcop.orgg", everyone
>>  will first try "www.ipcop.orgg" and then
>>  "www.ipcop.orgg.mydowmain.home".
>
>So basicly, it would work fine on a *nix machine - ok, I can live with that
>and add to my grumble-list for windows and networking...
>
>>  >>
>>  >>Issue number 2: Global DNS Suffixes
>>  >>As I said above in the first workaround, DNS suffixs work fine for me
>>  >>locally.
>>  >>However, global ones don't. Here is a test case I just ran.
>>  >>I set the DNS suffix to "bbc.co.uk". I renewed my DHCP lease and
>>  >>checked that the new settings had come through. I then flushed the DNS
>>  >>cache on the box I was using to test the suffix to remove any chance
>>  >>of it using a precached result.
>>  >>With this setup, requesting "www" should get me http://www.bbc.co.uk,
>>  >>and requesting "news" should get me http://news.bbc.co.uk, and so on.
>>  >>Not so. any request that relies on the suffix results in a 404.
>>  >>However, an inspection of the local DNS cache after the request
>>  >>reveals an entry like:
>>  >>news
>>  >
>>  >Are you running a web proxy, if so it might not work, since you
>>  >would look for news and so might the proxy.
>>  >If domain name was not defaulted on the proxy then the it would look for
>news.
>>  >Just an idea.
>I've tried it with squid on (transparent), on ('normal'), and off. I flushed
>the local DNS cache and restarted IPCop before testing in each mode. I got
>identical results in all modes - the DNS lookup would be sucessfully
>recieved by the local machine but the browser would still 404. In all modes,
>it worked for all other services.
>In fact, I did a bit more testing, and here's where it gets odd. I tried
>this at the windows command prompt:
>telnet www 80
>I was expecting a destination unreachable error or something, but instead it
>connected. Hitting enter resulted in what I'd expect to happen if I'd typed
>the full address myself (I got the HTML for the "bad request" response
>spewed down the screen because I'd not specified any HTTP header before
>sending the CR). So it works at the lowest level - I guess there's something
>up at the API level - still sufficiently low level that it's used by both
>Mozilla and IE, but abstracted enough that using telnet circumvents it.
>Yet another thing to add to the windows grumble list then.
>>  >
>>  >Why not net the domain and be done with it?
>The people who will be using the system are used to being able to type
>"mail" etc and being directed straight to thier webmail login. I'll just
>have to sort out the local hosts files.
>
>>  >
>>  ><me thinks out aloud>
>>  >Maybe people who 'know' about networking are setting the domain
>>  >without thinking about it, whereas those we problems are not.
>>  ></me thinks out aloud>
>>
>>  This sounds like you're not getting the DNS domain set properly on
>>  the machine doing the browsing and are you sure you didn't type
>>  "news."?
>>
>>  Harry
>
>I definately didn't. I tried it later out of interest, but during the
>testing I didn't use a trailing period.
>Ah well, it looks like IPcop is functioning perfectly and windows is just
>being irregular as usual. Maybe there should be a section added to the FAQ
>on this, detailing both workarounds?
>
>Thanks for your responses anyway.
>
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
>_______________________________________________
>IPCop-devel mailing list
>IPC...@li...
>https://lists.sourceforge.net/lists/listinfo/ipcop-devel