New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
netty-resolver-dns "Got bad packet: bad label type" #8962
Comments
I suspect it has to do with the maximal datagram packet size. Try to use |
I tried this:
No luck. Tried 8192 as well. |
I tried to reproduce the problem. This seems to be a bug in The reason is that The
For Example: Send Expect
Actually decoded by Netty
When all ANSWER Records are combined in dns-proxy server and sent to the client, the original compression pointer will point to the illegal position, resulting in I'll do a PR. |
@qeesung can you provide a focused fix for the issue without changing the whole class hierarchy etc and breaking the API or is this not possible at all ? |
@normanmaurer Okay, I'll give it a try. :-) |
@qeesung thanks a lot |
@normanmaurer The reason for this problem is that rdata of DNS record cannot be parsed correctly when it contains compressed pointers. Generally, compression pointers are included only when rdata type is text type, such as In the original implementation, The original implementation of method netty/codec-dns/src/main/java/io/netty/handler/codec/dns/DefaultDnsRecordDecoder.java Lines 89 to 103 in 00afb19
Solution1: In the protected DnsRecord decodeRecord(
String name, DnsRecordType type, int dnsClass, long timeToLive,
ByteBuf in, int offset, int length) throws Exception {
if (type == DnsRecordType.PTR) {
return new DefaultDnsPtrRecord(
name, dnsClass, timeToLive, decodeName0(in.duplicate().setIndex(offset, offset + length)));
}
if (type == DnsRecordType.NS || type == DnsRecordType.CNAME /** || more types... */) {
// decode normal text rdata or compressed pointer text rdata
// return DnsRawRecord
}
return new DefaultDnsRawRecord(
name, type, dnsClass, timeToLive, in.retainedDuplicate().setIndex(offset, offset + length));
} Solution2: Add an RData decoder for each type of protected DnsRecord decodeRecord(
String name, DnsRecordType type, int dnsClass, long timeToLive,
ByteBuf in, int offset, int length) throws Exception {
ByteBuf rData = in.duplicate().setIndex(offset, offset + length);
// Get the corresponding RData decoder by type
DnsRDataDecoder<? extends DnsRecord> rDataDecoder = DnsRDataCodecs.rDataDecoder(type);
if (rDataDecoder != null) {
return rDataDecoder.decodeRData(name, dnsClass, timeToLive, rData);
}
return new DefaultDnsRawRecord(name, type, dnsClass, timeToLive, rData.retain());
} WDYT?Which way is better? |
@qeesung for 4.1 I think we should do 1) for master we can check 2) |
@normanmaurer Okay, I'll submit a new PR for 1) |
…rs (#9311) Motivation: When decoding DnsRecord, if the record contains compression pointers, and not all compression pointers are decompressed, but part of the pointers are decompressed. Then when encoding the record, the compressed pointer will point to the wrong location, resulting in bad label problem. Modification: Pre-decompressed record RData that may contain compression pointers. Result: Fixes #8962
…rs (#9311) Motivation: When decoding DnsRecord, if the record contains compression pointers, and not all compression pointers are decompressed, but part of the pointers are decompressed. Then when encoding the record, the compressed pointer will point to the wrong location, resulting in bad label problem. Modification: Pre-decompressed record RData that may contain compression pointers. Result: Fixes #8962
I have built a simple DNS proxy server using the Netty DNS resolver library. See the code here.
It works for most queries but not all. For example, when I try to query the A records for "www.apple.com" using nslookup or dig, it fails intermittently with this error:
When it fails the debug log looks like this:
When it succeeds the log looks like this:
Notice the additional OPT record when it succeeds. This appears to be the key. I just don't know how I can fix the problem when it fails.
I've discovered that if I remove the CNAME records from the response, then the query resolves with no errors. I would like to return a proper copy of the server response including the CNAME records. Any help would be greatly appreciated!
The text was updated successfully, but these errors were encountered: