In message <E041A687-5597-4D5B-AE07-8E1CD98F3225@xxxxxxxxxxxxxxx>, Henning Schu lzrinne writes: > As part of a research project, we are working on automated diagnostics > of network-related faults in residential, SOHO, conference/special > event, hotel and similar networks. If you have observed errors that > were hard for a lay person to diagnose, whether due to end system > problems, NATs, LAN or Internet issues, please send me a brief > description. (Also, contacts in tech support for such environments > would be most helpful, particularly if they might be willing to talk > to us.) > > Henning > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf 1. Hotel's implementing "transparent" DNS caching which was not transparent. This breaks any iterative resolvers sitting behinde the "transparent" DNS cache as they are expecting authoritative answers and the answers from the cache are non-authoritative. Iterative resolvers will become more common as people turn on DNSSEC validation and need a DNSSEC aware path and the easiest way to do that is to be a iterative resolver. While I can understand interception of DNS queries prior to signing on there is no justification in continuing to intercept the queries after signing on especially queries with RD=0 as the answers will not be accepted. 2. DHCP offers not being accepted due to the offer have a ttl of 1. Fault in the router. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf