Re: [dns-operations] DNS request for ./NS with two extra bytes at the end
On 26/05/2022 22:37, John Levine wrote: It appears that Brown, William said: -=-=-=-=-=- It made sense 40 years ago when it was written. In today’s security environment, it does not. It made sense and still makes sense when you know what Postel meant. Be liberal in what you accept when the specification is ambiguous, not accept any random garbage and try to guess what it means. I also want to interpret it as "be resilient to anything thrown at you". Frank ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] dns-operationsIgnored SOA serial SOA query refused
Also you should be using bind-users mailing list for BIND 9 related questions. And if you do that you need to give specifics. Anonymizing stuff or being vague makes it impossible to help you in any manner. Also BIND 9.11.4 is very old version (almost 4 years old) and BIND 9.11 itself has reached end-of-life, so you should be really asking the vendor who provided you with the package. Or upgrade to a supported version of BIND 9 - at least the latest 9.16 version and preferably latest 9.18 release. Ondrej -- Ondřej Surý (He/Him) > On 26. 5. 2022, at 22:56, Wes Hardaker wrote: > Eugene Tsuno - NOAA Affiliate via dns-operations > writes: > >> So a test stealth server was setup with an existing zone. It had a lower SOA >> serial than the running one, yet the master accepted a zone transfer and >> started >> using the outdated zone. > > How *much* lower? > > See RFC1982 for example. > -- > Wes Hardaker > USC/ISI > > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] dns-operationsIgnored SOA serial SOA query refused
Eugene Tsuno - NOAA Affiliate via dns-operations writes: > So a test stealth server was setup with an existing zone. It had a lower SOA > serial than the running one, yet the master accepted a zone transfer and > started > using the outdated zone. How *much* lower? See RFC1982 for example. -- Wes Hardaker USC/ISI ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS request for ./NS with two extra bytes at the end
It appears that Brown, William said: >-=-=-=-=-=- >It made sense 40 years ago when it was written. In today’s security >environment, it does not. It made sense and still makes sense when you know what Postel meant. Be liberal in what you accept when the specification is ambiguous, not accept any random garbage and try to guess what it means. R's, John >From: P Vixie >Sent: Thursday, May 26, 2022 11:23 AM >To: Stephane Bortzmeyer >Cc: dns-operations@lists.dns-oarc.net >Subject: Re: [dns-operations] DNS request for ./NS with two extra bytes at the >end > >The robustness principle is diametrically wrong. We must be ultra conservative >in what we accept, to put back pressure on >silly bugs before they can gain market share. >Confidentiality Notice: This electronic message and any attachments may >contain confidential or privileged information, and is >intended only for the individual or entity identified above as the addressee. >If you are not the addressee (or the employee or >agent responsible to deliver it to the addressee), or if this message has been >addressed to you in error, you are hereby >notified that you may not copy, forward, disclose or use any part of this >message or any attachments. Please notify the sender >immediately by return e-mail or telephone and delete this message from your >system. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS request for ./NS with two extra bytes at the end
It made sense 40 years ago when it was written. In today’s security environment, it does not. From: P Vixie Sent: Thursday, May 26, 2022 11:23 AM To: Stephane Bortzmeyer Cc: dns-operations@lists.dns-oarc.net Subject: Re: [dns-operations] DNS request for ./NS with two extra bytes at the end The robustness principle is diametrically wrong. We must be ultra conservative in what we accept, to put back pressure on silly bugs before they can gain market share. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS request for ./NS with two extra bytes at the end
--- Begin Message --- The robustness principle is diametrically wrong. We must be ultra conservative in what we accept, to put back pressure on silly bugs before they can gain market share. Get BlueMail for Android On May 25, 2022, 22:58, at 22:58, Stephane Bortzmeyer wrote: >[This has no operational consequences, it is just idle curiosity.] > >A server receives a few packets/second coming from several IP >addresses and querying ./NS (like in priming, or may be in some >reflection attacks). The server was never a root server, of course. > >What is interesting is that all these packets have two extra bytes at >the end, after the class. The UDP length is correct, but the DNS >content is not. I don't show you the output of tshark, because it >ignores these extra bytes (but you can see them with Wireshark or >other tools). I attached a small pcap. > >The source IP addresses (which may be spoofed) are all registered in >China. > >Did anyone see these requests? > >Side question: what should the receiver do? tshark, as I said, drops >these extra bytes, Wireshark flags no error (but displays the >bytes). I did not test them with various DNS servers to see how they >react. Ignoring the extra bytes in the name of the robustness >principle? Instead, at least one DNS library rejects the packet as >malformed. > > > > > >___ >dns-operations mailing list >dns-operations@lists.dns-oarc.net >https://lists.dns-oarc.net/mailman/listinfo/dns-operations --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Input from dns-operations on NCAP proposal
--- Begin Message --- Thank you, Peter, for the response. I want to try and steer this conversation towards the main question/concern the NCAP is looking for community input – What impact/risk comes from delegating a TLD that was receiving NXDOMAIN responses from the root but would subsequently receive a NOERROR NODATA response for single label queries to the authoritative name servers for the TLD after delegation? How does that change in response from NXDOMAIN to NOERROR NODATA impact application behavior (e.g., things like suffix search list processing)? What things will break, change behavior, etc.? Thanks. Matt On 5/25/22, 9:37 AM, "Peter Thomassen" wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Thomas, On 5/23/22 15:48, Thomas, Matthew wrote: > In the 2012 round of new gTLDs, DNS data collected at the root server system via DNS-OARC’s DITL collection was used to assess name collision visibility. The use of DITL data for name collision assessment purposes has growing limitations in terms of accessibility, increasing data anonymization constraints, a narrow data collection time window, and the limited annual collection frequency. I think these are valid concerns, but they don't necessarily mean that a new assessment methodology is needed. Instead, we could try to work towards reducing these limitations, i.e. improve accessibility, collection frequency etc. > Other changes in the DNS, such as Qname Minimization, Aggressive NSEC Caching, etc., also continue to impair name collision measurements at the root. QNAME Minimization drops labels from the left. How would it impact root traffic? Aggressive NSEC caching covers non-delegated domains. Assuming such a record is cached, the root would not be asked for a name contained in the range, regardless of which special response strategy would be employed for such queries. In both cases, I think it would be helpful to understand better how these mechanisms impair name collision measurements. Can you elaborate? > In preparation for the next round of TLDs, the NCAP team is examining possible new ways of passively collecting additional DNS data while providing a less disruptive NXDOMAIN response to queries. Before deciding what set-up best suits the data collection, I'd like to understand what data do you want to collect specifically? > The proposed system below is an attempt to preserve the NXDOMAIN response these name collision systems are currently receiving, [...] > The proposal would involve delegating a candidate TLD. The delegation process of inserting a string into the DNS root zone will make the TLD active in the domain name system. The required delegation information in the referral from the root is a complete set of NS records and the minimal set of requisite glue records. Given the DNS protocol, these two goals seem inconsistent. If the servers referred to by the NS rrset do know the zone, they will answer NOERROR for apex queries, and depending on the query type, they will also return records (e.g. NS, or SOA). If they don't know the zone, the best practice response is REFUSED. There doesn't seem to be a compliant way to delegate a candidate TLD and then have the auth return NXDOMAIN to queries for that domain. (If you do that, there is no guarantee of success. The set-up would be strange, and resolvers may decide to pass SERVFAIL to their clients, for example. Also, cache issues may arise, as pointed out by Vladimír.) > Configuration 3: Use a properly configured empty zone with correct NS and SOA records. Queries for the single label TLD would return a NOERROR and NODATA response. If I understand correctly, that's similar to what was done in 2012. Again, I'm not sure why it would not work now when it did back then. I think this is the question that should be answered first. > The level of disruption to existing private use of such labels by this restricted form of name delegation would be reasonably expected to be /minimal/; I think it would be "hoped", not "expected" to be minimal. :-) Best, Peter -- Like our community service? Please consider donating at https://secure-web.cisco.com/1L9meurL2lpDues9wEZ5Pn5j_K-T1ujsw9oJpFSM_5f9mUTfWPfCaoXX0DJH9Mxlz5RVvHTZKI4Q3z0ouc7pN7bysaYVPH4i6vHyOWzhNBBldmPb1j01VUWoEokg-ZlM2TOySuNoy0oZVNbikYodSK0PUO5KvVQmQ1oLJC7pJ_tOn-c7O0uFHxmfYafDq75fpsx_JGcYRAz6vkgrKvPh5IBBQIvj3kiCVaoggd2crmbVZeLi8rmbVfbjfTzSZ6PnS/https%3A%2F%2Fdesec.io%2F deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net
Re: [dns-operations] DNS request for ./NS with two extra bytes at the end
I’ve not looked for these, but will look now… The additional two bytes seems to be the identifier in the DNS header, plus one, based on the two messages in the PCAP sample. Roy > On 26 May 2022, at 06:40, Stephane Bortzmeyer wrote: > > [This has no operational consequences, it is just idle curiosity.] > > A server receives a few packets/second coming from several IP > addresses and querying ./NS (like in priming, or may be in some > reflection attacks). The server was never a root server, of course. > > What is interesting is that all these packets have two extra bytes at > the end, after the class. The UDP length is correct, but the DNS > content is not. I don't show you the output of tshark, because it > ignores these extra bytes (but you can see them with Wireshark or > other tools). I attached a small pcap. > > The source IP addresses (which may be spoofed) are all registered in > China. > > Did anyone see these requests? > > Side question: what should the receiver do? tshark, as I said, drops > these extra bytes, Wireshark flags no error (but displays the > bytes). I did not test them with various DNS servers to see how they > react. Ignoring the extra bytes in the name of the robustness > principle? Instead, at least one DNS library rejects the packet as > malformed. > > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
