In message <e041a687-5597-4d5b-ae07-8e1cd98f3...@cs.columbia.edu>, 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@ietf.org
> 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_andr...@isc.org
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
