> On Oct 8, 2019, at 09:48 , Michel Py <michel...@tsisemi.com> wrote:
>
>> Owen DeLong wrote :
>> I’m not sure how giving them DNS names makes them less resilient to DNS
>> failures.
>
> How do you resolve the IP address of the PBX ? I hard-code (in the master
> config).
Usually, i have sufficiently resilient DNS that I use it. If I’m in an
environment where hard-coding is
required, I generally have software that is building the config file rather
than doing it by hand. The
config generation software can depend on DNS, even if the phone may not be able
to in all runtimes.
> The PBX does not have a DNS name. I want my support staff to know its IP on
> the top of their head.
Then make it something easy like prefix::5 and move on. Even if you’ve got a
/48 like 2620:5af2:3ace::/48,
you can use the first prefix for your PBX and then it’s just
2620:5af2:3ace::5/64.
While that’s a little worse than IPv4 for remembering the prefix (3 4-digit
numbers instead of 3 3-digit numbers),
that prefix will be readily visible on any device that’s able to utilize the
same network, so it’s not hard to look
up and it’ s only 3 extra digits of typing and 1 extra separator mark.
> DNS failures do not happen often, but they do happen. Fat fingers change or
> delete the entry, the zone gets corrupted or partially corrupted, that kind
> of stuff.
If you’re pushing DNS edit -> Production, I suppose that’s true. If it matters
that much, I usually have Edit->Staging->validation scripts->production.
If the staging environment can’t resolve the critical infrastructure items
(such as PBX), then it doesn’t change production.
> There are things that redundant hardware and network will not solve. If the
> PBX address becomes unresolvable, the SIP registrations will timeout and I'm
> going to lose phones.
Sure, but it should have a very long TTL and shouldn’t become unresolvable in
less time than it takes you to identify and solve the DNS problem.
> Granted, it would not take that much time to troubleshoot, but just the
> possibility, not matter how remote, that it could happen makes it a
> non-option.
In which case, I’d definitely set up validation before shipping on my DNS
updates.
> If DHCP fails, I have a 169.254 secondary address. It may not be elegant, but
> it is resilient.
Uh, only if the PBX is on the same segment as every phone. (does not scale
unless you buy a PBX for each phone segment).
And the fe80:: alternative is SO MUCH more elegant than 169.254…
Just sayin’
Owen
