feat(txt-registry): deprecate legacy txt-format #5172
Conversation
Signed-off-by: ivan katliarchuk <[email protected]>
k8s-ci-robot
added
the
do-not-merge/work-in-progress
k8s-ci-robot
added
cncf-cla: yes
Signed-off-by: ivan katliarchuk <[email protected]>
|
/label tide/merge-method-squash |
k8s-ci-robot
added
the
tide/merge-method-squash
|
/kind cleanup |
k8s-ci-robot
added
the
kind/cleanup
Signed-off-by: ivan katliarchuk <[email protected]>
Signed-off-by: ivan katliarchuk <[email protected]>
Signed-off-by: ivan katliarchuk <[email protected]>
Signed-off-by: ivan katliarchuk <[email protected]>
Signed-off-by: ivan katliarchuk <[email protected]>
Signed-off-by: ivan katliarchuk <[email protected]>
ivankatliarchuk
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
Signed-off-by: ivan katliarchuk <[email protected]>
Signed-off-by: ivan katliarchuk <[email protected]>
Signed-off-by: ivan katliarchuk <[email protected]>
Signed-off-by: ivan katliarchuk <[email protected]>
This looks like a bug to me for when custom prefix is specified. At least for APEx it should behave differently. Could you share all you arguments and example setup. Maybe there is a way to write a fix |
|
I agree, the TXT registry has been a bit of a mess for a while now, ever since the new format was introduced to help support managing the same record with multiple record types. It solved that one problem but introduced a number of other compatibility problems for users along with it. In my opinion it should have been removed back then until a proper working solution was found, but instead it's been in a halfway house for years now. I do think the newer registry format works for all use cases, including apex domains, where templating is being used, i.e. for my example above instead of |
|
So how it currently works for Apex domains? I have not found a flag to disable upsert for new format. Does external-dns errors out, crashes, or swallow the error? |
|
Our setup has the below flags: What we see in the case of apex domains is external-dns constantly updating the records no every reconciliation loop: My assumption, and I'm sure I confirmed a while ago, is that external-dns is reconciling everytime because on each check it sees the However, if external-dns begins only caring about |
|
Got it. Will try to find a solution for apex records, before merging this to master /hold |
k8s-ci-robot
added
the
do-not-merge/hold
|
I think the question is, how to reliably |
The way we've handled a similar problem elsewhere (determining the authoritative zone for a domain) is to traverse through the address until an SOA record is returned, e.g. The same logic could be applied; if the record being created resolves an SOA, it's probably an apex domain Though I'm not sure external-dns should be doing this as it'd be a lot of extra lookups and might not be fool proof in all scenarios, especially where split DNS is involved. I do think the better approach is to a) clearly document the downfalls of using |
|
DNS lookups, not sure, on the edge. We all have different networking requirements, network segmentation, what if there is no access to DNS lookups and etc. Maybe we need a new flag And add a flag external-dns/source/service.go Line 546 in ecd57c8 |
|
I suppose even if you could reliably determine a domain is an apex, what would external-dns do to handle the domain differently? You could suffix it with a period Not everyone uses it, but I'm still in favour of consistently handling records, rather than having edge cases for apex domains where external-dns exhibits different behaviour; and to achieve that I personally feel either mandating or clearly warning users about the impacts of using |
|
Got it. I'll submit a patch with documentation update. Yeah, handling apex corretly is not a trivial thing. The dns lookup could happen for example for domain Will update docs and flag description |
|
So, the behaviour you described, could be a source or provider specific, as I was not able to reproduce it for AWS provider. There is an open issue from 2018.... #449 so this are my fixtures, where apex zone is ---
apiVersion: v1
kind: Namespace
metadata:
name: extdns
---
apiVersion: v1
kind: Service
metadata:
name: nginx-v1
namespace: extdns
annotations:
dns.company.com/label: controllertest-v1
dns.issue/type: issue-5172
external-dns.alpha.kubernetes.io/hostname: nginx-v1.ex.com
spec:
type: ClusterIP
clusterIP: None
ports:
- port: 80
name: http
targetPort: 80
selector:
app: nginx
---
apiVersion: v1
kind: Service
metadata:
name: nginx-v2
namespace: extdns
annotations:
dns.company.com/label: controllertest-v2
dns.issue/type: issue-5172
external-dns.alpha.kubernetes.io/ttl: "1m"
external-dns.alpha.kubernetes.io/hostname: nginx-v2.ex.com
spec:
type: LoadBalancer
allocateLoadBalancerNodePorts: true
ports:
- port: 80
name: http
targetPort: 80
selector:
app: nginx
---
apiVersion: v1
kind: Service
metadata:
name: nginx-v3
namespace: extdns
annotations:
dns.company.com/label: controllertest-v2
dns.issue/type: issue-5172
external-dns.alpha.kubernetes.io/ttl: "180"
external-dns.alpha.kubernetes.io/hostname: nginx-v3.ex.com
spec:
type: LoadBalancer
allocateLoadBalancerNodePorts: true
ports:
- port: 80
name: http
targetPort: 80
selector:
app: nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
namespace: extdns
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
ports:
- containerPort: 80
name: httpand arguments for latest external dns go run main.go \
--provider=aws \
--registry=txt \
--source=service \
--aws-zone-type=private \
--zone-id-filter=/hostedzone/${ZONE} \
--log-level=debug \
--policy=sync \
--interval=10s \
--txt-owner-id="current" \
--annotation-filter="dns.issue/type=issue-5172"results and for arguments go run main.go \
--provider=aws \
--registry=txt \
--source=service \
--aws-zone-type=private \
--zone-id-filter=/hostedzone/${ZONE} \
--log-level=debug \
--policy=sync \
--interval=10s \
--txt-owner-id="current" \
--annotation-filter="dns.issue/type=issue-5172" \
--txt-prefix="%{record_type}-prefix-"and results ❯ aws route53 list-resource-record-sets --hosted-zone-id ${ZONE} --query "ResourceRecordSets[?Type=='TXT'].{Name:Name, Value:ResourceRecords[0].Value}" --output table
-----------------------------------------------------------------------------------------------------------------------------------
| ListResourceRecordSets |
+---------------------------+-----------------------------------------------------------------------------------------------------+
| Name | Value |
+---------------------------+-----------------------------------------------------------------------------------------------------+
| a-prefix-nginx-v2.ex.com.| "heritage=external-dns,external-dns/owner=current,external-dns/resource=service/extdns/nginx-v2" |
| a-prefix-nginx-v3.ex.com.| "heritage=external-dns,external-dns/owner=current,external-dns/resource=service/extdns/nginx-v3" |
+---------------------------+-----------------------------------------------------------------------------------------------------+ |
Signed-off-by: ivan katliarchuk <[email protected]>
ivankatliarchuk
force-pushed
the
feat-txt-registry
branch
from
0c4053b to
4faec98
Compare
|
New changes are detected. LGTM label has been removed. |
k8s-ci-robot
removed
the
lgtm
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: ivan katliarchuk <[email protected]>
|
I've updated documentation. In regards
If you ok with following changes, submit LGTM or share what is missing so I could |
Signed-off-by: ivan katliarchuk <[email protected]>
The problem exists when a user is specifying a So when trying to create a record for i.e. tld.co.uk, the old TXT record format creates correctly (TXT myprefix.tld.co.uk), however the new TXT record format (TXT myprefix.a-tld.co.uk) does not, since it's trying to create a record for an entirely different domain. |
|
I just shared my configuration, and there is no problem I discover. Running on latest external-dns. The only different is AWS Route53, not cloudflare. |
|
Have a look #5172 (comment). For apex domain, without even having a prefix, the new TXT record is |
|
I updated the docs. Personally not sure if docs update even need to be required, as not able to reproduce the behaviour in my setup, but no harm to have it there. |
|
@mloiseleur I could be missing something obvious for apex domains. wdyt? |
|
@ivankatliarchuk If you try with |
|
Understood. But this is a configuration that not default, so one could just break things. For example, if prefix contains IDNA character, example What I'm unsure. The expectation is, that by default the TXT records are going to be update, at least they should. There are dozens of combinations that could break any TXT record format, but this should be on users. Would you mind share your desired message in documentation, or even create a pull request with examples and mitigations. This could help for sure to progress with this PR as well. |
|
The README already contains this:
I would suggest adding something like the below?
|
Signed-off-by: ivan katliarchuk <[email protected]>
|
Nice one. Added to |
Description
TODO:
Checklist
Executed on real cluster with arguments
go run main.go \ --provider=aws \ --registry=txt \ --source=fake \ --aws-zone-type=private \ --zone-id-filter=/hostedzone/XXXXXX \ --log-level=debug \ --policy=sync \ --interval=60s \ --fqdn-template=a1.ex.comWithout change, records current and old format created
With the change. New format records created, letagcy TXT records left untouched