In message
<E041A687-5597-4D5B-AE07-8E1CD98F3225(_at_)cs(_dot_)columbia(_dot_)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(_at_)ietf(_dot_)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_Andrews(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf