On Apr 8 2019, Matthew Pounsett wrote, in another thread:
RFC2606 reserves test, example, invalid, and localhost, for "testing
and documentation," which seems to fit this use-case. 'invalid'
doesn't seem to me to be intended for use as a generic private TLD
though, as was suggested up-thread.
This reminded me of one use I did make of "invalid". The IPv4 addresses
192.153.213.[249-251] were reserved for a web probing service for which
it was desired to make them appear not to be on the university network
(although they were) to see whether the web sites responded differently
in that case. Partly this was done by using an unusual /24, but also by
supressing DNS entries for them.
Originally this was done by tagging them in the database with a "visibility"
option that supressed inclusion of both forward and reverse entries in
the DNS. I was quite keen to get rid of this option, which messed up the
database semantics in other ways, and they were the only remaining cases
of its use.
So instead I attached them to a database object with a name under "invalid".
Reverse lookup on the IPv4 addresses then gave that name (indeed, it still
does). That still made them appear to be "not in cam.ac.uk", and forward
lookup on the name would be guaranteed to give NXDOMAIN. Well, unless
we ever generated a forward zone for "invalid" from the database, which
obviously was not going to happen...
I still think this was a reasonable use of "invalid", and consistent with
the remarks in section 6.4 of RFC 6761 (also dating from 2013, incidentally).
--
Chris Thompson
Email: c...@cam.ac.uk
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
