[dns-operations] Also any Microsoft CDN people here?
Gavin McCullagh
gmccullagh at gmail.com
Thu Nov 27 15:37:22 UTC 2025
Hi Ondrey,
I think it's evident that these DNS servers are likely not e.g. BIND but I
don't quite understand why we'd say the behavior is "invalid".
The DNS protocol, as I understand it, accepts that zone files may change at
any moment and caches will catch up as ttls expire. That the zone file
changed between the queries you made would explain your observations,
right? One would have to get very lucky, but I think you could see the
same output when querying a BIND nameserver.
It appears these vendors have both created a DNS server that modifies the
contents of zones, in real time, as each query arrives. The authoritative
zone is changing each nanosecond in response to queries.
If you want to call this "stupid DNS tricks", feel free. But I don't
understand why it is illegal or "invalid" to create, modify or delete
cnames in response to events. Every DNS server does this for some
definition of "event" so a resolver cannot expect consistency between
successive query responses.
A resolver may cache the cname's existence (or non-existence) of course.
But as long as the authorities accept that caching will happen and allow
for it, why is there a problem? I think it's safe to assume they don't
update the soa serial or propagate every change via axfr, but that seems to
be the authority's concern.
If we look hard enough, my employer's DNS service can be configured to
change the values of cnames in response to queries (though I don't think
they disappear ever). This does not seem fundamentally different.
Is it causing some issue for resolvers?
Gavin
On Thu, Nov 27, 2025, 3:51 AM Ondřej Surý <ondrej at sury.org> wrote:
> Same invalid CNAME behavior can be observed at msedge.net:
>
> ; <<>> DiG 9.21.14 <<>> +norec -t A l-ring.msedge.net. @ns1.msedge.net.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19903
> ;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1224
> ;; QUESTION SECTION:
> ;l-ring.msedge.net. IN A
>
> ;; ANSWER SECTION:
> l-ring.msedge.net. 60 IN CNAME l-ring.l-9999.l-msedge.net
> .
> l-ring.l-9999.l-msedge.net. 240 IN CNAME l-9999.l-msedge.net.
> l-9999.l-msedge.net. 240 IN A 13.107.42.254
>
> ;; Query time: 14 msec
> ;; SERVER: 204.79.197.1#53(ns1.msedge.net.) (UDP)
> ;; WHEN: Thu Nov 27 12:38:48 CET 2025
> ;; MSG SIZE rcvd: 113
>
> but
>
> ; <<>> DiG 9.21.14 <<>> +norec -t HTTPS l-ring.msedge.net. @ns1.msedge.net
> .
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6454
> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1224
> ;; QUESTION SECTION:
> ;l-ring.msedge.net. IN HTTPS
>
> ;; AUTHORITY SECTION:
> msedge.net. 900 IN SOA ns1.msedge.net.
> msnhst.microsoft.com. 2016041201 1800 900 2419200 3600
>
> ;; Query time: 14 msec
> ;; SERVER: 204.79.197.1#53(ns1.msedge.net.) (UDP)
> ;; WHEN: Thu Nov 27 12:38:57 CET 2025
> ;; MSG SIZE rcvd: 106
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ondrej at sury.org
>
> > On 27. 11. 2025, at 12:34, Ondřej Surý <ondrej at sury.org> wrote:
> >
> > Hey Joe,
> >
> > found another case of CNAME weirdness.
> >
> > CNAME returned for A query (or NS or any other type that exists at the
> target of the CNAME):
> >
> > ; <<>> DiG 9.21.14 <<>> +norec in A www.berlin-city-tour.de. @
> lina.ns.cloudflare.com.
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1239
> > ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 1232
> > ;; QUESTION SECTION:
> > ;www.berlin-city-tour.de. IN A
> >
> > ;; ANSWER SECTION:
> > www.berlin-city-tour.de. 60 IN CNAME berlin-city-tour.de.
> > berlin-city-tour.de. 300 IN A 167.71.36.225
> >
> > ;; Query time: 17 msec
> > ;; SERVER: 2606:4700:50::adf5:3abb#53(lina.ns.cloudflare.com.) (UDP)
> > ;; WHEN: Thu Nov 27 12:27:02 CET 2025
> > ;; MSG SIZE rcvd: 82
> >
> > CNAME not returned for NODATA answer:
> >
> > ; <<>> DiG 9.21.14 <<>> +norec in AAAA www.berlin-city-tour.de. @
> lina.ns.cloudflare.com.
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42854
> > ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 1232
> > ;; QUESTION SECTION:
> > ;www.berlin-city-tour.de. IN AAAA
> >
> > ;; AUTHORITY SECTION:
> > berlin-city-tour.de. 1800 IN SOA amit.ns.cloudflare.com.
> dns.cloudflare.com. 2389579513 10000 2400 604800 1800
> >
> > ;; Query time: 17 msec
> > ;; SERVER: 2606:4700:50::adf5:3abb#53(lina.ns.cloudflare.com.) (UDP)
> > ;; WHEN: Thu Nov 27 12:27:33 CET 2025
> > ;; MSG SIZE rcvd: 114
> >
> > I believe the CNAME has to be returned regardless of the target
> existence.
> >
> > Cheers,
> > Ondrej
> > --
> > Ondřej Surý (He/Him)
> > ondrej at sury.org
> >
>
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20251127/ecaba4a5/attachment-0001.html>
More information about the dns-operations
mailing list