Logic behind lib/krb5/os/k5_sendto()

[Greg Hudson]

On 4/15/19 5:48 PM, Дилян Палаузов wrote:
> kinit x at expamle.org is called and in dns the SRV records _kerberos._udp.example.org and _kerberos._tcp.example.org show
> that k.example.org:88 is in charge.  But the KDC there is in fact in charge of EXAMPLE.ORG, example.org being non-local
> realm.
> 
> • If k5_sendto receives an answer from a KDC, that the realm is non-local, does it retry to the other KDCs, here asking
> the same process over a different transport protocol?

If example.org issues a client referral (KDC_ERR_WRONG_REALM) to
EXAMPLE.ORG, k5_sendto() will return the error response, and the
higher-level logic will (if canonicalization is enabled) retry with
EXAMPLE.ORG, which will contact the same KDC.

> When is the timeout (interval) increased from 1s to to 2s?  If there is no answer within 1s, then the query is resent,
> waiting for 2 more seconds?

If there is a single KDC with both UDP and TCP transports, the normal
schedule is:

1. Send UDP request, wait one second
2. Begin TCP connection, wait one second
3. Wait two seconds
4. Send UDP request, wait one second
5. Wait four seconds
6. Send UDP request, wait one second
7. Wait eight seconds
8. Send UDP request, wait one second
9. Wait sixteen seconds
10. Give up

If there are multiple KDCs, the steps to send UDP requests or begin TCP
connections are iterated over each KDC, with a one-second wait after each.