AWS DNS services break query name minimisation (DNS privacy) Posted by: rijswijk Posted on: Dec 9, 2017 5:34 AM Reply



Short summary



As requested via Twitter, I'm submitting a description of problems with AWS's DNS service for DNS resolvers that have enabled query name minimisation (RFC 7816,



As a result of the way AWS's DNS service responds to queries for certain names, domains hosted in AWS's DNS become unresolvable for DNS resolvers that have QNAME minimisation enabled.



Essentially, the cause of the issue is that AWS authoritative DNS servers incorrectly return an NXDOMAIN response to queries for empty non-terminal domains (domain names that contain multiple labels within a single DNS zone). Instead, they should return a NODATA response, which will allow resolvers that have enabled QNAME minimisation will correctly resolve these names.



Edit: in the particular example I use below, there may also be another issue at play, which is that there is a delegation missing in one of the intermediate zones (in particular, the delegation from ws.fdmg.org to prod.ws.fdmg.org may be missing in the ws.fdmg.org zone if it exists). It is hard to tell from the outside whether this is the case, or whether it is AWS's broken empty non-terminal behaviour that's causing the problems. For more info, also see this thread:



Detailed Description and Example



Query name minimisation (RFC 7816) is an improvement to the DNS lookup process that enhances privacy protection for users of DNS resolvers. In a 'classic' lookup, a DNS resolver will always send the full query name and type to authoritative name servers as it is performing a recursion from the root zone of the DNS down through the TLD and on to the authoritative name servers for a domain. This exposes the full query name to all levels in the DNS hierarchy and leaks information about the query to parties that do not need to have any knowledge of the full query name to aid in resolving the query.



AWS's authoritative DNS servers have an implementation error that prevents DNS resolvers that have QNAME minimisation enabled from resolving domain names that consists of multiple labels that exist within a single zone. I will illustrate this with a concrete example, for which I have observed lookup problems.



Consider the domain name "api.prod.ws.fdmg.org". This name consists of six DNS labels ("api", "prod", "ws", "fdmg", "org", and the root label). I will demonstrate what happens with a lookup for this name using a 'classic' lookup process (which succeeds) and using QNAME minimisation (which fails). The demonstration utilises the commonly used "dig" DNS lookup tool and shows its output (redacted where necessary to keep the text readable).



Classic lookup



First, the classic lookup. This starts with a query for the A record for "api.prod.ws.fdmg.org" to one of the root name servers:



$ dig +norecurse A api.prod.ws.fdmg.org @a.root-servers.net

... (removed)

;; AUTHORITY SECTION:

org. 172800 IN NS d0.org.afilias-nst.org.

org. 172800 IN NS a0.org.afilias-nst.info.

org. 172800 IN NS c0.org.afilias-nst.info.

org. 172800 IN NS a2.org.afilias-nst.info.

org. 172800 IN NS b0.org.afilias-nst.org.

org. 172800 IN NS b2.org.afilias-nst.org.



As you can see, this returns a referral to the .org name servers, so the next thing the resolver will do is repeat the same A query, but then send it to one of the .org name servers:



$ dig +norecurse A api.prod.ws.fdmg.org @a0.org.afilias-nst.info.

... (removed)

;; AUTHORITY SECTION:

fdmg.org. 86400 IN NS ns-677.awsdns-20.net.

fdmg.org. 86400 IN NS ns-372.awsdns-46.com.

fdmg.org. 86400 IN NS ns-1089.awsdns-08.org.

fdmg.org. 86400 IN NS ns-1928.awsdns-49.co.uk.



As you can see, this once again leads to a referral to the AWS authoritative name servers that are authoritative for the "fdmg.org" domain.



Now, the resolver will once again send the A query for "api.prod.ws.fdmg.org" to one of these AWS servers:



$ dig +norecurse A api.prod.ws.fdmg.org @ns-677.awsdns-20.net.

... (removed)

;; AUTHORITY SECTION:

prod.ws.fdmg.org. 300 IN NS ns-1206.awsdns-22.org.

prod.ws.fdmg.org. 300 IN NS ns-1844.awsdns-38.co.uk.

prod.ws.fdmg.org. 300 IN NS ns-320.awsdns-40.com.

prod.ws.fdmg.org. 300 IN NS ns-903.awsdns-48.net.



As you can see, this once again leads to a referral to AWS name servers for "prod.ws.fdmg.org". But note that the intermediate ws.fdmg.org is a so-called empty non-terminal, that is: there appear to be records for "prod.ws" directly in the "fdmg.org" DNS zone. As we will see further down with the QNAME minimisation lookup, this is where things go wrong when QNAME minimisation is turned on.



In the 'classic' lookup, the final step the resolver takes is to do the A lookup for "api.prod.ws.fdmg.org" once again, but now to one of the servers that is authoritative for "prod.ws.fdmg.org":



$ dig +norecurse A api.prod.ws.fdmg.org @ns-1206.awsdns-22.org.

... (removed)

;; ANSWER SECTION:

api.prod.ws.fdmg.org. 300 IN A 52.212.193.89

api.prod.ws.fdmg.org. 300 IN A 52.212.16.17

api.prod.ws.fdmg.org. 300 IN A 52.213.71.54



And as we can see, this leads to a successful response to the query.



With QNAME minimisation turned on



Now let's look at the way a resolver that implements QNAME minimisation does this recursion. I'm using the way that the Unbound DNS resolver implements this



To perform a lookup of "api.prod.ws.fdmg.org", the resolver will start with a query to a root name server to perform a lookup of an A record for "org."



$ dig +norecurse A org. @a.root-servers.net

... (removed)

;; AUTHORITY SECTION:

org. 172800 IN NS d0.org.afilias-nst.org.

org. 172800 IN NS a0.org.afilias-nst.info.

org. 172800 IN NS c0.org.afilias-nst.info.

org. 172800 IN NS a2.org.afilias-nst.info.

org. 172800 IN NS b0.org.afilias-nst.org.

org. 172800 IN NS b2.org.afilias-nst.org.



As you can see, this leads to a referral to .org authoritative servers (exactly the same as in the 'classic' approach discussed above).



The next step is that the resolvers sends an A query for "fdmg.org" to one of the .org authoritative servers:



$ dig +norecurse A fdmg.org. @a0.org.afilias-nst.info.

... (removed)

;; AUTHORITY SECTION:

fdmg.org. 86400 IN NS ns-677.awsdns-20.net.

fdmg.org. 86400 IN NS ns-1089.awsdns-08.org.

fdmg.org. 86400 IN NS ns-1928.awsdns-49.co.uk.

fdmg.org. 86400 IN NS ns-372.awsdns-46.com.



Again, this returns a referral, same as in the 'classic' lookup to the AWS servers that are authoritative for fdmg.org.



Then, the resolver will send an A query for "ws.fdmg.org" to one of these AWS servers:



$ dig +norecurse A ws.fdmg.org. @ns-677.awsdns-20.net.

... (removed)

;; AUTHORITY SECTION:

ws.fdmg.org. 300 IN NS ns-1372.awsdns-43.org.

ws.fdmg.org. 300 IN NS ns-1561.awsdns-03.co.uk.

ws.fdmg.org. 300 IN NS ns-343.awsdns-42.com.

ws.fdmg.org. 300 IN NS ns-941.awsdns-53.net.



As you can see, this returns a referral, and this is where things start going wrong. As you may recall from above, an A query for the full name to the AWS servers returns referral to prod.ws.fdmg.org, but here, a query for ws.fdmg.org returns a referral to that name, suggesting that there is actually a zone cut and delegation for ws.fdmg.org.



To make matters worse, if the resolver would use the default QNAME minimisation algorithm from the RFC and had issued an NS query for ws.fdmg.org...

Other text removed



(Comment on the strikethrough text: as discussed in this thread https://news.ycombinator.com/item?id=15893103 I made a mistake here; I should have asked one of the authoritative name servers in the referral for the NS record set for ws.fdmg.org, as the NS records will be in the child zone. These do actually respond to that particular query, which does not matter for the problem at hand, because they still return NXDOMAIN to a query for prod.ws.fdmg.org).



So let's go back to the recursion. Recall that we got a referral to AWS servers for ws.fdmg.org on the original A query for ws.fdmg.org to the AWS name servers for fdmg.org. The next thing the resolver will do is issue an A query for "prod.ws.fdmg.org" to these AWS servers:



$ dig +norecurse A prod.ws.fdmg.org @ns-1372.awsdns-43.org.



; <<>> DiG 9.9.7-P3 <<>> +norecurse A prod.ws.fdmg.org @ns-1372.awsdns-43.org.

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51491

;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1



;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;prod.ws.fdmg.org. IN A



;; AUTHORITY SECTION:

ws.fdmg.org. 900 IN SOA ns-1372.awsdns-43.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400



And this is where the resolution process will stop and return an NXDOMAIN to the original client.



Solving this problem



The solution for this problem is to properly implement delegations and NODATA responses to empty non-terminals. Under the assumption that in the example above, ws.fdmg.org is an empty non-terminal (that is: the label "ws" is only used as part of compound names that also have another label in them, such as "prod.ws"), the A query for "ws.fdmg.org" should return a NODATA response, that is: a response with RCODE NOERROR, an empty answer section and an SOA record in the authority section. If a resolver that implements QNAME minimisation encounters this, it will issue another A query for "prod.ws.fdmg.org". I illustrate this below:



$ dig +norecurse A prod.ws.fdmg.org @ns-677.awsdns-20.net.

... (removed)

;; AUTHORITY SECTION:

prod.ws.fdmg.org. 300 IN NS ns-1206.awsdns-22.org.

prod.ws.fdmg.org. 300 IN NS ns-1844.awsdns-38.co.uk.

prod.ws.fdmg.org. 300 IN NS ns-320.awsdns-40.com.

prod.ws.fdmg.org. 300 IN NS ns-903.awsdns-48.net.



As you can see, this returns a referral to AWS name servers. The next thing the resolver will do is issue an A query for "api.prod.ws.fdmg.org" to one of these as shown below:



$ dig +norecurse A api.prod.ws.fdmg.org @ns-1206.awsdns-22.org

... (removed)

;; ANSWER SECTION:

api.prod.ws.fdmg.org. 300 IN A 52.213.71.54

api.prod.ws.fdmg.org. 300 IN A 52.212.193.89

api.prod.ws.fdmg.org. 300 IN A 52.212.16.17



Which as you can see results in the correct response and a successful resolution of the query.



More reading



Shumon Huque has written an excellent summary of all sorts of implementation problems in authoritative name servers (mainly from CDN operators) that break DNS resolution if QNAME minimisation is used. It can be found here:



Contact



If you have any questions regarding the above, please do not hesitate to contact me.



Edited by: rijswijk on Dec 11, 2017 8:44 AM



Edited by: rijswijk on Dec 11, 2017 9:20 AM Dear AWS folks,As requested via Twitter, I'm submitting a description of problems with AWS's DNS service for DNS resolvers that have enabled query name minimisation (RFC 7816, https://tools.ietf.org/html/rfc7816 ).As a result of the way AWS's DNS service responds to queries for certain names, domains hosted in AWS's DNS become unresolvable for DNS resolvers that have QNAME minimisation enabled.Essentially, the cause of the issue is that AWS authoritative DNS servers incorrectly return an NXDOMAIN response to queries for empty non-terminal domains (domain names that contain multiple labels within a single DNS zone). Instead, they should return a NODATA response, which will allow resolvers that have enabled QNAME minimisation will correctly resolve these names.in the particular example I use below, there may also be another issue at play, which is that there is a delegation missing in one of the intermediate zones (in particular, the delegation from ws.fdmg.org to prod.ws.fdmg.org may be missing in the ws.fdmg.org zone if it exists). It is hard to tell from the outside whether this is the case, or whether it is AWS's broken empty non-terminal behaviour that's causing the problems. For more info, also see this thread: https://news.ycombinator.com/item?id=15893103 Query name minimisation (RFC 7816) is an improvement to the DNS lookup process that enhances privacy protection for users of DNS resolvers. In a 'classic' lookup, a DNS resolver will always send the full query name and type to authoritative name servers as it is performing a recursion from the root zone of the DNS down through the TLD and on to the authoritative name servers for a domain. This exposes the full query name to all levels in the DNS hierarchy and leaks information about the query to parties that do not need to have any knowledge of the full query name to aid in resolving the query.AWS's authoritative DNS servers have an implementation error that prevents DNS resolvers that have QNAME minimisation enabled from resolving domain names that consists of multiple labels that exist within a single zone. I will illustrate this with a concrete example, for which I have observed lookup problems.Consider the domain name "api.prod.ws.fdmg.org". This name consists of six DNS labels ("api", "prod", "ws", "fdmg", "org", and the root label). I will demonstrate what happens with a lookup for this name using a 'classic' lookup process (which succeeds) and using QNAME minimisation (which fails). The demonstration utilises the commonly used "dig" DNS lookup tool and shows its output (redacted where necessary to keep the text readable).First, the classic lookup. This starts with a query for the A record for "api.prod.ws.fdmg.org" to one of the root name servers:$ dig +norecurse A api.prod.ws.fdmg.org @a.root-servers.net... (removed);; AUTHORITY SECTION:org. 172800 IN NS d0.org.afilias-nst.org.org. 172800 IN NS a0.org.afilias-nst.info.org. 172800 IN NS c0.org.afilias-nst.info.org. 172800 IN NS a2.org.afilias-nst.info.org. 172800 IN NS b0.org.afilias-nst.org.org. 172800 IN NS b2.org.afilias-nst.org.As you can see, this returns a referral to the .org name servers, so the next thing the resolver will do is repeat the same A query, but then send it to one of the .org name servers:$ dig +norecurse A api.prod.ws.fdmg.org @a0.org.afilias-nst.info.... (removed);; AUTHORITY SECTION:fdmg.org. 86400 IN NS ns-677.awsdns-20.net.fdmg.org. 86400 IN NS ns-372.awsdns-46.com.fdmg.org. 86400 IN NS ns-1089.awsdns-08.org.fdmg.org. 86400 IN NS ns-1928.awsdns-49.co.uk.As you can see, this once again leads to a referral to the AWS authoritative name servers that are authoritative for the "fdmg.org" domain.Now, the resolver will once again send the A query for "api.prod.ws.fdmg.org" to one of these AWS servers:$ dig +norecurse A api.prod.ws.fdmg.org @ns-677.awsdns-20.net.... (removed);; AUTHORITY SECTION:prod.ws.fdmg.org. 300 IN NS ns-1206.awsdns-22.org.prod.ws.fdmg.org. 300 IN NS ns-1844.awsdns-38.co.uk.prod.ws.fdmg.org. 300 IN NS ns-320.awsdns-40.com.prod.ws.fdmg.org. 300 IN NS ns-903.awsdns-48.net.As you can see, this once again leads to a referral to AWS name servers for "prod.ws.fdmg.org". But, that is: there appear to be records for "prod.ws" directly in the "fdmg.org" DNS zone. As we will see further down with the QNAME minimisation lookup, this is where things go wrong when QNAME minimisation is turned on.In the 'classic' lookup, the final step the resolver takes is to do the A lookup for "api.prod.ws.fdmg.org" once again, but now to one of the servers that is authoritative for "prod.ws.fdmg.org":$ dig +norecurse A api.prod.ws.fdmg.org @ns-1206.awsdns-22.org.... (removed);; ANSWER SECTION:api.prod.ws.fdmg.org. 300 IN A 52.212.193.89api.prod.ws.fdmg.org. 300 IN A 52.212.16.17api.prod.ws.fdmg.org. 300 IN A 52.213.71.54And as we can see, this leads to a successful response to the query.Now let's look at the way a resolver that implements QNAME minimisation does this recursion. I'm using the way that the Unbound DNS resolver implements this https://unbound.net/ . Unbound starts using A record queries at all stages. The default algorithm suggested in RFC 7816 is to use NS queries, but since many DNS implementations used at CDNs sometimes erroneously respond to such queries (in fact, AWS DNS also gets this wrong), Unbound uses A queries as a safer approach. It will only switch to NS queries if necessary (which in the lookup illustrated below isn't necessary and doesn't happen).To perform a lookup of "api.prod.ws.fdmg.org", the resolver will start with a query to a root name server to perform a lookup of an A record for "org."$ dig +norecurse A org. @a.root-servers.net... (removed);; AUTHORITY SECTION:org. 172800 IN NS d0.org.afilias-nst.org.org. 172800 IN NS a0.org.afilias-nst.info.org. 172800 IN NS c0.org.afilias-nst.info.org. 172800 IN NS a2.org.afilias-nst.info.org. 172800 IN NS b0.org.afilias-nst.org.org. 172800 IN NS b2.org.afilias-nst.org.As you can see, this leads to a referral to .org authoritative servers (exactly the same as in the 'classic' approach discussed above).The next step is that the resolvers sends an A query for "fdmg.org" to one of the .org authoritative servers:$ dig +norecurse A fdmg.org. @a0.org.afilias-nst.info.... (removed);; AUTHORITY SECTION:fdmg.org. 86400 IN NS ns-677.awsdns-20.net.fdmg.org. 86400 IN NS ns-1089.awsdns-08.org.fdmg.org. 86400 IN NS ns-1928.awsdns-49.co.uk.fdmg.org. 86400 IN NS ns-372.awsdns-46.com.Again, this returns a referral, same as in the 'classic' lookup to the AWS servers that are authoritative for fdmg.org.Then, the resolver will send an A query for "ws.fdmg.org" to one of these AWS servers:$ dig +norecurse A ws.fdmg.org. @ns-677.awsdns-20.net.... (removed);; AUTHORITY SECTION:ws.fdmg.org. 300 IN NS ns-1372.awsdns-43.org.ws.fdmg.org. 300 IN NS ns-1561.awsdns-03.co.uk.ws.fdmg.org. 300 IN NS ns-343.awsdns-42.com.ws.fdmg.org. 300 IN NS ns-941.awsdns-53.net.As you can see, this returns a referral, and this is where things start going wrong. As you may recall from above, an A query for the full name to the AWS servers returns referral to prod.ws.fdmg.org, but here, a query for ws.fdmg.org returns a referral to that name, suggesting that there is actually a zone cut and delegation for ws.fdmg.org.So let's go back to the recursion. Recall that we got a referral to AWS servers for ws.fdmg.org on the original A query for ws.fdmg.org to the AWS name servers for fdmg.org. The next thing the resolver will do is issue an A query for "prod.ws.fdmg.org" to these AWS servers:$ dig +norecurse A prod.ws.fdmg.org @ns-1372.awsdns-43.org.; <<>> DiG 9.9.7-P3 <<>> +norecurse A prod.ws.fdmg.org @ns-1372.awsdns-43.org.;; global options: +cmd;; Got answer:;; ->>HEADER<https://indico.dns-oarc.net/event/21/contribution/9/material/slides/0.pdf If you have any questions regarding the above, please do not hesitate to contact me.Edited by: rijswijk on Dec 11, 2017 8:44 AMEdited by: rijswijk on Dec 11, 2017 9:20 AM Replies: 8 | Pages: 1 - Last Post: Oct 10, 2019 4:11 AM by: mnordhoff Replies Re: AWS DNS services break query name minimisation (DNS privacy) Posted by: rijswijk Posted on: Dec 11, 2017 9:33 AM in response to: rijswijk Reply



As an example we take the sslmate.com domain and one of it's authoritative name servers from Route 53. We ask it for an empty non-terminal (a DKIM label):



$ dig +norecurse TXT _domainkey.sslmate.com @ns-500.awsdns-62.com.



; <<>> DiG 9.9.7-P3 <<>> +norecurse TXT _domainkey.sslmate.com @ns-500.awsdns-62.com.

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55996

;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1



;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;_domainkey.sslmate.com. IN TXT



;; AUTHORITY SECTION:

sslmate.com. 900 IN SOA ns-1351.awsdns-40.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400



This seems to suggest that _domainkey.sslmate.com does not exist, but it is actually an empty non-terminal, as demonstrated by this query:



$ dig +norecurse TXT opsmate0._domainkey.sslmate.com @ns-500.awsdns-62.com.

... (removed)

;; ANSWER SECTION:

opsmate0._domainkey.sslmate.com. 7200 IN TXT "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzOJeabYXKJ1T+P1lnwwvRX320px2enfr9Fqp+UJdP1baQVUzBPK/EdGAFW47R5XOYsLBvzhN/huOfVW6eLH2qpwCrpgL6n9RXS2AJkuAVHzgFhcXquzWGdF/xbJN7I335Nh5vk1uZhJkeeXQbrqyWT4c" "SU8BrtlY2/PStctJ5X3NcyXB3chmy7/WKFm3mWxqR1wSFH8/9M3tO/FU5/38V8K5reKAyKUBpOGUbDCJN5mZsaGU8mhJSn4wsGAbKui9QTju2PVYttoAqONsQHo6sqpdYWxqHMtm8nCsSIyjcEVPe6Rr+feo+S7xvCaouu5WWXyUnce84UvWxUUhGB5zwQIDAQAB"



The response to the first query is mostly correct, but the RCODE must be NOERROR (indicating a NODATA response), rather than NXDOMAIN, because _domainkey.sslmate.com is an empty non-terminal.



Edited by: rijswijk on Dec 11, 2017 9:34 AM



Edited by: rijswijk on Dec 11, 2017 10:26 AM And to make this summary complete, here is a demonstration of Route 53's broken empty non-terminal behaviour (with thanks to @__agwa and this thread https://news.ycombinator.com/item?id=15893103 ):As an example we take the sslmate.com domain and one of it's authoritative name servers from Route 53. We ask it for an empty non-terminal (a DKIM label):$ dig +norecurse TXT _domainkey.sslmate.com @ns-500.awsdns-62.com.; <<>> DiG 9.9.7-P3 <<>> +norecurse TXT _domainkey.sslmate.com @ns-500.awsdns-62.com.;; global options: +cmd;; Got answer:;; ->>HEADER< Re: AWS DNS services break query name minimisation (DNS privacy) Posted by: pspacek Posted on: Dec 12, 2017 1:36 AM in response to: rijswijk Reply I independently confirm that this behavior is causing problems with standard-compliant implementations of DNS resolvers, e.g. with Knot Resolver version 1.5.0.



Petr Špaček @ CZ.NIC Re: AWS DNS services break query name minimisation (DNS privacy) Posted by: rijswijk Posted on: Dec 12, 2017 4:56 AM in response to: rijswijk Reply Update on earlier example



I have been in touch with the administrators for the fdmg.org domain, and they have confirmed that the problem with that domain was caused by a missing delegation. Therefore, please do not use that domain as a test for this issue.



My post from yesterday that uses opsmate0._domainkey.sslmate.com as an example should be used instead, as that is a confirmed case of an existing empty non-terminal that is not handled in a standards compliant way by Route 53 (viz. RFC 8020). Re: AWS DNS services break query name minimisation (DNS privacy) mattm@AWS Posted by: Posted on: Dec 12, 2017 11:28 AM in response to: rijswijk Reply Thank you for the detailed reproduction and explanation. As you can see in the Hacker News thread you linked to, this is a complicated issue.



Route 53 unfortunately can not simply fix the non-compliant responses to empty non-terminal queries. This is a breaking change, and we have customers that depend on the existing behavior. We are looking into the issue, but as a product development decision, not a bug fix.



Your feedback is valuable. Please continue to report use cases that are impacted by the non-compliant behavior. Re: AWS DNS services break query name minimisation (DNS privacy) mnordhoff Posted by: Posted on: Dec 12, 2017 9:18 PM in response to: mattm@AWS Reply ...People rely on ENT NXDOMAINs? What? How? Why? A DNS resolver shouldn't rely on NOERROR or NXDOMAIN, since authoritative servers aren't consistent anyway.



Bespoke software (or ISC host) and strange zones?



How about a configurable per-zone checkbox or API call? What could go wrong? Options are always fun! :-D Re: AWS DNS services break query name minimisation (DNS privacy) mattm@AWS Posted by: Posted on: Dec 13, 2017 1:59 PM in response to: mnordhoff Reply I meant that customer's software and configurations are designed to expect this behavior, and would break without it. Agreed, I don't know why anyone would consider ENT NXDOMAIN responses valuable. And I too like the idea of making this configurable, that's something the team will consider. Re: AWS DNS services break query name minimisation (DNS privacy) mnordhoff Posted by: Posted on: Aug 20, 2018 6:19 PM in response to: mattm@AWS Reply



The other DNS provider that begins with "A" deployed ENT NOERRORs last month. I already asked this in another thread, but is there any news on this? :-DThe other DNS provider that begins with "A" deployed ENT NOERRORs last month. Re: AWS DNS services break query name minimisation (DNS privacy) mnordhoff Posted by: Posted on: Oct 10, 2019 4:11 AM in response to: rijswijk Reply



When I posted before, I failed to think of the issues around wildcards...



I don't want to understate the massive amount of work involved in sorting everything out, but I'm still curious if there's news. Is there any news on Empty Non-Terminals?When I posted before, I failed to think of the issues around wildcards...I don't want to understate the massive amount of work involved in sorting everything out, but I'm still curious if there's news. View Thread RSS Feeds

Available Actions Reply to this Thread Icon Legend Answered question Unanswered question with answer points still available Unanswered question AWS Forums Status Icons Ace: 2000+ pts Expert: 750-1999 pts Guide: 300-749 pts Enthusiast: 50-299 pts Newbie: 5-49 pts Amazonian