[LispM] What does a valid internet address look like?

[Steven Nunez]

Thank-you Kalman, the hint on debugging enabled me to solve the problem, although there are still a few things that baffle me. The most puzzling is why, when the local DNS server answers (host diskstation), the resolver continues asking other hosts to resolve the query? You can see this in the trace below, where it receives an answer from diskstation, then goes right on to ask hurricane-dns. At least the parse-msg output makes me think diskstation provided answers.

 



 

 

A few observations for anyone doing this in the future:

 

*	The Genera resolver seems to ask at most two DNS servers, then fails. It would be nice to be able to increase this number.
*	The majority of the DNS servers I tried do not respond properly to the wildcard request. Trial and error is required.

 

@Kalman, you mentioned “…things might work better with such a misbehaving server by making :internet requests instead of wildcard requests.” That might be worth a try. How do I do that?

 

Thanks & Regards,

Steve

 

 

From: Kalman Reti [mailto:kalman.reti at gmail.com] 
Sent: 20 August, 2017 05:16
To: Steven Núñez <steven.nunez at illation.com>
Cc: ams at gnu.org; lispm at tunes.org
Subject: Re: [LispM] What does a valid internet address look like?

 

On Aug 19, 2017 4:58 AM, "Steven Nunez" <steven.nunez at illation.com.hk <mailto:steven.nunez at illation.com.hk> > wrote:

A small step forward: I know that it is not because of communication issues. Taking Alfred's advice, I set-up a local DNS server and confirmed connectivity, recursive look-ups, etc, but the problem persists. I had a look at the stack trace:

 



 

 

And had a look at the code in neti and host.lisp. Not pretty. I am not sure where to begin.

Regards,

*	Steve

 

-----Original Message-----
From: Alfred M. Szmidt [mailto:ams at gnu.org <mailto:ams at gnu.org> ] 

Sent: 18 August, 2017 17:05
To: steven.nunez at illation.com <mailto:steven.nunez at illation.com> 
Cc: lispm at tunes.org <mailto:lispm at tunes.org> 
Subject: Re: [LispM] What does a valid internet address look like?

 

   No, still stuck. Most recently I added the remote DNS servers as hosts in

   the namespace with them listed as providing the service, like this:

 

   HOST GOOGLE-RESOLVER

   SERVICE DOMAIN TCP DOMAIN

   ADDRESS INTERNET 8.8.8.8

   SYSTEM-TYPE UNIX42

   NICKNAME GOOGLE-DNS

   SITE SINGAPORE

 

   but still no name resolution. Very frustrating; normally the docs are quite

   good, but something is clearly wrong. I've attached the entire namespace

   file here too. Maybe I'm missing something obvious.

 

 

Does your site have an internet address on its namespace object, root domain servers defined on its site object (plus the recursive query property set to yes) and at least one host with 'domain tcp domain' service?

 

If yes, you domain server is probably refusing wildcard requests (i.e. :*). AFAIK this is not allowed in the original RFC's, but things might work better with such a misbehaving server by making :internet requests instead of wildcard requests.

 

By binding neti:*debug-domain-requests* to non-nil around a request, you can see the queries to and responses from the server, e.g.

 

(let ((neti:*debug-domain-requests* t)) (si:parse-host "www.ibm.com <http://www.ibm.com> "))

 

Did you read the netio documentation?  I don't have Genera setup up currently to look.  I do have a vauge recollection that DNS names are just plain strings, i.e. "abc.com <http://abc.com> ".  Now, one issue might be just that Google's DNS is not responding, or that Genera is sending garbage.

Can you check that, or use a local BIND instance?

 

Do nyou have a host that talks telnet somewhere? I'm sure that telnet accepts some sort of a hostname which you could test.  Many of the basic stuff like ICMP only take an address.


_______________________________________________
LispM mailing list
LispM at tunes.org <mailto:LispM at tunes.org> 
http://lists.tunes.org/mailman/listinfo/lispm

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </archives/lispm/attachments/20170820/ce69b5a4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 26873 bytes
Desc: not available
URL: </archives/lispm/attachments/20170820/ce69b5a4/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 41404 bytes
Desc: not available
URL: </archives/lispm/attachments/20170820/ce69b5a4/attachment-0003.png>