AAAA behaviour

[marka63]

Lots of authoritative servers don't response sanely to AAAA queries.

[vttale]

Examples? What should be done when they don't?

[marka63]

TLD's should remove delegations when the servers don't return a valid NODATA for AAAA or AAAA records at apex.

Yes, we have to get ICANN and TLD operators involved.

[oerdnj]

@marka63 could you please finally give up on the idea that it's ok to break domains on TLD level based on the technical issues? That's simply not going to happen for various reasons and it's futile to propose it over and over. TLDs can do better on the education, but removing the delegation on pet peeves like this is no-no.

[oerdnj]

On the other hand this is totally in a scope for DNS Flag Day, so if a AAAA query with broken response makes the subsequent queries to other datatypes to fail, so be it.

[cathya57]

I should like to echo this as a DNS Flag day 'no more workarounds' issue - and to broaden it to beyond AAAA query responses.

The scenarios I should like to have workarounds removed for are:

• servers that respond properly for A RRsets but then SERVFAIL or fail to respond for some other RTYPEs for the same name (often these are exposed by clients that query for both A and AAAA RRs)
• servers that respond properly for A RRsets but then reply NXDOMAIN for AAAA (and often any other RTYPEs they don't have answers for) queries
• servers that respond properly 'no answer, no error' but quote the incorrect authority (usually a parent zone or intermediate empty zone) instead of claiming authority for the delegated subdomain for which they should be answering.

Some (but not all) DNS resolver implementations tolerate and work around this type of broken authoritative provisioning. I should like to see us end all tolerance for this type of misconfiguration/broken delegation.

[vttale]

I should like to echo this as a DNS Flag day 'no more workarounds' issue - and to broaden it to beyond AAAA query responses.

The scenarios I should like to have workarounds removed for are:

* servers that respond properly for A RRsets but then SERVFAIL or fail to respond for some other RTYPEs for the same name (often these are exposed by clients that query for both A and AAAA RRs)

Note RFC 2308 (NCACHE) section 7.1 explicitly says to cache ServFail against a tuple that includes qtype. There are good reasons for this; one type might in fact being having some unexpected problem that resolving a different type for the same name does not have.

* servers that respond properly for A RRsets but then reply NXDOMAIN for AAAA (and often any other RTYPEs they don't have answers for) queries

Here I agree. Aggressive NxDomain.

* servers that respond properly 'no answer, no error' but quote the incorrect authority (usually a parent zone or intermediate empty zone) instead of claiming authority for the delegated subdomain for which they should be answering.

I think this one needs even more work in the resolver to figure out it is happening. In the absence of DNSSEC and DS proofs, you don't necessarily know where the zone cut is. I don't know why you should really care, either. What benefit does the resolver gain by being strict about it?

[oerdnj]

I absolutely agree with @vttale on the first two bullets. For the third, we should not add more strictness, but it should allow us to remove the code. So, whatever is going to be easiest to implement.

[cathya57]

The scenarios I should like to have workarounds removed for are:

* servers that respond properly for A RRsets but then SERVFAIL or fail to respond for some other RTYPEs for the same name (often these are exposed by clients that query for both A and AAAA RRs)

Note RFC 2308 (NCACHE) section 7.1 explicitly says to cache ServFail against a tuple that includes qtype. There are good reasons for this; one type might in fact being having some unexpected problem that resolving a different type for the same name does not have.

Ah yes, excellent reason why not to change this. I withdraw this one (although note in passing that 'not responding at all' versus SERVFAIL can cause operational problems for some resolvers and thus accessibility problems for the zone owners and any other zones being served by the same nameservers.)

[vttale]

(although note in passing that 'not responding at all' versus SERVFAIL can cause operational problems for some resolvers and thus accessibility problems for the zone owners and any other zones being served by the same nameservers.)

Yeah, Mark & Ray's draft https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue is still alive which calls this out explicitly, but which also still allows for the possibility that there are some circumstances (eg, under attack) where a server might deliberately and reasonably choose not to respond. It is certainly bad behavior for some servers to just not reply under "normal" operational conditions, like getting a qtype they don't like, but 2308's guidance on this still seems apt.