A comment on hotel service

[Steve Crocker]

Roy, et al.,

Your comment about hotel service adds to a separate concern about  
IPv6 service from hotels.

I'd like to see some pressure applied to hotels to offer cleaner,  
more complete service.  Here's a thought I've been kicking around.

Competent people -- that is, people like you but not like me ;) --  
should put together a suite of tests that can be run by travelers  
whenever we're in hotel rooms.  The tests should check for clean DNS  
service -- I leave it to you to define what that means -- and clean  
IPv6 service.  Further, let's have the test generate an email message  
that captures the name of the hotel, information about the ISP and  
the date, and then have that email collected and automatically  
processed.  A web site showing the results then becomes a good  
scoreboard.

I've recommended something like this be done when we look at hotels  
as possible meetings sites for IETF, ICANN or other meetings, but the  
idea could be expanded more fully.  If the tests were packaged up to  
be easy to run, I'll bet lots of people would run them and we'd  
quickly gather lots of data.

The tests should be fully documented and should not make unnecessary  
complaints.

Thoughts?

Steve

Steve Crocker
steve at shinkuro.com

Try Shinkuro's collaboration technology.  Visit www.shinkuro.com.  I  
am steve!shinkuro.com.


On May 7, 2007, at 10:25 AM, Roy Arends wrote:

> Sigh,
>
> My dig queries where send from a hotel network. Seems that those  
> request are forcefully directed to a local resolver cluster,  
> regardless of what I specify on the cli.
>
> So, forget the part about the empty response message and the AA  
> bit. I was being lied to. It works as expected from less intrusive  
> networks.
>
> Roy
>
>
> Considering to connect the 230V power outlet to the RJ45 ethernet  
> inlet to punish whatever equipment does this. to prove the hotel  
> that I can do silly network hacks as well ;-)
>
>
>
>
> On May 7, 2007, at 4:09 PM, Roy Arends wrote:
>
>> Few things, though. I've queried for a few non-existent domains  
>> under test.mx and noticed that I only get the proper info on the  
>> second try. The first try returns mostly, well, nothing usable:
>>
>> dig +dnssec @201.131.249.45 b.test.mx a
>>
>> ; <<>> DiG 9.3.2 <<>> +dnssec @201.131.249.45 b.test.mx a
>> ; (1 server found)
>> ;; global options:  printcmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36997
>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0,  
>> ADDITIONAL: 0
>>
>> ;; QUESTION SECTION:
>> ;b.test.mx.                     IN      A
>>
>> ;; Query time: 4 msec
>> ;; SERVER: 201.131.249.45#53(201.131.249.45)
>> ;; WHEN: Mon May  7 15:07:51 2007
>> ;; MSG SIZE  rcvd: 27
>>
>> (Maybe there is a loadbalancer, and one server instance behind it  
>> is not configured
>> properly ?)
>>
>> On the second try, I indeed get the expected information back,  
>> though I have a small suggestion for the nsec record that is being  
>> altered:
>>
>> azzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test. 
>> mx. 1363 IN NSEC b0.test.mx. NS DS RRSIG NSEC
>>
>> I'd scrub the NS DS types.
>>
>> Another point, the thing on port 53 does not set the AA bit. Some  
>> resolvers expect this. Also not that due to caching, the thing on  
>> port 53 might have outdated data.
>>
>> What are you using as a secure key store, if any ? (a bcm5821 does  
>> the acceleration, not the secure key storage). Are you using  
>> native openbsd support ? This would nicely avoid any purpose build  
>> engine or any hacks to existing signers.
>>
>> I'm looking forward to the code. Meanwhile, as for Crypto Hardware  
>> and DNSSEC, we have some information about that at http:// 
>> blog.nominet.org.uk/
>>
>> Thanks !
>>
>> Roy
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> #############################################################
>> This message is sent to you because you are subscribed to
>>  the mailing list <dnssec-deployment at shinkuro.com>.
>> To unsubscribe, E-mail to: <dnssec-deployment-off at shinkuro.com>
>> A public archive is available here: <http://mail.shinkuro.com:8100/ 
>> Lists/dnssec-deployment/>
>> and older material is at
>> <http://mail.shinkuro.com:8100/Lists/dnssec-deployment-archive/>
>>
>
>
> #############################################################
> This message is sent to you because you are subscribed to
>  the mailing list <dnssec-deployment at shinkuro.com>.
> To unsubscribe, E-mail to: <dnssec-deployment-off at shinkuro.com>
> A public archive is available here: <http://mail.shinkuro.com:8100/ 
> Lists/dnssec-deployment/>
> and older material is at
> <http://mail.shinkuro.com:8100/Lists/dnssec-deployment-archive/>