On Thu, Jun 21, 2018 at 09:41:43PM +0100, Jonathan Matthews wrote: > On Thu, 21 Jun 2018 at 19:45, Willy Tarreau <[email protected]> wrote: > > > Oh indeed I didn't even notice! The correct solution is to use the > > example.com domain for this, as explained in RFC2606/6761. No other > > domain possibly pointing to a valid location now or in the future > > should appear in test nor example files > > > [Gmail on mobile; forgive any formatting fubar] > > Example\.com resolves. There's a "you can use this domain in documentation" > site there.
In fact it depends where : $ host example.com example.com has address 127.0.0.1 $ host example.com 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: example.com has address 93.184.216.34 example.com has IPv6 address 2606:2800:220:1:248:1893:25c8:1946 > *Someone* is absorbing the traffic to that domain - I suggest > not putting it in .vtc files :-) It's hosted by IANA. But it's made exactly for this purpose in fact, because you know that people copy-pasting examples in documentation do whatever with them and sometimes even forget to replace certain lines. > I think the same RFC reserves .invalid as a TLD. Perhaps > missing.haproxy.invalid for when a DNS entry needs not to exist, and ... > something else for when it needs a real backend? I'm out of ideas on that > 2nd use case ... I'd suggest to indeed use .invalid when we really want a name to always fail to resolve, and example.com when we'd prefer it to resolve though we don't care if any service works or not. All other cases where you need a working service have to be provided with the embedded server in vtc and must not rely on any external service. Also that reminds me that if we have to provide example addresses for servers, there's a 192.2 network for this purpose which is listed in RFCs as well and that we should use instead of anything else. Cheers, Willy
