In my setups I link Asterisk with the unbound libs such that I have more control about name resolution (if necessary). Normally, I let the lib scan /etc/resolv.conf, which basically results in whatever the system provides. I’ve seen setups on ip-phoneforum.de where a local dns server with a fake domain was used for that. I don’t think that this is necessary and it is more straightforward to use the names of the servers as provided by the SRV records. One only needs to explicitly set the outbound proxy.
That said, I cannot confirm your observations, but as I mentioned the dns pattern for ALL-IP is different than for the SIP-TRUNK. It seems that there are some regional differences, though. I have a customer in Prussian Sibera who has never complained and he has an “unpatched” configuration. Either you observe more systematically, or add an identify section to your SIP configuration with something like:
It’s probably not really needed, as the line parameter is more important. The side effect is that after about a day you can list the endpoint and see what Asterisk has found for tel.t-online.de. In my case I currently have:
> pjsip show endpoint ...
The starting point for this discussion was a few years ago when PJSIP was introduced and some other things changed. If you look at the Asterisk code, then I would say that the DNS resolution remains transparent for various modules, regardless of whether an A record is resolved directly or recursively via NAPTR/SRV requests. Ultimately, the SIP code has no idea what the structures look like in between. You enter a symbolic address at the top, the the registration process gets a single IP at the bottom.
If you don’t do that, you have to drag along the registration IP for every registration and signal whether you want to use it. Much more code needs to know about the DNS internals. If a change is pending, you also have to check whether the associated endpoint is currently active. Basically, you have to check before every INVITE and every OPTION request whether something has just changed (although you can do without qualifying the accounts with the Telekom servers). That would be more than ugly.
There are some people at Telekom who know their way around. Years ago I complained to their business customer hotline, but initially nobody knew what I was talking about. Later I received a call from Hamburg, and this technician was able to understand everything after a bit of back and forth, but also said in a general sense that nothing could be changed so quickly with a mass product.
Again, it works, but as long as the Telekom servers do not check the authentication data centrally, the system, which is actually designed for redundancy and failure safety, is not really fully used - in my opinion. Some parts of the 1TR114 seem to have forgotten that SIP is a stateful protocol.